MCP Gateway Security: What a Choke Point Enforces and What It Never Sees

A line keeps appearing in agent design documents, usually in the section headed security: all tool traffic routes through our MCP gateway. The sentence is treated as closing the topic. A gateway is a genuinely useful component and worth the integration effort, but the work it performs is narrower than the diagram suggests, and nobody benefits from leaving the gap unnamed.

Vendors in this space describe the job accurately enough. Lasso Security's material presents the component as the controlled route by which agents reach the tools and the data they need, which is a fair description. What this article covers is everything outside that description: where the choke-point instinct originates, four things a routing layer structurally cannot observe, and the layers that have to sit beside it. Operational material starts at the third heading.

The Choke-Point Instinct and Where It Comes From

The belief runs like this: one enforcement point sitting between agents and tool servers constitutes the trust boundary for everything an agent does with a tool. Funnel all traffic through it and authorisation, audit and abuse prevention get handled in one place, by one team, with one dashboard.

That instinct comes from API security, where it is largely correct. An API gateway authenticates a caller, applies a rate limit, validates a schema and writes an access log. Those requests are deterministic: a given client either may or may not perform a given operation, and the policy expresses that cleanly. MCP traffic resembles API traffic on the wire, structured requests and structured responses, and vendor positioning leans on the resemblance, which makes an unsettled category feel like a solved one.

The divergence is in what is being decided. A conventional gateway resolves one question: may this caller perform this operation? With an agent, the operation was selected by a model that had just finished reading prose which may have originated outside your organisation entirely. Permission and intention are separate questions, and only permission has a deterministic answer available at a choke point.

Four Gaps a Routing Layer Cannot Close

Obot's survey of the category states the division directly, treating the routing of traffic and the detection of behavioural change as separate engineering problems addressed by separate product types. It names the structural limit in four words, observing that a gateway "can't see behavior drift after approval".

That single limit propagates into at least four practical gaps, and each of them has a different owner inside most organisations.

• Behaviour that changes after sign-off. A server clears intake review, and later its descriptions, its schemas or the content of its responses shift. Obot's material describes exactly this case, a tool holding to its approved behaviour for months and then departing from it. Each access check continues to pass, because access is not what moved.
• Authorised calls nobody wanted. The agent consumes a document carrying planted instructions and then invokes a tool it is entirely permitted to invoke. From the gateway's position this is a valid identity making a valid request. The injection side is in prompt injection across multi-agent pipelines.
• Credential handling on the far side. Protocol guidance requires a server to reject a token where it was not the intended audience, and sets out how a confused deputy condition arises once a proxy sits in the path. Forwarding credentials onward without that audience check recreates the very failure the component was bought to prevent.
• Servers whose traffic never arrives. An engineer starts a tool server on a laptop and those calls bypass the enforcement point completely. The same guidance observes that a locally started server inherits the privileges of whatever client launched it, and asks clients to secure consent and apply isolation around installation flows that take one click.

Nothing here is a claim about how any specific product behaves. Lasso's own page describes runtime protection that holds agentic applications inside the scope intended for them, and does not document gateway internals, so take the four items above to your own supplier's documentation rather than treating this article as a product review.

A Gateway Enforces Policy, It Does Not Infer Intent

Treat the component as an enforcement point for policy. It applies the rules you can already state precisely: identity, permitted tool, permitted scope, frequency, and what gets written down. It holds no basis for judging whether an invocation is reasonable in light of everything the agent just read, because that context never arrives in a form any rule can evaluate.

Three checkpoints, following the framing in Obot's material, make the division of labour explicit.

1. Intake. Has this server and its tool set been approved, who maintains the project, and where did the artefact itself originate?
2. Invocation. Is this identity permitted this operation at this scope at this moment? The gateway owns this question and answers it well.
3. Behaviour across time. Is the tool doing what it did at intake, and does this agent's usage pattern still resemble its own history? Answering needs baselines and monitoring rather than routing.

The Layers That Belong Beside It

• Record and hash every tool definition. Capture approved names, descriptions and schemas during intake, then raise an alert or refuse the call when one of them differs. This is the least expensive answer to drift available, and it requires no additional purchase.
• Verify audience at each server, not only at the edge. Refuse any credential issued for a different resource, and treat acceptance as a defect. Our piece on audience validation and the confused deputy sets out the check itself.
• Begin minimal and elevate on demand. Protocol guidance favours a small opening scope, with a step up at the point a privileged tool is first required. A wildcard scope is a finding, not a configuration choice.
• Treat a tool's output as hostile input. Mark or remove instruction-shaped text from responses ahead of the model consuming them, while recording honestly in the design notes that this lowers likelihood and closes nothing.
• Pull workstation servers onto the same route. Either prevent unsanctioned servers from starting at the endpoint, or oblige them to traverse the identical control set. Our trust boundary article shows where those lines actually fall in practice.
• Write a record for each invocation. Agent, tool, a classification of the arguments, and the volume of data returned, routed into detection rather than into storage nobody queries.

A Fifth Gap Arrived in July

