Notifications
Clear all
Topic starter
06/07/2026 9:45 am
TL;DR: AI gateways are emerging as the enforcement point between autonomous agents and enterprise applications because static OAuth scopes, shared secrets, and browser-era assumptions do not fit headless, non-deterministic workloads, according to Andromeda Security. The trust model breaks when agents can dynamically choose tools, chain actions, and act on behalf of users without granular delegation controls.
NHIMG editorial — based on content published by Andromeda Security: Securing the New Perimeter, AI Gateways
Questions worth separating out
Q: How should security teams govern AI agents that use enterprise tools at runtime?
A: Use an AI gateway to enforce policy at the point of access, not just at token issuance.
Q: Why do OAuth scopes become a problem for autonomous agents?
A: OAuth scopes are too coarse when an agent can decide which tool to call next and can chain actions dynamically.
Q: What breaks when a locally validated agent token cannot be revoked?
A: The organisation loses the ability to cut off a compromised agent before the token expires.
Practitioner guidance
- Define gateway policy as the enforcement boundary for agent access Place the AI gateway in front of enterprise tools that agents can reach, and use it to apply context-aware policy rather than relying on token claims alone.
- Replace shared secrets with cryptographic client assertions Where headless machine access is required, prefer signed client assertions over long-lived client secrets so the private key stays with the workload.
- Separate coarse OAuth scopes from fine-grained policy Treat scopes as the minimum machine-readable input, then enforce tool-level conditions in the gateway.
What's in the full article
Andromeda Security's full blog covers the operational detail this post intentionally leaves for the source:
- The protocol-level walkthrough of front-channel and back-channel OAuth flows for machine identity
- The full explanation of token exchange, client assertions, and how different upstream auth servers affect enforcement
- The gateway policy patterns for inbound auth, outbound auth, and revocation handling in live environments
- The article's examples of MCP, SPIFFE, SPIRE, and WIMSE as the next layer of agent identity plumbing
👉 Read Andromeda Security's analysis of AI gateways and agent identity control →
AI gateways and agent identity: where OAuth starts to strain?
Explore further
06/07/2026 10:02 am
AI gateways are becoming a compensating control for identity models that were never designed for runtime tool selection. OAuth can authenticate a caller, but it does not natively express which tool chain an autonomous agent will choose next. That gap matters because the security decision is no longer about a single request, but about a sequence of decisions made after authentication. Practitioners should treat gateway policy as the place where agent behaviour, not just agent identity, is constrained.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree governing AI agents is critical to enterprise security.
A question worth separating out:
Q: Who is accountable when an AI agent acts on behalf of a user?
A: Accountability should follow the delegation chain, not just the software identity. If the human user's identity is not preserved through the downstream token and audit trail, it becomes unclear whether the action was authorised, which permissions applied, and who must answer for it. That is why on-behalf-of lineage matters for both governance and review.
👉 Read our full editorial: AI gateway governance exposes the limits of OAuth for agents
