Notifications
Clear all
Topic starter
10/06/2026 10:57 pm
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.
NHIMG editorial — based on content published by Cerbos: AI gateway authorization and fine-grained policy for models, tools, and agents
Questions worth separating out
Q: How should security teams govern AI gateway authorization across models, tools, and agents?
A: Use the gateway as the enforcement point, but evaluate every request against contextual policy before it reaches the model or tool.
Q: Why do AI gateways create governance gaps for IAM and PAM teams?
A: They verify identity at the edge, but they often do not decide whether that identity may use a model, tool, or downstream service in a specific business context.
Q: What breaks when agent-to-agent delegation is not attenuated?
A: The delegated agent can inherit more authority than the original task justified, especially if tokens are passed downstream unchanged.
Practitioner guidance
- Move authorisation decisions out of agent code Keep allow and deny logic in a central policy layer that the gateway can call before routing each AI request.
- Enforce attenuation on every delegated hop Require each sub-agent grant to be a strict subset of the delegator’s authority and the originating user’s permissions.
- Filter MCP tool discovery by principal and context Return a reduced tool catalog to low-privilege callers and reserve destructive methods for explicit break-glass roles.
What's in the full article
Cerbos's full guide covers the operational detail this post intentionally leaves for the source:
- Native enforcement patterns for AI gateways, including pre-request plugins, ext-auth calls, and SDK hooks.
- Concrete policy examples for model allowlists, data-residency routing, tool-level access, and bounded delegation.
- Context enrichment patterns that combine identity, resource, and relationship data at request time.
- Fail-closed design guidance for long-running or high-capability agent sessions.
👉 Read Cerbos's guide on AI gateway authorization and fine-grained policy →
AI gateway authorization: what IAM teams are missing now?
Explore further
12/06/2026 4:43 am
The AI gateway has become an identity choke point, but not yet an authorisation authority. Authentication at the edge is useful, but it does not resolve the decision about whether a caller may use a model, tool, or data source in context. That gap pushes policy into agent code, downstream services, and ad hoc rules that identity teams cannot govern consistently. The practical conclusion is that gateway design now sits inside the identity stack, not beside it.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
A question worth separating out:
Q: Who is accountable when an AI agent acts on a user’s behalf through a gateway?
A: Accountability stays with the originating identity and the policy that authorised the delegation, not with an invisible agent proxy. The gateway should record both the acting agent and the human or service behind it so access decisions are traceable.
👉 Read our full editorial: AI gateways need fine-grained authorization, not just identity checks