The protocol moved underneath this question, and the move matters more to a gateway than to anything else in the path. The current MCP revision is 2026-07-28, and in it the protocol is explicitly stateless with no protocol-level sessions. Each request declares its own version and the server accepts or rejects each request independently, so there is no negotiated session for a routing layer to pin a decision to. Where a server does need state across calls, the current security guidance describes it minting an explicit handle, a cart ID or a workflow ID, which comes back as an ordinary tool argument on every subsequent request.

Read that as a gateway operator and the new attack class is obvious. A state handle travelling inside an argument blob is indistinguishable, to a routing layer, from any other string a tool happens to take. The enforcement point can confirm that this identity may call this tool at this scope, and the call will be entirely valid, while the handle in the arguments belongs to somebody else. The specification addresses it where it has to be addressed, requiring that servers verify all inbound requests and never treat possession of a state handle as authentication, and recommending that handles be bound server-side to the authenticated user. Note where that obligation lands. Not on the gateway.

If you want a concrete way to find out what your own choke point does, there is now a benchmark rather than a feature matrix. MCPSEC is an Apache-licensed test suite whose published listing, version 1.1.0 dated 2 March 2026, defines 10 security properties and 64 reproducible attack cases across 12 attack classes, covering injection evasion, encoded exfiltration and audit tampering, with payloads and pass criteria documented per case. Two honest caveats before you quote it: the project sits alongside a gateway of its own, so its claim to vendor neutrality is the authors' rather than an independent finding, and its own page carries two different version labels. Use it as a test harness you run yourself, which is the part that does not depend on trusting anybody.

Who Owns the Handle Check?

Our position is that the statelessness change quietly broke the sentence this article opened with, and most architecture documents have not noticed. A gateway's natural unit of enforcement is a session: authenticate once, carry the decision, log the stream. A protocol with no sessions and with authorisation-relevant state riding inside tool arguments gives the gateway nothing to hold. It can still answer its own question well, and that question is worth answering. What it cannot do is discharge the handle-binding requirement on behalf of a server, and no amount of configuration makes it able to, because the gateway does not know which argument is a handle or whose it was. If your security story is that everything routes through one enforcement point, a whole attack class has just moved outside that story and nobody owns it.

The practical consequence is a procurement question rather than an architecture one. Ask your supplier what the component passes through to the server, not only what it blocks, because the server now needs verified caller identity to bind a handle against. A gateway that terminates identity and forwards an opaque service credential has made the check impossible downstream, which is the same shape of mistake as token passthrough, arriving from the other direction.

Where would we be wrong? If every tool server in your estate is first-party and they all import one shared library that performs handle binding, then the gateway plus that library genuinely is a single boundary, and the ownership argument above is bookkeeping. That is an achievable position and worth engineering towards. It stops being true the first time a third-party server enters the path, which for most estates is already the case, and it was never true for the servers running on laptops.

Five Checks for the Next Design Review

1. Inventory every tool server reachable by an agent, including the ones running on laptops.
2. Work out which of those the enforcement point actually observes, and keep the remainder as a separate list with names against it.
3. Enable change detection across tool descriptions and schemas.
4. Add a single behavioural alert: one tool invoked far more frequently, or returning far more data, than its own history suggests.
5. Document what the component decides and what it leaves undecided, then hand the second document to whoever carries the risk.

Our view: acquire the component, then stop presenting it as the answer in architecture reviews. It is a single layer within defence in depth, and the layers surrounding it carry most of the weight against threats that are specific to agents rather than inherited from ordinary API traffic.

There is an organisational reason this matters beyond the architecture. A gateway is a procurement item with an owner, a budget line and a renewal date, which makes it extremely easy to treat as the project's security deliverable. Behavioural baselines, recorded definitions and an endpoint policy for laptop servers have none of those properties. They are ongoing work spread across three teams, with no supplier to call when something drifts. That asymmetry, rather than any technical limitation, is why the gap keeps going unaddressed in organisations that have already paid for the choke point.

Worth repeating because it determines how the conversation goes: nothing above is an argument against the component. A central enforcement point for identity, scope and logging is good engineering, and an estate without one is harder to reason about, not safer. The argument is narrower. It is against the sentence in the design document that treats the component's presence as the end of the tool-use security discussion, because that sentence is what stops the four gaps from ever acquiring an owner.

Questions about MCP gateways

Is a gateway worth deploying at all?

Yes, as soon as more than a couple of agents and servers exist. One central place for identity, scope enforcement and logging earns its keep several times over. It is simply not sufficient by itself.

Will a gateway block prompt injection?

Not on its own. An injection changes which permitted operation gets chosen, and permission is precisely the thing the component evaluates. Tight scopes and explicit allowlists cap the damage without any need to read intention.

What exactly is tool drift?

Any change to a description, a schema or the runtime behaviour of a tool after it cleared review. Recording the definitions and baselining the behaviour are the two answers that work in practice.

How do locally launched servers fit in?

Such a server inherits the privileges of whatever client launched it, and its traffic may never reach the enforcement point at all. Require explicit consent, isolate the process, and route it through identical controls wherever the platform permits.