Gateway-based authorization for AI agents needs one policy layer

At a glance

What this is: This is an analysis of gateway-based authorization for AI agents, showing that model access, MCP server access, and tool-call arguments need policy enforcement at the same decision point.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot safely govern agentic systems if model routing and tool permissions are split across disconnected controls.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Cerbos's analysis of AI agent gateway authorization and policy enforcement

Context

AI agent governance is the discipline of deciding what an agent may reach, which tools it may expose, and how its actions are checked at runtime. The primary gap in this article is that routing and authorisation are being separated even though agents combine model calls, server discovery, and tool execution in one path.

For IAM and NHI programmes, that split matters because the agent is not just a workload calling one service. It is a non-human identity that can touch models, MCP servers, and application APIs, so the control plane has to understand all three decisions together rather than treating them as unrelated access events.

Key questions

Q: How should security teams govern AI agents at the gateway?

A: They should use one policy decision point for model access, MCP server access, and tool-call approval, with the gateway enforcing the result on every hop. That keeps policy close to the request, supports fail-closed behaviour, and makes revocation visible immediately. Splitting these decisions across different controls creates drift and weakens auditability.

Q: Why do AI agents complicate IAM and NHI controls?

A: AI agents complicate IAM and NHI controls because one identity can request models, discover tools, and execute actions within the same session. Traditional access models assume a stable target and a predictable request path. Once the actor can choose its own sequence of calls, contextual authorisation matters more than static entitlement lists.

Q: What breaks when model and MCP access are controlled separately?

A: When model and MCP access are controlled separately, the agent can learn too much too early or reach tools that should have been invisible. The result is fragmented enforcement, inconsistent audit trails, and policy gaps between routing and authorisation. A unified decision model prevents those gaps from becoming exploitable behaviour.

Q: Who should own accountability for AI agent authorisation decisions?

A: Accountability should sit with the identity and platform teams that own policy, not with the gateway alone. The gateway enforces, but the policy owner defines model tiers, tool permissions, and revocation rules. That separation matters because a technical control without clear ownership becomes hard to audit and harder to govern.

Technical breakdown

Gateway-based authorization for AI agents

A gateway fronting AI agents becomes the choke point for both model requests and MCP tool traffic. In this pattern, the gateway routes traffic, but a separate policy engine decides whether the identity can call a model, open a server, or submit a tool request. That separation matters because the gateway itself is not the policy authority. It is only the enforcement point that forwards identity and request context to the decision engine before any upstream service is touched.

Practical implication: put the policy decision in a central engine and treat the gateway as enforcement only.

Model access, MCP access, and tool-call arguments

Agent authorisation is three decisions, not one. First, the caller needs access to a model tier. Second, it needs permission to discover or initialise an MCP server. Third, it needs argument-aware approval for the actual tool call, because the same tool can be safe or unsafe depending on the inputs. That is why simple allow-lists are insufficient for agent governance. The policy must inspect the request body and the identity together, then return a decision before the model or tool endpoint is reached.

Practical implication: evaluate agent policies on model, server, and argument context separately rather than relying on route-level allow-lists.

Ext_authz, fail-closed policy checks, and auditability

The integration pattern described here relies on Envoy ext_authz, which lets the gateway call an external authorisation service on every hop. With failureMode set to deny, the system fails closed if policy cannot be evaluated. That is important for agents because they can generate many high-frequency requests in a single run. A consistent decision point also creates a single audit trail across model calls and MCP tools, which is essential when you need to reconstruct what the agent attempted and why a request was denied.

Practical implication: use a fail-closed external authorisation pattern and require one auditable decision trail for the full agent path.

Threat narrative

Attacker objective: The objective is to get an agent to perform tool actions or reach systems beyond the policy boundaries that should constrain its task.

1. entry: An agent starts a task through an employee-triggered workflow or an autonomous event and immediately reaches a model and multiple tools through a shared gateway path.
2. escalation: The agent discovers which MCP servers exist and which model options are available, turning routing knowledge into permission-seeking behaviour across the stack.
3. impact: If the policy layer is missing or fragmented, the agent can submit unsafe tool arguments, reach over-scoped systems, or expose sensitive actions before any human review occurs.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Gateway-native authorisation is becoming the control point for agentic systems. When agents can call models and enumerate MCP tools from the same runtime path, the old split between routing and authorisation stops being workable. The policy decision has to sit at the point where the request is still visible, contextual, and revocable. For NHIs, that is a familiar pattern, but the agentic twist is that the same identity may move across model and tool planes in a single task. Practitioners should treat the gateway as the enforcement surface and the policy engine as the authority.

