The Airlock Pattern
How Apigee’s Agent Gateway turns “can we build an agent” into “can we trust what it does next” a walkthrough of the architecture now governing autonomous AI agents in production.
From “can it reason” to “can it be talked into anything”
Six months ago the hard question on most platform teams was whether an agent could reason well enough to finish a task. Today it’s whether a well-crafted input can talk that same agent into doing something it was never supposed to do.
That’s the confused deputy problem, restated for the agentic era. An agent holds legitimate credentials to call a CRM, a billing system, an internal search index. It isn’t malicious. But a hostile email, a poisoned document, or a rogue tool response can steer its reasoning toward the wrong endpoint with the wrong parameters and it will call that endpoint with the same authenticated confidence as any correct call it makes all day.
The math doesn’t help. Even a model that’s right 95% of the time on any single step compounds that uncertainty across a ten-step task, and multi-step agent workflows are the whole point of building agents. Something going sideways isn’t the rare case it’s the expected one, eventually.
A network firewall can’t tell a legitimate tool call from a hijacked one; both look like a valid, authenticated HTTP request. Neither can the backend service on the other end it just sees a token it recognizes. That gap, between “authenticated” and “actually supposed to be doing this,” is what Apigee’s Agent Gateway pattern is built to close.
This isn’t a hypothetical for platform teams anymore. Support agents now hold tokens against ticketing systems and CRMs. Procurement agents call payment and vendor APIs. Internal DevOps copilots read logs, open tickets, and in some rollouts, trigger deploys. Every one of those is a case where “authenticated” quietly became “trusted,” without anyone deciding that on purpose the credential just followed the agent wherever its reasoning happened to go. A gateway is the place to put that decision back under someone’s control.
An airlock, not a door
A traditional API gateway checks a door: is this caller who it says it is, does it hold a key. An agent gateway behaves more like an airlock every call passes through a chamber that checks identity, narrows permission, and screens content, all before the far door ever opens onto a real system.
The four checks below don’t run as separate hops the agent has to know about. From the agent’s side, it’s a single call to a single endpoint. Everything inside the chamber happens before that call is allowed to resolve.
What the chamber actually checks
- IDENTITY: The agent authenticates as itself a service identity distinct from the human who deployed it instead of quietly inheriting a developer’s broad credentials. If the agent is compromised, what’s exposed is the agent’s own narrow identity, not whoever happened to build it.
- TOKEN EXCHANGE: That identity’s standing permission is narrowed, on the fly, into a scoped, short-lived token for the one tool call being made right now. Nothing wider than the task in front of it, and nothing that outlives the call.
- MODEL ARMOR: Prompts and responses are screened for injection attempts and for sensitive data trying to leave through a tool’s reply — the same screening whether the traffic is a human chatting with the model or an agent calling it as a reasoning step.
- POLICY ENGINE: The same engine that’s long governed human-facing APIs decides whether this agent, this token, this endpoint right now is allowed, and logs the decision either way. It’s policy-as-config, not policy buried in each agent’s code.
None of this requires the agent to be built a particular way. Apigee sits in front of what already exists, converting OpenAPI-described services into MCP-compatible tools an agent can discover the agent just looks like another authenticated client. A fussier one, but a familiar shape.
That conversion step matters more than it sounds. Most enterprises already have hundreds of internal APIs described in OpenAPI specs, built for human developers and traditional apps. Rather than hand-writing a bespoke integration for every agent framework that wants to call those APIs, Apigee wraps them once as MCP tools, and any compliant agent can discover and call them the same way. The security posture lives on the proxy, not scattered across however many agent codebases end up calling it.
A denied call, end to end
Take an invoice-review agent. Its job: compare new invoices against vendor records on file and flag mismatches. Its token scopes it to two read-only endpoints GetInvoice and ListVendors. Nothing else.
A poisoned invoice attachment convinces the agent’s reasoning that the correct next step is to call DeleteVendorRecord. The request that leaves the agent looks exactly like every other call it's made all day authenticated, well-formed, addressed to a real endpoint.
Nobody wrote invoice-specific logic to catch this. The gateway didn’t need to understand invoices, vendors, or what a “correct” reasoning path looks like. It only needed to know what this agent is scoped to do which is precisely the part that doesn’t change every time someone tweaks a prompt.
What lands in the audit log is boring on purpose: an agent ID, the endpoint it tried to call, the token scope it actually held, and a timestamp. No investigation into why the model reasoned its way there that’s a separate exercise for whoever owns the prompt and the document pipeline feeding it. The gateway’s job stops at “did this hold a valid, matching scope,” and it did that job correctly by refusing to guess.
Multiply this across a fleet of agents and the same shape holds. A support agent’s token never includes IssueRefund. A research agent's token never includes anything that writes. The gateway doesn't need a special case for each one it just needs each agent's scope defined once, correctly, up front.
What an airlock doesn’t see
Worth being honest about the limits here. A gateway answers “is this agent authorized to make this call,” not “does this call fit what the agent is actually meant to be doing right now.”
Get Yash Sanjivkumar Pawar’s stories in your inbox
Join Medium for free to get updates from this writer.
STAYS INSIDE SCOPE, STILL WRONG
An agent that never leaves its granted scopes but starts behaving strangely repeating failed calls, drifting into a pattern no legitimate task would produce still looks like a string of valid, authorized requests from the gateway’s seat. Catching that is a behavioral question, usually answered by a layer that profiles usage over time, sitting alongside the gateway rather than replacing it.
Prompt injection itself isn’t solved by any gateway either. It’s mitigated narrower scopes mean a successful injection has less to work with but a convincing enough input can still get an agent to misuse the tools it is allowed to call. The pattern shrinks the blast radius. It doesn’t promise there won’t be one.
Agent-to-agent chains add a second wrinkle. If Agent A’s output becomes Agent B’s input a common shape in multi-agent workflows a gateway checking each agent’s own scope independently can still let a chain execute a sequence no single agent was ever meant to run alone. That’s less a gap in the gateway than a reminder that scopes need to be designed with the whole chain in mind, not just each hop in isolation.
What changes once it’s a fleet, not a pilot
A single gateway in front of a single agent is the easy version. The harder, more realistic version is a platform team with a dozen agents in flight, built by different squads, each with its own reasons to touch a different slice of the same backend systems.
Centralizing at the gateway is what keeps that from becoming a dozen separate security reviews. A few things that fall out of it naturally:
- ONBOARDING: A new agent gets a scope definition before its first call, not security review after the fact once it’s already in production.
- OFFBOARDING: Retiring an agent means revoking one identity at the gateway no hunting through codebases for hardcoded keys it might still be holding.
- AUDIT ROLLUP: One log format across every agent means a platform team can answer “which agents touched customer data this week” without stitching together logs from a dozen different frameworks.
- SCOPE REVIEW: Deny counts per agent are a natural signal for a periodic access review an agent that’s constantly denied on the same endpoint either has a bug or needs a scope it was never given.
None of this replaces good judgment about what an agent should be allowed to do in the first place. It just means that judgment gets enforced in one place, consistently, instead of trusted to whoever wrote each agent’s code.
A first pass that doesn’t require a platform migration
- Pick one API with real downside if misused a delete, a payment, a record update and put it behind an MCP proxy instead of exposing it directly.
- Turn on token exchange for that one proxy before adding a second. Get the scoping right on one endpoint first.
- Route the agent’s model calls through the same gateway so prompt and response screening isn’t a separate system to maintain.
- Log every decision, allow and deny both. The deny log is what tells you, six months from now, which agent’s scope needs tightening.
- Red-team it before you trust it. Feed the agent a deliberately poisoned document or prompt and confirm the gateway actually denies the out-of-scope call it provokes don’t assume the policy works until you’ve watched it fail closed.
- Write down who owns scope changes. As agents multiply, “who’s allowed to widen this agent’s permissions” needs an answer before it needs to be asked in an incident review.
References
- Apigee AI Gateway — Agent Development Kit (ADK) docs
- Extending Agent Gateway Capabilities with Apigee (Community TechTalk)
- AI Agent Gateways: Definitive Guide to Autonomous AI
- Cequence AI Gateway vs. Google Apigee: Agentic AI Security Comparison
Next Step
Don’t try to wrap every API at once. Take the single riskiest tool call one of your agents can make today, put it behind an MCP proxy with token exchange, and confirm by actually trying to break it that an out-of-scope call gets denied. That one proxy is the whole pattern in miniature.
Thank you so much for reading 💙
Like | Follow | Subscribe to the newsletter.
Catch me on my socials here: https://bio.link/yashpawar
