MCP in Production: The Gateway Is Not the Perimeter

An InfoQ piece argues that securing Model Context Protocol deployments needs four control layers, not just a gateway in front of the tool servers. The framing is right, and it's the same lesson we learned with API gateways, reverse proxies and web application firewalls — the chokepoint you can see is rarely the chokepoint that matters. Here's what that means if you're being asked to put MCP into production this quarter.

Architecture reviews are full of boxes labelled "gateway" with everything behind them treated as solved. It happened with API management. It happened with reverse proxies in front of legacy web apps. It happened with the WAF that was going to compensate for the code nobody wanted to refactor. So when a new protocol arrives and the first production security answer is "put a gateway in front of it", I recognise the shape of the conversation before it starts.

Nik Kale's InfoQ article on securing Model Context Protocol deployments makes the case for defence in depth across four architectural layers — execution, management infrastructure, the outbound trust boundary, and semantic integrity — and argues that enforcement has to happen at what he calls the earliest trustworthy enforcement point, not just at the edge. That framing is worth your attention, because MCP is arriving in enterprise environments faster than most security teams have written a position on it.

What MCP actually is, in operational terms

Strip away the AI framing and MCP is a standardised way for a model to call your stuff. A model host connects to MCP servers; those servers expose tools, resources and prompts; the model decides which to invoke and with what arguments. If you have ever run an integration bus, you already understand the risk profile. You have a caller whose behaviour you cannot fully specify, invoking operations against systems that assume the caller knows what it is doing.

The difference from a classic integration is the non-determinism. A scheduled job that calls a SharePoint API does the same thing every night. A model deciding whether to call list_files or delete_file based on text it just read from a ticketing system is a different animal. That text is input. It is untrusted input. And in most MCP deployments, nobody has classified it as such.

The four layers, translated for people who run infrastructure

The article's layering maps reasonably cleanly onto controls you already own. Here's how I would translate it for a Microsoft-heavy estate:

Execution — tool handlers must treat arguments as data, not commands: no shell interpolation or dynamic evaluation. Run the server as a sandboxed workload with a least-privilege identity (managed identity, scoped RBAC, no interactive logon, egress-filtered subnet), not a domain-admin service account because it needs to read a few file shares.
Management infrastructure — inspectors, test harnesses, registration surfaces and admin consoles. Require authentication on every management endpoint and don't expose development tools to the internal network by default. Know which servers are approved, and whether developers are pulling community servers onto laptops and pointing them at production data.
Outbound trust boundary — limit what a server can reach on its own with egress allow-lists, and give each tool its own narrowly scoped credentials. An MCP server with unrestricted internet egress is an exfiltration channel with a friendly interface.
Semantic integrity — detect when a tool's definition changes after it was approved, typically by pinning manifests at registration and reviewing changes by diff class. It is the MCP version of a supply chain check.

Why the gateway argument keeps failing

Gateways enforce on what they can parse. A gateway in front of MCP traffic can do authentication, rate limiting, schema validation and some allow-listing of tool names. That is genuinely useful and you should have it. What it cannot do is judge intent, because intent lives in natural language that the gateway has no basis for evaluating.

Kale's phrase for the alternative — enforcement at "the earliest trustworthy enforcement point" — is the bit I would write on the whiteboard. It is the same principle behind putting authorisation checks in the application rather than the load balancer, and behind Conditional Access evaluating at token issuance rather than at the resource. Push the decision to where the context is richest and the identity is strongest. For MCP, that usually means inside the tool implementation, where you know the calling identity, the target object and the operation, rather than at a proxy that sees a JSON blob.

What I would actually do this quarter

Practical, low-drama, achievable before anyone asks for budget:

First, find out what MCP servers exist. Endpoint telemetry, network egress logs, developer laptop inventory. Not to shut them down — to know. These exercises usually surface at least one integration nobody had documented, and the value is in the conversation that follows.

Second, insist that every MCP server has its own identity with its own scoped permissions. If a tool needs read access to one document library, that is what it gets. The temptation to reuse an existing high-privilege service principal is enormous and it is how these deployments turn into incidents. Treat each tool as a separate workload identity, log its actions under its own name, and make sure the audit trail answers "which tool did this" and not just "which model did this".

Third, separate read from write. Most of the business value in early MCP deployments is retrieval. Most of the risk is in mutation. Two different server sets, two different approval paths, two different levels of scrutiny. Write operations get human confirmation until you have operational evidence that they behave, and "evidence" means logs you have actually read, not a demo that went well.

The bit that is genuinely new

I am cautious about declaring anything unprecedented, but prompt injection is not a problem our existing control set was designed for. Content-based injection against a component that treats all text as potentially instructive has no clean analogue in traditional infrastructure security. The nearest cousins are stored XSS and SQL injection, and the mitigation there was parameterisation — a hard boundary between code and data. We do not yet have a reliable equivalent for prompts, which is why the honest answer for the next twelve months is architectural containment: assume the model can be persuaded, and make sure what it can be persuaded to do is bounded by permissions rather than by good behaviour.

That is not a satisfying answer for a steering committee that wants MCP live by June. It is, however, the same answer we gave about macros, about PowerShell remoting and about OAuth consent grants — constrain the blast radius, log everything, and stop pretending the perimeter device is doing work it cannot do.

Source: Securing MCP in Production: Defense-in-Depth Beyond the Gateway