TL;DR: AI gateways can authenticate users and route traffic, but they often cannot decide what those identities may do across models, tools, MCP methods, and delegated agent calls, according to Cerbos. Fine-grained authorization shifts that decision to policy, where contextual access can be enforced at every hop instead of drifting into agent logic.
At a glance
What this is: This is a guide to why AI gateways need fine-grained authorization, not just identity checks, and how policy can decide what users, agents, and delegated calls may do.
Why it matters: IAM, PAM, and NHI teams need to treat AI gateways as enforcement points, because identity verification alone does not govern model calls, tool use, or agent-to-agent delegation.
Context
AI gateway authorization is the control gap that appears when a gateway can prove who is calling, but cannot decide what that caller may do with models, tools, or MCP methods. In AI systems, that decision often drifts into application code or agent logic, which weakens central governance and makes policy harder to test, audit, and enforce consistently.
Cerbos frames the problem around request-level decision making rather than identity alone. That matters for IAM teams because the control boundary has moved from user authentication to contextual authorization across users, agents, delegated scopes, and resource attributes.
When AI gateways proxy multiple models and tools, the access question is no longer simply whether the caller is valid. The operational question is whether the request is allowed in this environment, for this resource, with this delegation chain, at this point in the workflow.
Key questions
Q: What breaks when AI gateways do not tie requests to identity?
A: When requests are not tied to identity, teams lose the ability to distinguish between approved use, delegated agent activity, and accidental overreach. That weakens accountability, complicates investigations, and makes policy enforcement dependent on shared keys or coarse account logs. In practice, the gateway becomes a transport layer rather than a control layer.
Q: Why do AI gateway access decisions need contextual policy instead of static allowlists?
A: Because static allowlists can answer who may reach a model, but not whether that request is allowed for this resource, team, environment, or workflow state. Contextual policy lets the system combine identity with ownership, classification, and delegation before making the decision.
Q: What are the signs that agent-to-agent delegation is creating privilege drift?
A: Look for sub-agents acting with broader authority than the initiating user intended, especially when tokens pass downstream unchanged and audit logs show only the user. That pattern usually means scope attenuation is missing at one or more hops in the chain.
Q: How should security teams govern managed MCP access for AI clients?
A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.
Technical breakdown
Why gateway authentication is not enough
An AI gateway can verify tokens and claims, then forward traffic to LLMs, MCP servers, or downstream tools. That is authentication and routing, not authorization. The missing layer is policy that can combine principal attributes, resource attributes, and request context before the call continues. Without that layer, the system can say who a caller is, but not whether the requested action fits team ownership, data classification, environment, or spending limits. The result is a coarse allowlist model that cannot express the conditions enterprise AI traffic actually needs.
Practical implication: Place a policy decision point in front of gateway traffic so the request is evaluated before it reaches models or tools.
How delegation breaks when agents impersonate users
AI agents often act as the user rather than on behalf of the user, which flattens the principal chain and obscures accountability. In delegated workflows, a sub-agent may inherit the full authority of its parent unless policy attenuates that scope at each hop. That creates confused-deputy risk, because the outer identity may be legitimate while the delegated action exceeds what the original human intended. In governance terms, the delegation model matters as much as the caller identity itself.
Practical implication: Treat delegated scope as a first-class authorization input and require every downstream hop to remain within the original grant.
Why MCP method access needs per-request policy
MCP proxying increases the need for method-level control because discovery and invocation are not the same thing. A gateway may expose a broad set of tools, but only a subset should be available to a given principal, role, or workflow state. Per-method ACLs and attribute-based policy let the system hide destructive or sensitive actions from low-privilege callers while preserving richer access for approved users. This is especially important when the gateway mediates multiple agents, where a tool list alone does not describe the actual permission boundary.
Practical implication: Use contextual policy to filter MCP methods per principal, not a static tool catalogue that assumes all callers should see the same options.
Threat narrative
Attacker objective: The objective is to get an agentic or delegated AI request accepted and executed with more authority than the original caller should have received.
- Entry occurs when a valid user or agent reaches the AI gateway with a legitimate token, because the gateway authenticates identity before it decides authorization.
- Escalation happens when the request is routed onward without a contextual policy check, so application code or agent logic becomes the real place where privilege is expanded or constrained.
- Impact follows when delegated calls, MCP methods, or downstream tool actions proceed with permissions broader than the original request justified, creating confused-deputy and overreach risk.
Breaches seen in the wild
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI gateways have become enforcement chokepoints, but not governance points by default. They authenticate traffic, yet the real decision about allowed action often remains buried in agent code or downstream services. That split creates an authorization gap across model calls, tool calls, and MCP methods. The implication is that identity teams cannot stop at the front door if the policy engine is not at the same boundary.
Request-level authorization is now the control that determines whether AI routing is safe to operate. Once a gateway brokers multiple models, tools, and delegated calls, coarse allowlists and regex routes are too blunt to express team ownership, data residency, or workflow state. Fine-grained policy becomes the difference between traffic shaping and access governance, and practitioners should treat that distinction as material architecture.
Delegation without attenuation is a governance failure, not just a technical edge case. When a planner agent can pass authority downstream unchanged, the delegation chain no longer reflects the original human intent. That breaks accountability and recertification assumptions across NHI and autonomous workflows alike, so the real issue is uncontrolled scope propagation through the chain.
Per-hop authorization is the named concept this article surfaces. The gateway is not the last access decision in an AI workflow, because each MCP method, tool invocation, and agent-to-agent call can widen the effective trust boundary. Practitioners should read this as a signal that policy must travel with the request, not sit only at the perimeter.
AI governance teams should stop assuming that agent identity is the same thing as delegated permission. In practice, an authenticated agent can still be the wrong actor for the requested task if the human, service, or workflow context is missing. The implication is that authorization must be contextual, explainable, and independently enforced across the chain.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Authorisation Guide
What this signals
Per-hop authorization is becoming the practical boundary for AI governance. A gateway that merely routes traffic leaves too much discretion inside agents and application code, especially when a request crosses models, tools, and delegated calls. For practitioners, the priority is to move the decision point as close as possible to the request itself and keep it consistent across the chain.
Access reviews do not solve ephemeral AI delegation on their own. If a sub-agent can inherit broad scope and act before a human can inspect the outcome, the control needs to operate at issuance and delegation time, not after the fact. That is the real governance shift for AI gateway programmes.
AI gateway policy must be built for request context, not just caller identity. When the principal, resource, and environment all matter, a single token claim is not enough to express the decision. Teams should prepare for policy enrichment across identity stores, data systems, and workflow state so the gateway can enforce the right rule on every call.
For practitioners
- Implement request-level policy enforcement Evaluate every model call, tool call, and MCP method before the gateway forwards it, using principal, resource, and context attributes together.
- Separate authentication from authorisation decisions Keep identity verification at the gateway, but move allowed-action logic into a policy layer that can test team ownership, environment, and data classification.
- Attenuate delegated agent scopes Require each downstream agent or sub-agent to stay within the delegating principal's permissions and deny re-expansion unless the original grant explicitly allowed it.
- Filter destructive MCP methods by privilege Expose reduced tool catalogues to low-privilege callers and reserve destructive methods for approved break-glass or on-call roles.
- Fail closed on policy unavailability Block high-capability requests when the decision point cannot evaluate fresh context, then define a safe degradation path for low-risk traffic.
Key takeaways
- AI gateways can validate callers and still leave the actual permission decision unresolved, which is why request-level authorization matters.
- Delegated AI workflows are especially exposed when scope travels unchanged from one agent to another, because the original human intent gets diluted.
- Fine-grained policy needs principal, resource, and context data at enforcement time if gateways are to govern models, tools, and MCP methods consistently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on delegated AI calls and privilege boundaries across agents and tools. |
| Recommendation — Enforce scoped authorization on every agent and tool request so delegated privilege cannot expand mid-chain. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The gateway authenticates callers, but the article shows authentication alone cannot govern what happens next. |
| NHI-05 — Overprivileged NHI | The article repeatedly warns about delegated scopes and tool access exceeding the original grant. | |
| Recommendation — Pair authentication with request-level authorization so verified identities still face contextual access checks. Limit agent and service scopes to the minimum action set required for each request and each hop. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This is a direct access-control problem across AI requests, tools, and delegated identities. |
| GV.RM-01 — Risk Management Strategy | The article argues AI gateway authorization must be governed as a programme-level risk decision. | |
| Recommendation — Apply PR.AA-05 to enforce context-aware permissions for models, tools, and MCP calls. Set a risk strategy that treats AI gateway authorization as a governance control, not a routing feature. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Uncontrolled delegation and tool propagation can support downstream abuse across systems. |
| Recommendation — Map delegated AI abuse paths to credential access and lateral movement to improve detection coverage. | ||
Key terms
- AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
- Fine-Grained Authorization: Fine-grained authorization is access control that evaluates specific resources, actions, and context rather than granting broad application-level permission. For AI agents, this is the difference between merely connecting to a system and being limited to the exact data or action the task requires.
- Delegation attenuation: The narrowing of authority as work passes from one identity to another. A well-designed delegation chain limits scope at each hop so downstream actors cannot reassemble capabilities their parent never had. In autonomous and NHI systems, this is a core control because provenance alone does not prevent overreach.
- Per-Request Enforcement: Per-request enforcement evaluates the access decision at the moment the action is made, using current context rather than a standing grant. For AI gateways, this matters because routing, delegation, and workflow state can all change between calls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org