Notifications
Clear all
Topic starter
12/06/2026 9:44 pm
TL;DR: AI gateways increasingly centralize model access, tool exposure, and spend control, but Cerbos argues that static scopes cannot answer whether a specific principal should use a specific model or MCP tool with specific inputs, according to Cerbos. Policy-driven, request-time authorization becomes the missing control when agent traffic concentrates in one proxy.
NHIMG editorial — based on content published by Cerbos: LiteLLM gateway authorization for AI agents and MCP tools
Questions worth separating out
Q: How should security teams authorize AI agents at a gateway?
A: Use request-time policy rather than static model scopes alone.
Q: Why do AI gateways create new authorization risks for NHI governance?
A: Because they concentrate many decisions into one control point while still relying on coarse scopes in many deployments.
Q: What breaks when tool authorization is based only on roles?
A: Role checks stop at broad entitlement and miss the context that makes a tool call safe or unsafe.
Practitioner guidance
- Externalise gateway authorization decisions Keep model access, tool exposure, and tool-call approval in policy rather than static proxy configuration so the decision can inspect caller identity, resource state, and request context.
- Bind MCP tool use to business attributes Require attributes such as assigned ticket, owner, amount cap, or case state before allowing high-impact tool calls, especially where agents can invoke tools directly through a shared proxy.
- Strip unused tools before the model sees them Deny tool visibility at the gateway when a tool is not relevant to the caller or task, because exposure itself expands the attack surface even if later calls are blocked.
What's in the full article
Cerbos' full article covers the operational detail this post intentionally leaves for the source:
- Two-file integration pattern for plugging external authorization into LiteLLM without forking the proxy
- Example policy logic for binding refund actions to ticket ownership and refund limits
- Request and decision log outputs that show how denied model calls and stripped tools are recorded
- Practical deployment notes for using the gateway as an enforcement point while keeping policy separate
👉 Read Cerbos' analysis of LiteLLM gateway authorization for AI agents →
AI gateway authorization for agents and MCP tools: what changes now?
Explore further
13/06/2026 12:02 am
AI gateway authorization is now an identity governance problem, not a proxy configuration problem. LiteLLM concentrates model access, tool exposure, and spend control into one hop, but concentration does not equal governance. The real control question is whether request-time policy can decide if a specific principal may perform a specific action with specific inputs. Practitioners should treat gateway policy as an identity decision layer, not a routing convenience.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 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.
A question worth separating out:
Q: Who should own policy when AI agents are using shared proxies?
A: Identity and security teams should own the policy layer, not the gateway configuration alone. The proxy can enforce decisions, but governance belongs in versioned policy that can be tested, reviewed, and audited. That keeps model access, tool exposure, and argument-level rules consistent across changing agents and protocols.
👉 Read our full editorial: LiteLLM gateway authorization exposes the gap in AI agent controls