Least privilege for agents is not a static entitlement problem, it is a request-shaping problem. A model choice, an MCP server initialisation, and a tool argument are all part of the same access decision once the actor is an agent. That makes coarse role design insufficient on its own, because the safe answer depends on task context, bound resource, and call contents. The implication is that IAM teams need to stop thinking only in terms of named permissions and start thinking in terms of contextual authorisation for non-human identities.

Authorization for an agent was designed for a stable request path. That assumption fails when the actor is autonomous because it can discover, select, and sequence tools at runtime without waiting for a human decision loop. The implication is not simply that controls need to be stronger. The control premise itself changes: review cycles, pre-approved menus, and one-time task scoping no longer describe the actual behaviour of the actor. Practitioners should recognise this as assumption collapse, not just a missing guardrail.

Identity blast radius is now shaped by how far a gateway can see and stop an agent. If the policy engine is behind the request path, the system can still enforce deny-before-spend and deny-before-disclosure. If it is elsewhere, the agent can already have learned the tool catalogue or spent model budget before the decision lands. That moves blast-radius control from a back-office IAM concern to a front-door design requirement. Security architects should assess whether their agent stack has one decision point or several inconsistent ones.

One policy engine across models, tools, and application actions is the governance model that matches the problem. The article’s strongest architectural point is not the specific gateway, but the fact that access logic, audit evidence, and revocation should live together. Fragmented policy stores create drift between the LLM plane and the tool plane, which is exactly where agent governance fails in practice. Practitioners should align their NHI architecture so that the same identity and the same policy semantics govern every hop.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• For a broader view of why agent governance is accelerating, see AI Agents: The New Attack Surface report, where 80% of organisations reported agent behaviour beyond intended scope.

What this signals

Gateway control will become the organising principle for agent governance. As AI agents move from isolated pilots into shared operational paths, teams will need to decide whether policy lives in application code, in the gateway, or in a central decision service. The strongest operating model is the one that makes every hop auditable and every denial immediate. The 18% access-scoping figure from The State of MCP Server Security 2025 suggests the market is still early in that transition.

Policy drift between model access and tool access is now a programme risk, not an implementation detail. If one team governs the LLM plane and another governs the MCP plane, the result is usually inconsistent identity semantics and unclear ownership. That gap becomes visible as soon as an agent can discover more of the environment than it should. Teams should expect their NHI and IAM operating model to converge around one authorisation layer rather than several disconnected ones.

For practitioners

• Define one authorisation authority for all agent hops Route model access, MCP initialisation, and tool execution through the same policy engine so that a single decision model governs the full agent path. Keep the gateway as the enforcement point, not the policy source.
• Require argument-aware decisions for high-risk tools Evaluate the model-produced request body before approving actions such as refunds, record changes, or payroll operations. Tie approval to the caller's identity, the bound task, and the specific arguments the agent submits.
• Fail closed when policy evaluation is unavailable Set gateway behaviour so a missing policy response denies the call rather than allowing the agent to continue. That prevents a transient policy outage from becoming an open door for model requests or MCP access.
• Map agent identities to task-scoped runtime tokens Issue per-resource runtime tokens that only work for the specific model or server the agent is authorised to reach. This limits reuse of a captured token and makes cross-service replay far less useful.
• Test revocation on every hop Remove task authority mid-run and verify that the next model call or tool call is denied immediately. If revocation only works at startup, the design still relies on standing access that agents can outlive.

Key takeaways

• AI agent governance fails when routing and authorisation are split across different control planes.
• Agent stacks need policy at the point of request because model choice, server visibility, and tool arguments are all security decisions.
• Identity teams should design for one auditable decision engine, not separate rules for the LLM plane and the tool plane.

Key terms

• Gateway-based authorization: A pattern where access decisions are enforced at the network or API gateway rather than inside each application. For AI agents, this means the gateway becomes the checkpoint for model calls, tool discovery, and tool execution, with a separate policy engine deciding whether each request is allowed.
• MCP server access scoping: The practice of restricting which Model Context Protocol servers an identity can discover, initialise, or call. In agentic systems, this prevents an agent from learning about tools it should not see and reduces the chance that a model can choose an unsafe action from an exposed catalogue.
• Argument-aware authorisation: An access control method that evaluates the actual request content, not just the caller's role or route. For AI agents, this means the policy checks the tool arguments the model produced, so the same tool can be allowed in one context and denied in another based on task scope, amount, or target.
• Fail-closed enforcement: A control behaviour that blocks access when the authorisation system cannot be reached or cannot make a decision. In agentic environments this is critical because allowing requests during policy outages can turn a temporary control failure into unsupervised model or tool access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity controls across human, machine, and agent systems, it is worth exploring.

This post draws on content published by Cerbos: AI agent gateway authorization and policy enforcement. Read the original.