MCP gateways are the new developer firewall

Posted Oct 24, 2026

By Paulo Victor Leite Lima Gomes

9 min read

For years, the security conversation around developer machines had a familiar shape: endpoint protection, VPN, disk encryption, patching, and perhaps a firewall rule nobody wanted to touch.

Then we put an AI agent beside the terminal.

That agent can read a repository, run a CLI, use a browser session, call GitHub, query a database, open a pull request, and ask a cloud API to do something expensive. It can do all of this quickly and with a confidence level that is occasionally much higher than its correctness level.

At that point, the interesting question is not simply whether the agent runs in a container or a microVM. It is: which tools may it use, under which identity, with what approval, and how will we know later?

That policy layer is becoming the developer-machine firewall. And MCP gateways are where it is starting to become real infrastructure rather than a diagram in a security review.

A sandbox is necessary, but it is not the whole boundary

Sandboxing still matters. It limits access to files, processes, and the host. It gives a compromised agent less room to wander. But isolation alone does not decide whether an agent should be allowed to invoke delete-production-database, create a cloud access key, or send a private repository to a third-party service.

Those are tool-boundary decisions.

This distinction is easy to miss because a tool call looks harmless in an agent transcript. “Call GitHub.” “Run the deployment.” “Look up customer data.” In practice, each one is a jump from model output into an authenticated system. The agent may be inside a small VM while the credential, OAuth browser session, or local helper process that gives the call meaning lives somewhere else.

So “our coding agent runs in a sandbox” is incomplete security architecture. It describes where the process lives, not what authority it can exercise.

The gateway is the useful choke point

Docker’s Sandboxes MCP gateway is a good concrete example of the emerging shape. The agent in the sandbox gets one MCP endpoint. MCP servers are registered and managed on the host, and the gateway handles exposing the chosen servers to the sandbox. OAuth-backed registrations can be authorised there too, rather than handing a bearer token to every agent configuration. Docker’s gateway documentation is explicit about this host-managed model.

The point is not that every team must adopt Docker’s product. The point is that the architecture is finally honest about where governance belongs: between an agent and its tools.

A proper gateway gives us several things a pile of local MCP configuration files does not:

a controlled inventory of servers an agent can load;
a place to bind a server to a known identity and narrow OAuth scopes;
a policy decision before a tool invocation crosses into another system;
approvals for the actions that deserve a human decision; and
audit events that can be joined to a repository, cloud, or incident timeline.

That is much closer to an application firewall than to a plugin manager. It does not just discover tools. It mediates authority.

The uncomfortable part: a gateway can be bypassed

Here is the bit vendors and architecture diagrams tend to make visually small: a gateway only governs traffic that goes through the gateway.

Docker says this plainly. Its MCP policies apply to server registration and requests handled by the Docker MCP gateway; an agent that configures a direct connection to a remote MCP server is instead governed by sandbox network policy. To close both paths, the server must be blocked in the MCP policy and its destination blocked in network policy. That warning is in the access-policy documentation.

This is the test I would apply to any “governed agent” story: can the agent reach the same capability another way? If it can curl the service directly, run an unreviewed MCP client, or install a new local server that inherits broad credentials, then the policy is advisory. The microVM is only half the boundary.

Host-run stdio servers deserve particular suspicion. They are useful and often unavoidable, but a local MCP server may run on the host rather than in the sandbox. That means registration is a supply-chain and privilege decision, not a little bit of setup. Who reviewed the command? What environment does it inherit? Which files, sockets, keychains, or CLIs can it reach? “It is local” is not an answer; it is the beginning of the threat model.

Registration and invocation are different controls

One of the better details in Docker’s model is the separation between registering a server and using it. A rule that decides whether a developer may add a server does not automatically constrain what an already registered server may do. The policy surface also distinguishes tool calls, resource reads, prompts, and gateway meta-tools. Docker documents the lifecycle split and its Cedar policy reference lists actions such as register, invokeTool, and invokePrimordial.

That separation is exactly right. These are two different questions:

Should this server exist in our agent environment at all?
Given that it exists, may this principal perform this action now?

Treating them as one permission produces the familiar failure mode: somebody approves a useful read-only integration, then the same integration grows a write tool six months later and quietly inherits the old trust.

