Mind the Gateway: Where Are Enterprises Enforcing What AI Agents Can Do

Key Takeaways

• Agent identity: platform tokens such as Copilot Studio’s carry the user and the OAuth app, so scope agent groups by app.
• Agent scoping: run separate MCP gateways per agent group and access level; the SaaS grant itself can hide write tools.
• Shared controls: an approved tool catalog, credentials kept out of agents, small tool sets, read and write risk tiers, one model gateway, contained coding agents and agent-aware audit.
• Where enforcement lives: SDK or client configuration when you own the agent’s code, gateways and tool servers when you don’t.
• Sensitive data: keep agent calls behind the data platform’s own gateway so its row and column security applies.
• Cost: gateway fees are small; tool definitions and model routing drive agent spend.

A comment call to Jira came back with “tool not found.” The same call, from the same user, through a second gateway, reached Jira. The two gateways were identical except for the OAuth grant each one held to Jira.

That run was one of a series of tests we ran while working out where agent controls have to sit when your agents live on Copilot Studio, Amazon Bedrock AgentCore, Databricks and Snowflake at the same time. The tests kept pushing us toward one shape: a gateway per agent group, split by read and write access, with sensitive data left behind the data platform’s own controls.

We wanted to know if anyone else had landed in the same place.

So we read the engineering write-ups from companies running agents in production: Uber, Pinterest, Stripe, Block, Spotify, DoorDash, Netflix, Ramp, Cloudflare, Anthropic and OpenAI, plus the reference architectures AWS, Google Cloud and Snowflake publish. They agree on more than we expected. Where they diverge, the key decision comes down to whether you built the agent’s underlying code yourself or are leveraging a third-party platform.

Platform Tokens Identify the User and the App

The first thing a gateway needs is to know who is calling. In our tests, Copilot Studio’s calls to an MCP server (the Model Context Protocol endpoint an agent uses to reach tools) carried the signed-in user and the OAuth app behind the connector. They carried no agent identifier, even after the agent was published.

If the token can’t say which agent is calling, the gateway can only tell agent groups apart by the OAuth app they connect through.

The companies we read handle this in three ways:

• Mint your own agent identity. Uber built a token service that issues a short-lived token for every hop, carrying the full chain from engineer to agent to sub-agent. It works because Uber’s agents are standardized on Uber’s own SDK.
• Keep the person, label the agent. Cloudflare chose not to create agent accounts. Agents act with the employee’s permissions, and a shared layer stamps each write with the agent session behind it.
• Leave it open. Anthropic writes that it hasn’t settled whether an agent should be its own principal or an extension of the user, and expects a blend.

If most of your agents run on third-party platforms, Cloudflare’s model is the one you can deploy today. Uber’s becomes available as platforms start issuing agent identities in their tokens.

Scope Agents With Separate Gateways per Group and Access Level

Once the gateway can tell groups apart, it can scope them. Our tests pointed the same way.

In the first, a gateway rule accepted only one group’s OAuth app. A Copilot Studio agent got through. The same user calling the same tool through a different app was refused, and the change took effect within seconds.

In the second, the one from the opening, two gateways held different OAuth grants to Jira. The read-scoped gateway only exposed read tools, so a write call failed before it reached Jira. No policy of ours was in the path; the SaaS grant decided which tools existed. Grants like this are coarse, typically read or write per product, so finer scoping still needs a tool allowlist on the gateway. Per-gateway scoping is also one answer to the problem Mark Castillo’s three-layer post ends on: an agent allowlist that is all or nothing, with no read-only role and no per-user tool scoping.

The published architectures land in the same place:

• Cloudflare’s MCP portals can show different groups different tools. Its example is a finance portal that exposes only read tools for the code repository server, next to an engineering portal, limited to corporate laptops, that exposes read and write.
• Stripe hosts nearly 500 tools on one internal MCP server but gives each agent a small, curated subset, because agents do better with fewer tools.
• Pinterest gates sensitive servers by the user’s business group and limits some tools to specific chat channels.
• Google Cloud’s reference architecture gives each business unit its own tool servers for sensitive data and shares only common tools.

Scoping by gateway also gives you a clean kill switch. Removing a group’s app from one gateway cuts that group off without touching anyone else.

Seven Controls the Published Architectures Share

Read side by side, the write-ups agree on a core set of controls, whatever cloud or agent framework sits underneath:

• One catalog of approved tools, off until approved. Uber registers more than 5,000 tools in a disabled state until the owning team turns each one on and approves every description change.
• Credentials stay out of the agent. Cloudflare’s proxy injects provider keys server-side, so no API keys sit on laptops. Anthropic keeps credentials in the host keychain, outside the VM where agent code runs.
• Small tool sets per agent or group. Stripe, Spotify, Cloudflare, Pinterest and DoorDash all narrow what each agent sees.
• Reads and writes treated differently. Block designs each tool with a single risk level, read or write. Cloudflare assigns risk tiers and switches off critical tools such as merging code. AWS shows Cedar rules that permit reads for everyone and forbid destructive calls outright.
• One model gateway. Model traffic goes through a single endpoint for keys, budgets and provider switching at Uber, Cloudflare, Block and in AWS’s reference design.
• Coding agents run contained. Stripe’s agents run on isolated devboxes with no production access and no open internet. Ramp gives every session its own VM.
• Audit that knows about agents. Uber, Cloudflare and OpenAI record who asked, which agent acted and what was decided, beyond plain HTTP logs.

