The Model Context Protocol did for agent tooling what USB did for peripherals: it gave everyone a common plug. Before MCP, connecting a model to a database, a SaaS API, or an internal service meant writing custom integration code for each one. Now a tool can advertise itself in a standard way, and any MCP-aware agent can discover and call it. That standardization is the reason agentic systems went from research demos to production pilots so quickly inside large enterprises.
It's also the reason a lot of security teams are uneasy. A common plug means a model can now reach a sprawling set of tools with almost no friction, and MCP, by design, says nothing about whether a given call should be allowed. The protocol moves the call. It does not govern it. That gap is exactly where a governance layer has to live, and for a regulated firm it is the difference between an audited capability and an unmanaged liability.
What MCP is, and what it deliberately isn't
MCP is an open protocol for connecting AI models and agents to external tools and data sources. A server exposes capabilities: tools (functions the model can invoke), resources (data it can read), and prompts. A client, embedded in the agent's host application, connects to those servers, learns what's available, and relays the model's tool calls and the servers' responses. It's a clean client-server design, transport-agnostic, and intentionally minimal.
That minimalism is a feature. A protocol that tried to bake in every organization's authorization rules, data-handling requirements, and audit obligations would be unusable. So MCP stays out of it. The specification has evolved to address authorization for connecting to servers. Recent versions treat MCP servers as OAuth resource servers, so a client can present a token and a server can validate it. That's real and useful. But authenticating the connection is not the same as governing the call. Knowing who connected tells you nothing about whether this specific action, writing to a production table, paying an invoice, exporting a customer list, is permitted right now, for this agent, under this policy.
Put plainly: MCP can tell you the agent is allowed in the building. It does not decide which rooms the agent may enter, what it may carry out, or whether someone needs to sign off first. Those decisions are organization-specific, contextual, and deterministic. They belong in a layer the protocol intentionally leaves open.
Why the raw plug is risky in practice
Plug a powerful model into a rich tool catalog and several problems surface at once.
The catalog is a verb list. Every MCP tool is an action the model can take.
A read-only analytics server is low-stakes. A server that exposes execute_sql,
refund_payment, or delete_user is not. The model chooses which verb to use
based on inputs that may include untrusted content. Without something in the
path to say "no, not that, not now," the model's judgment is the only control.
Credentials live too close to the model. The straightforward way to make an MCP server work is to hand it an API key or a service token. That secret now sits in the agent's runtime, reachable by the model and by anything that can manipulate the model. Long-lived, broadly scoped credentials in an agent's environment are a standing liability, and they're the default, because they're the easy path.
Untrusted tool output flows straight back into the model. An MCP tool returns data, and that data becomes part of the model's context for the next decision. If a tool fetches a web page, reads an email, or queries a table that contains attacker-controlled text, that text can carry instructions. This is prompt injection, and the protocol does nothing to neutralize it. Nor should it; that's a runtime concern.
Sprawl outpaces oversight. MCP makes adding tools cheap, so teams add tools. Each new server widens the attack surface and the set of actions in play. Without a central point where every call is resolved, policy-checked, and logged, you lose the ability to answer basic questions: which agents can reach which tools, what did they actually do, and what did you stop them from doing.
Why bolting governance onto each server doesn't scale
The instinct is to fix this per-server: add auth here, rate-limit there, log in each service. It falls apart fast. Every team implements controls differently, or forgets some. Policy ends up scattered across a dozen codebases with no consistent enforcement and no unified record. When an auditor asks you to show every action an agent took and every one you blocked, you're stitching together logs from systems that don't agree on format, identity, or even what counts as an action. That is precisely the evidence gap that turns a routine examination into a finding.
The leverage point is the call path itself. Every MCP tool call already passes through a client-server boundary. If a single governed layer sits on that boundary, between the agent and the tools, you get consistent enforcement and a single, complete record, without modifying every downstream service.
What good looks like: a gateway in the call path
A managed MCP gateway is a control plane that every tool call flows through before it reaches a real system. Concretely, a well-designed gateway does the following, in order, on every call:
- Resolves context. Which tenant is this, and which tool is being invoked? Everything downstream is scoped to that answer, so one customer's policy and data never bleed into another's.
- Applies deterministic policy. A per-tenant rule set decides, without invoking a model, whether the call proceeds: block writes to production, enforce IP allowlists, hold the line on budget ceilings, require a human approval gate for sensitive actions, redact PII from arguments or results. An operator kill-switch can halt everything immediately.
- Brokers credentials. Instead of the agent holding the API key, the gateway holds it in a per-tenant vault and issues a short-lived, tool-scoped token for this one call. The raw secret never reaches the model.
- Executes in a sandbox. The tool runs deny-by-default: no implicit network egress, a hard timeout, and runtime inspection for data leakage and prompt-injection patterns in inputs and outputs.
- Writes a tamper-evident record. The call, allowed or denied, lands in a per-tenant, hash-chained, write-once log. Denials matter as much as approvals: "we blocked this" is evidence.
For a security architect, the appeal is that governance becomes a property of the path, not of each engineer's diligence. For an auditor, the appeal is that there is one place to look, and the record is complete by construction. The protocol stays minimal and open. The policy, identity, and audit concerns it leaves out get handled in the one place every call already goes.
Where this fits
This is the layer Cytra is built to be: a managed MCP gateway and agent control plane that sits in the call path and runs the sequence above (resolve, policy, broker, sandbox, record) for every tool call, with agents and other non-human identities treated as first-class principals that have their own policy lane and their own audit trail. The framing that drives the design is simple. Compliance is a record of how your AI runs, and the only reliable place to produce that record is the path the calls already travel. For compliance officers and security architects, plainly: the Cytra gateway and these gateway capabilities are in private beta, not generally available. The platform is designed to be aligned and audit-ready, not certified. SOC 2 Type II and a HIPAA BAA are in process, not granted.
Takeaway: evaluating MCP governance
If your organization is adopting MCP, use this checklist to judge whether you've secured it or merely connected it:
- Is there a single point every tool call passes through, or is enforcement scattered across servers?
- Is policy deterministic and per-tenant, enforced before execution rather than inferred by a model after the fact?
- Do raw credentials ever reach the agent, or are they brokered into short-lived, scoped tokens?
- Is tool execution contained, with deny-by-default network, hard timeouts, and injection and DLP inspection on the data crossing the boundary?
- Is every call recorded, including denials, in a tamper-evident log you could hand to an auditor?
- Can a human stop everything with a kill-switch, and is that stop recorded too?
MCP solved the integration problem brilliantly. It left the governance problem open on purpose. Securing MCP means owning the call path, because that's the only place where you can decide, enforce, and prove what your agents are allowed to touch.