The safe default is boring: default deny, explicit server identity, read-only tools allowed deliberately, and write tools requiring either a separate policy or an approval. Use an absolute forbid for actions that must not happen, even if another broad permit exists. Docker’s Cedar evaluation is default-deny and a matching forbid wins over a permit, including one that requests approval. That is a good property for an agent system, because “please approve this destructive action” is not a meaningful fallback for everything.

There are rough edges too. Docker notes that tool and resource listings are not Cedar-gated, so an agent can see names that policy will deny at invocation. That is not necessarily a vulnerability, but it is a reminder to design for enforcement at the call itself, not for a perfectly curated illusion of what exists.

OAuth scopes are part of the policy, not plumbing

MCP authorization is increasingly an OAuth problem. The MCP authorization specification describes protected MCP servers as OAuth resource servers and MCP clients as clients acting for a resource owner. It also makes an important distinction: the HTTP authorization flow is not meant for stdio; stdio implementations are expected to obtain credentials from their environment. The draft specification is worth reading before treating “supports OAuth” as a complete security claim.

OAuth is powerful here, but only if the scopes match the job. An agent that needs to read issues does not need organisation administration. A deployment-review agent does not need the ability to create new cloud identities. A support assistant does not need a token that can download every customer export.

This sounds obvious, but the ecosystem has earned skepticism. A 2026 measurement study found 7,973 live remote MCP servers and reported that 40.55% exposed tools without authentication. Among 119 testable OAuth-enabled servers, every server had at least one identified flaw; the paper reported dynamic-client-registration flaws in 96.6% of them. The study is a useful, sobering read. It does not mean MCP is uniquely doomed. It means convenience-driven integration is reproducing old identity mistakes at agent speed.

The answer is not to give up on OAuth or gateways. It is to centralise the decisions: which grants are acceptable, which identities can be delegated, which scopes are minted, how long tokens live, and how quickly they can be revoked. An enterprise gateway architecture paper makes the same case from the operational side: once dozens of MCP servers use different authentication styles, a single identity and governance layer becomes the only manageable way to offboard people and account for activity. Its production experience is described here.

Logs turn a policy into an operational control

Approvals without evidence are just slower permissions.

The useful audit record is not “the agent did a thing.” It is: which principal requested which action against which target, what policy decided, when, and whether a human approved it. Docker’s AI Governance audit logs use that shape—principal, action, target, decision, and time—and can be delivered locally or through Docker Cloud. The documentation also makes clear that this is a licensed, centrally governed feature, not magic telemetry that appears automatically.

I would correlate those events with the systems that mattered afterwards: GitHub audit events, cloud control-plane logs, database records, and deployment changes. If an agent opened a pull request and then a different identity changed production, that is a useful distinction. If the same agent invoked a cloud tool with a broad token, we need to know exactly which server, tool, scope, and policy path made that possible.

A practical starting policy

If you are rolling out coding agents to a team, I would start with this checklist:

Inventory every MCP server. Include remote endpoints, local stdio commands, built-in gateway tools, and the credentials each one can reach.
Centralise registration. Require a reviewed server identity, owner, intended use, transport, and lifecycle before it is available to agents.
Separate read from write. Give read-only tools their own scopes and policies. Put writes behind explicit policy and approvals where appropriate.
Block bypass routes. Pair gateway policy with egress controls so an agent cannot talk directly to a server you meant it to use only through the gateway.
Treat host-run commands as privileged code. Minimise inherited environment and filesystem access; do not make shell the universal escape hatch.
Use short-lived, narrow credentials. Bind OAuth tokens to the resource and purpose, not to the vague idea of an “AI assistant.”
Make denial and revocation routine. Remove a compromised server, token, or registration in a rehearsal—not for the first time during an incident.
Keep decision-grade logs. Retain enough context to connect an agent tool call to the resulting repository, cloud, or data-plane change.

The first wave of agent security was about putting the model in a box. That was sensible. The next wave is about deciding what doors the box can open.

The new developer firewall is not iptables. It is the policy layer between an agent and its tools—and it needs to be just as deliberately designed as the network boundary we already know how to defend.

References

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

ai, security, developer-tools

This post is licensed under CC BY 4.0 by the author.