Notifications
Clear all
Topic starter
12/06/2026 9:40 pm
TL;DR: AI agents that reach models and MCP tools create an authorization problem at the gateway: model choice, server visibility, and argument-aware tool calls all need policy enforcement before any upstream request is made, according to Cerbos. The control issue is not just access routing; it is that existing IAM assumptions break when agent requests, model calls, and tool actions converge in one runtime path.
NHIMG editorial — based on content published by Cerbos: AI agent gateway authorization and policy enforcement
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- The exact ext_authz integration pattern for agentgateway and how the policy decision is wired into the request path.
- The Cerbos rule structure for model access, MCP server access, and refund argument checks.
- The per-resource token flow that scopes an agent to a specific model or server.
- The structured denial output that returns a remediation path to the agent when a rule blocks the call.
👉 Read Cerbos's analysis of AI agent gateway authorization and policy enforcement →
AI agent gateway authorization: what IAM teams need to change?
Explore further
12/06/2026 11:54 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Gateway-based authorization for AI agents needs one policy layer