Where They Split: Do You Own the Agent’s Code?

The disagreements are about where to enforce, and they line up with one variable.

Companies that own the agent runtime push controls into it. Uber’s security layer runs in SDK and runtime hooks, with small local models checking each action against the agent’s declared purpose. OpenAI governs Codex through admin-enforced client configuration: sandbox modes, a network proxy with allow and deny lists, and rules by command prefix.

Companies that connect agents they didn’t build enforce at the boundary instead: a gateway, the tool server, or both. That is the AWS and Cloudflare pattern, and it is the practical option when the agent is a Copilot Studio bot or an Agentforce flow.

Most enterprises have both kinds. Treat your coding agents as the code you own, and your platform agents as the code you don’t. Mark Castillo’s Part 2 of the authorization series covers how to choose between a gateway, a tool and the destination for a single permission. It also makes the point this layout depends on: a gateway is a boundary only if nothing can route around it.

For both kinds, Anthropic’s lesson holds: an egress allowlist works as a capability grant. A malicious file in Cowork used an attacker’s API key to upload files through a domain the sandbox had to allow. If your coding agents can reach your MCP gateway, the gateway has to accept only that session’s own credential, or it becomes the exfiltration route.

Keep Sensitive Data Behind the Data Platform’s Own Controls

A single shared gateway is tempting for everything. For sensitive data, the published designs keep the call inside the platform that holds it.

Snowflake points out that a platform’s own MCP endpoint inherits the row-level security, column masking and classification the organization already manages. Google Cloud’s design keeps sensitive tool servers inside each tenant’s project. AWS keeps each line of business’s data in its own account and returns only the tool’s result to the central agent.

Routing those calls through a shared gateway with a service credential would throw that away. The data platform would see only the gateway’s identity. In our tests, Snowflake could tell two agents acting for the same user apart once the session carried an actor claim, which lets the data layer apply different rows per agent.

So the layout has two kinds of MCP gateway: shared ones for SaaS and internal APIs, and the data platform’s own gateway for sensitive data. It is the same split as in our earlier post on build-time and runtime enforcement: a gateway checks the shape of a call, and the data layer enforces the state of the record.

Gateway Fees Are the Smallest Line on the Bill

We started this exercise expecting gateway pricing to drive the routing decision. It doesn’t.

• AWS lists AgentCore Gateway at $0.005 per 1,000 calls, plus $0.025 per 1,000 Policy checks. That is about $300 a month at 10 million calls with Policy on.
• Azure lists API Management Basic v2 at about $150 a month with 10 million requests included, and Standard v2 at $700 with 50 million.

Tokens are the larger line, and the published fixes target them. Cloudflare’s Code Mode collapses tool definitions into two tools, search and execute, and cut 52 tool definitions from about 9,400 tokens to about 600. Uber lets agents request only the fields they need from a tool response. Netflix measured 20 to 30% fewer tokens and less time once Claude Code and Codex could query a code index.

Choose gateways by identity and by where the data lives. Spend cost effort on tool definitions and model routing.

Questions to Ask Your Team

• Which of our agents run on code we own, and which run on platforms we don’t?
• When an agent calls a tool, what does the gateway see: the user, the app, or the agent?
• Can one agent group’s connector reach another group’s gateway?
• Which tools are write or destructive, and who approved them?
• Do calls to sensitive data reach the data platform as the user, or as a service account?
• Can our coding agents reach anything outside their allowlist, and what can they do through what is on it?

Frequently Asked Questions

What is an MCP gateway?

An MCP gateway sits between AI agents and the tool servers they call. It authenticates the caller, decides which tools each caller can see and use, holds the downstream credentials, and records each call. Uber, Cloudflare and AWS all describe one as the main place to enforce tool access.

Should we run one gateway or several?

The published designs use one control plane with several enforcement points. Shared tools can sit behind a common gateway, scoped per agent group, while sensitive data stays behind the data platform’s own gateway so its row and column security still applies.

How can a gateway tell which agent is calling?

On most third-party platforms today, it can’t directly. Tokens typically carry the user and the connector’s OAuth app. Giving each agent group its own app and its own gateway lets the gateway scope groups now, and agent identity can be added when platforms put it in their tokens.

Do coding agents like Claude Code need a gateway?

They need two things: managed configuration that points them at your MCP gateway and model gateway, and containment for the shell commands and file access that run outside any gateway. A devbox or VM with restricted outbound traffic covers the second.

Is the gateway the expensive part?

Rarely. At published rates, gateway fees are small next to model tokens. Shrinking tool definitions and routing work to cheaper models saves far more.

Where Trust3 AI Fits

This layout leaves you with several gateways from several vendors, each with its own rule language. Trust3 AI discovers the agents and gateways across these platforms and applies one policy through each platform’s native enforcement, with no proxy hop added to the request path. You get MCP security and runtime enforcement on the platforms you already run, including per-agent allowlists of approved MCP servers, short-lived scoped credentials and a log of every tool call.

Let’s chat further here: Book a Trust3 AI demo