Do You Need a Proxy or Gateway to Secure AI Agents?

What does a proxy or gateway do well for AI agents?

A gateway gives a security team one place to see and govern the agent traffic routed through it, and for agents standardized on a protocol such as MCP that is genuinely useful. Because every governed call arrives at the same point, the team can keep a registry of approved servers, broker credentials so individual agents don’t hold long-lived secrets, deny a server or a tool outright, and keep a record of what was requested.

The pattern is also familiar, since most security teams already run API gateways and web proxies and know how to operate them. Where the agents that matter are services running in infrastructure you control and calling a known set of tools, a gateway covers most of what they do, which is why the full case for one in MCP Gateways: What They Cover and What They Miss is worth reading before concluding that a gateway is the wrong tool.

What does a gateway see of a typical agent’s work?

Usually less than the team running it assumes, and following one agent through an ordinary session shows why. Consider a developer’s coding agent that has been given three capabilities: a skill that lets it run database migrations, an MCP server for the ticketing system that the developer configured on their own laptop, and a remote MCP server for internal documentation that the company routes through its gateway.

The developer asks the agent to pick up a ticket. It reads the ticket through the local MCP server, which never touches the gateway, then queries the documentation server, which does. It loads the migration skill from its own configuration, which produces no network traffic at all, and runs the migration through a shell using the developer’s database credentials. Four meaningful actions took place, and the gateway logged one of them.

Nothing in that session was misconfigured or malicious, and the gateway did exactly what it was built to do. The gap comes from where the gateway sits, because it can only see the calls that were routed to it, and an agent’s work increasingly happens through routes that weren’t.

Where does a gateway stop working?

A gateway stops at its own boundary, which is an architectural limit rather than a sign of an immature product, and the session above shows three of the ways it bites. Capabilities defined in configuration, such as skills, grant access without an outbound call for a proxy to intercept. Agents and servers configured locally, or agents nobody registered, never appear to it, so gateway coverage measures adoption, which is the very thing an organization with shadow AI and agent sprawl can’t vouch for. And even for the calls it does see, a gateway receives the request without the instruction, retrieved context or reasoning behind it, so a request from a prompt-injected agent looks identical at the chokepoint to the same request made in good faith.

These gaps show up in real estates as well as in examples. A British bank that had already deployed MCP gateways and surveyed its developers still had significantly more tool connections surfaced by a later assessment, concentrated in the tool types a gateway never sees.

The fourth limit is operational. Every governed call waits on a network hop, so latency and availability become properties of the gateway rather than of the agent, which matters little for a few hundred agents and a great deal at the volumes some enterprises already run, where one customer applies inline controls across tens to hundreds of thousands of agent operations a day. A hedge fund customer told us that downtime from a failed control could cost more than a security incident, which is what makes the choice between failing open and failing closed an operational decision rather than a configuration detail.

Is a gateway the right way to control AI agents?

It is the right way to control the traffic that reaches it, and on its own it can’t control agents whose work happens elsewhere. In most gateway products the component that intercepts a request is also the one that enforces policy on it, so the amount you can control is capped by the amount the chokepoint can see.

That coupling also limits what enforcement can do once a request does arrive, because a boundary can generally allow or deny and little in between. A finance agent legitimately handling financial data and a marketing agent that shouldn’t be touching it can send requests that look the same at the wire, so the gateway blocks both or permits both, when what the organization wanted was a decision that depended on which agent was asking and why.

What does agent-native security mean?

Agent-native security controls an agent from inside the environment where it runs, by reading its configuration and attaching to its execution path, rather than by inspecting traffic that has been re-routed to a central point. Nothing has to be pointed at the security layer before an agent can be seen, because discovery works from the artifacts agents already leave in code repositories, on endpoints, in cloud accounts and in browsers.

Applied to the session above, an agent-native view would have recorded the coding agent, its owner and all three of its capabilities before the developer typed anything, and would have seen each of the four actions as it happened. Because it sits beside the agent, it can also use the lifecycle hooks a harness exposes, such as the moment before a tool call executes, to act on a single action with the agent’s context available, so a policy can distinguish a migration against a test database from the same command pointed at production.

Gateway-based vs agent-native: which scales better?

Agent-native security scales better as the number and variety of agents grows, because its coverage doesn’t depend on routing and it introduces no shared chokepoint for traffic to queue at. Within the protocol it proxies, a gateway scales as well as any API gateway, and it remains the stronger tool for credential brokering and for holding a central registry of approved servers.

	Gateway or proxy	Agent-native
Where it sits	In the network path, between agents and their tools	Inside the environment where each agent runs
What it sees	Traffic routed to it	Agent configuration, tool connections and execution path
Coverage depends on	Every agent being configured to use it	The surfaces it reads: cloud, code, endpoint and browser
Skills and other configuration-defined capabilities	Not visible, because there is no traffic to inspect	Visible, read from the agent’s configuration
Latency	A network hop on every governed call	No added network hop
Credential brokering and server registry	Strong, with secrets and approvals held in one place	Reports which servers agents actually use, so a registry can be checked against reality
Failure mode	An outage affects every governed call at once	A failure is local to one agent’s environment
Enforcement	Allow or deny at the boundary	Per agent and per action, with the agent’s context

The skills row is the one most easily missed, because the gap can’t be seen from inside a gateway deployment, whose logs show what arrived and have no way to show what never did.

Can you run a gateway and agent-native security together?

Yes, and where a gateway is already deployed that is usually the most sensible arrangement. The gateway keeps brokering credentials and enforcing its registry for the traffic it receives, while agent-native discovery answers a question no control can answer about itself, which is whether every agent is in fact routing through it.

Teams that are furthest along with gateways tend to ask for exactly that confirmation, often because they maintain an internal registry of pre-approved MCP servers and want evidence that coding agents on endpoints use it instead of pulling a server straight from a public repository. We make the longer version of this argument in Agentic AI Governance: Why MCP Gateways Fall Short.

How do you tell whether a gateway is enough for your agents?

Four questions will show how much of your agent estate a gateway covers and what happens at its edges.

1. What share of your agents’ capabilities arrive through the protocol the gateway proxies? If skills, plugins and SaaS connectors are also in use, the gateway covers a slice, and it helps to know how large that slice is before anyone reports coverage upward.
2. How do you know every agent is routed through it? If the answer depends on developers configuring it correctly, gateway coverage is a floor rather than a measurement.
3. What happens when the gateway is slow or unavailable? Choose deliberately between failing open and failing closed, because otherwise the choice gets made for you during an incident.
4. Can you act on one agent’s action without blocking every agent that sends a similar request? If the only lever is allow or deny at the boundary, you have access control without proportionate control.