Last Tuesday, a production AI assistant running on a popular open-source framework was discovered to have full, unauthenticated access to its /api/agent route. This wasn't a sophisticated zero-day attack; it was a fundamental architectural failure. The incident, documented publicly as Med-Genie Issue #536, was flagged immediately as a "Critical Security Bug — Unauthenticated AI Agent Access." For CISOs and AI platform leaders, this represents the nightmare scenario: deploying autonomous systems that possess broad authority to alter internal state, without the access control guardrails required by SOC 2, HIPAA, or the EU AI Act.
This is not an isolated vulnerability. As security practitioners on r/Infosec bluntly note, "been trying to figure out the right way to secure ai apps once they leave the lab... access control, full inference trace... and it feels like every vendor has a different answer." The reality is that the majority of deployed AI agents currently rely on static, long-lived API keys injected directly into their environment. This creates a massive attack surface for credential theft via prompt injection. When you securely expose internal APIs to AI agents, you cannot rely on human-centric identity models. You need a systemic, infrastructure-level approach.
This guide explores how to build a zero-trust AI gateway for tool calling using Agentic IAM and the OAuth 2.0 Token Exchange (RFC 8693) pattern—the exact architectural standard recently endorsed by the OpenID Foundation for governing autonomous execution loops.
The Access Control Crisis in Agentic AI
The naive approach: Hardcoding ADMIN_API_KEY into the agent's environment
When development teams first transition AI agents from prototype to production using orchestration frameworks like LangGraph or CrewAI, the quickest path to giving the agent "skills" is to pass API keys as environment variables. In a local development setup, this seems harmless. In production, it is a catastrophic liability.
# The standard, insecure way most agents are deployed today import os from langchain.agents import initialize_agent # These keys grant broad, perpetual access to core infrastructure os.environ["STRIPE_API_KEY"] = "sk_live_51M..." os.environ["INTERNAL_HR_API_KEY"] = "hr_prod_99x..." os.environ["AWS_ACCESS_KEY_ID"] = "AKIAIOSFODNN7EXAMPLE" agent = initialize_agent(tools, llm, agent="zero-shot-react-description")
In this deployment model, the agent application itself holds the ultimate bearer tokens. Any tool the agent decides to invoke will execute with the full, unmitigated privileges of those static keys. There is no concept of least privilege, no identity delegation, and no granular audit trail separating the machine's actions from the human who requested them.
The risk: How prompt injection turns tool-calling into Server-Side Request Forgery (SSRF)
If an autonomous agent holds a static API key, its Large Language Model (LLM) context window effectively becomes your enterprise security perimeter. This is a fatal architectural flaw. LLMs are non-deterministic text engines; if an attacker can inject malicious instructions into the LLM's context—perhaps through a summarized customer support email or an uploaded vendor PDF—they can instruct the agent to use its powerful tools against unintended, unauthorized targets.
Because the agent holds a broad INTERNAL_HR_API_KEY, an indirect prompt injection payload can easily trick the agent into querying a sensitive endpoint like /api/v1/employees/salary and exfiltrating the data to an external server. This effectively turns the agent into an SSRF (Server-Side Request Forgery) vector, executing commands from inside your VPC on behalf of an external attacker. This highlights why understanding the MCP security crisis and tool poisoning is critical.
The blast radius of unauthenticated or over-privileged AI agents
The blast radius of a compromised agent is limited only by the permissions tied to its hardcoded keys. If an agent has read/write access to a production database via a static credential, a single jailbreak can result in complete data corruption or mass deletion. As highlighted in fast-climbing discussions on r/AI_Agents, developers are actively seeking "setups where agents have real authority to call tools, interact with internal APIs, or make operational changes," but they are operating without the governance frameworks required to do so safely.
What is Agentic IAM (Identity and Access Management)?
Defining identity for autonomous systems
Agentic IAM requires a fundamental shift in perspective. It moves the paradigm away from "Who is the human logging into the application?" to "What is the autonomous process currently executing, on whose behalf is it acting, and what specific action is it authorized to take right now?"
It requires managing machine identity with the exact same granularity, rigor, and short-lived credentialing that platform engineering teams apply to modern Kubernetes microservices. However, Agentic IAM must adapt these concepts for the non-deterministic nature of LLM execution, where the specific API payload is generated dynamically at runtime rather than being hardcoded by a developer.
The OpenID Foundation's October 2025 whitepaper: "Identity Management for Agentic AI"
In October 2025, the OpenID Foundation published a landmark, industry-defining whitepaper titled "Identity Management for Agentic AI". This document formally acknowledged that existing OAuth 2.0 and OpenID Connect flows were wholly insufficient for autonomous systems that act asynchronously, often long after the user has closed their browser session. The whitepaper highlighted the critical need to securely track the chain of delegation: from the initiating human user, down to the orchestration agent, and finally down to the specific tool making an API call.
Why legacy human-centric IAM fails for ephemeral multi-agent workflows
Legacy IAM systems expect a standard browser redirect flow or a static machine-to-machine JWT issued to a known backend service. Agents operate differently. They spawn parallel sub-agents, pause execution entirely to wait for human-in-the-loop (HITL) approvals, and dynamically construct complex API payloads on the fly.
A user logging into a frontend interface like ChatGPT (Human-to-AI identity) does not solve the backend authorization problem of how the underlying Python LangGraph agent authenticates against an internal billing microservice (AI-to-API identity). Legacy systems lack the vocabulary for "this agent is acting on behalf of user X, but only for the scope of querying invoices."
How Does OAuth 2.0 Token Exchange (RFC 8693) Work for AI?
The core concept: Trading a high-privilege context token for a narrowly-scoped, ephemeral tool token
RFC 8693 (OAuth 2.0 Token Exchange) defines a secure mechanism for an OAuth client to request a new security token by cryptographically exchanging an existing token. For AI agents, this specification is a perfect fit. It means trading a high-level, broad "Agent Session Token" for a highly restricted, incredibly narrow "Tool Execution Token" just milliseconds before an actual API call is dispatched over the network.
The actors: The Agent, The Gateway (Identity Broker), The Auth Server, The Downstream API
To implement this correctly, you need to understand the four primary actors in the Agentic IAM architecture:
- The Agent: The LLM orchestration layer (e.g., LangGraph, AutoGen) that possesses the business logic and decides what tool to call. It possesses a generic Agent Session Token but absolutely no actual API keys.
- The Gateway (Identity Broker): An inline, specialized network proxy that intercepts the tool call intent before it leaves the agent's environment.
- The Auth Server: The enterprise Identity Provider (IdP) like Keycloak, Okta, or Ping Identity that natively supports the RFC 8693 specification.
- The Downstream API: The internal microservice (e.g., HR System, billing database) that requires a cryptographically valid JWT to process a request.
Why Token Exchange Delegation is the industry standard approach
This pattern is rapidly becoming the consensus standard. As explicitly noted in Keycloak Issue #50690 detailing examples for Agentic AI use cases, "The OpenID Foundation whitepaper 'Identity Management for Agentic AI' identifies token exchange delegation as a foundational building block for secure AI agents."
It ensures that internal APIs receive standard, familiar JWTs containing claims about both the human user and the acting agent (act claim). The downstream APIs do not need to be rewritten to understand LLM logic; they simply validate standard OAuth 2.0 JWTs.
Building a Zero-Trust AI Gateway for Tool Calling
To securely expose internal APIs to AI agents and satisfy rigorous security audits, we must move identity governance completely out of the LLM context window. We must implement an inline AI Gateway. Here is the concrete, step-by-step architecture for building this.
Step 1: Intercepting the Tool Execution
Extracting the JSON tool payload before it hits the network
Instead of the orchestration agent calling the downstream API directly, it sends a standardized JSON-RPC or REST payload to the AI Gateway. The Gateway acts as an intercepting proxy. The agent only knows the internal IP address of the Gateway and possesses its generic, short-lived Agent Session Token.
When the LLM decides to use the get_employee_data tool, the SDK routes the raw JSON payload to the Gateway rather than resolving the actual microservice URL.
Step 2: Context-Aware Policy Evaluation
Checking the caller identity, the requested API, and the payload arguments
This is where the AI Gateway differentiates itself from standard proxies. Before exchanging any tokens, the Gateway evaluates the intent of the request by parsing the JSON payload that the LLM generated. It checks this payload against a strict, centrally managed policy:
- Is Agent Service A authorized to call the HR service on behalf of the current user?
- Is it authorized to call the specific
get_salaryendpoint? - Crucially: Are the specific arguments generated by the non-deterministic LLM (e.g.,
employee_id: 123) within the agent's authorized scope? Does this agent have permission to query employee 123, or only employee 456?
Step 3: Executing the Token Exchange
Using an AI Gateway to request a short-lived JWT from an Identity Provider (like Keycloak/Okta)
If, and only if, the deep payload policy evaluation passes, the Gateway acts as an OAuth 2.0 client. It securely sends a token exchange request to the Auth Server (IdP), presenting the generic Agent Session Token and requesting a new token explicitly scoped for the target API.
POST /token HTTP/1.1 Host: idp.internal.local Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &subject_token=<AGENT_SESSION_TOKEN> &subject_token_type=urn:ietf:params:oauth:token-type:jwt &audience=hr_microservice &resource=urn:api:hr:read
The Auth Server validates the subject_token and the gateway's credentials, then mints a new JWT.
Step 4: Proxying the Request
Injecting the JWT into the Authorization header and forwarding to the internal API
The Auth Server responds with an ephemeral JWT valid for exactly this specific tool call. The Gateway strips out any agent-level tokens, injects this newly minted, highly restricted JWT into the Authorization: Bearer header, and proxies the HTTP request to the internal microservice.
The internal API simply validates the JWT signature and scopes, processing the request securely. The internal API never knows that an LLM generated the request; it only sees a cryptographically verified mandate from the Auth Server.
Why Can't I Just Use a Legacy API Gateway?
Legacy proxies inspect HTTP headers, not JSON schema payloads embedded in LLM completions
You might wonder why you can't just configure your existing Kong or Apigee deployment to handle this. Traditional API gateways are designed to route based on static URLs and authenticate based on static headers. They are entirely blind to the dynamic, nested JSON payloads generated by LLM tool calls (like the tools array output by OpenAI). They cannot enforce authorization rules based on the arguments an AI chose to use.
The requirement for LLM-native parsing (OpenAI/Anthropic tool formats)
An AI Gateway must natively understand the specific schema formats output by disparate foundation models. If Claude outputs a <invoke> XML block, or OpenAI outputs a specific nested JSON structure, the gateway must accurately parse this schema to apply argument-level authorization before executing the token exchange. Legacy proxies lack this LLM-specific parsing capability.
Latency and statefulness in Agentic workflows
Agentic workflows often involve multiple rapid, sequential tool calls as the agent loops through reasoning and execution (ReAct). An AI Gateway must maintain incredibly low latency (sub-10ms) while handling the stateful nature of these interactions. It must cache Token Exchange responses where cryptographically appropriate, ensuring that security checks do not introduce unacceptable overhead to the agent's reasoning loop.
How Should You Scope Agent Permissions?
Principle of Least Privilege for autonomous tools
The golden rule of Agentic IAM is strict adherence to the Principle of Least Privilege. Never grant autonomous agents broad "Read All" scopes. Permissions must be tied to specific, granular tools. If an agent's designated task is to check the status of a server, its exchanged token should only possess the server:read_status scope, explicitly denying server:reboot or server:admin.
Time-bounding agent tokens (e.g., 5-minute expirations)
Tokens issued via RFC 8693 for agent actions must be highly ephemeral. A 5-minute expiration ensures that even if a token is intercepted via a memory dump, logging error, or complex exfiltration attack, its utility is drastically limited. The agent must constantly rely on the inline Gateway to broker fresh authority. This rapid expiration is key to effective AI incident response and containment.
Audience restriction (aud claims) in agent JWTs
The aud (audience) claim must be strictly enforced. The token exchanged by the gateway should only be valid for the exact microservice it is intended to hit. If an attacker manages to trick the LLM into redirecting the HTTP request to a different internal service, that secondary service will immediately reject the token because the aud claim will not match its own identifier.
While some contrarian voices in the developer community argue that orchestration tools like LangGraph or CrewAI should handle identity natively via simple SDK integrations, enterprise reality dictates otherwise. The Hitchhiker's Guide to Agentic AI and broader cybersecurity consensus clearly show that an inline AI Gateway is required to enforce zero-trust policies outside the highly vulnerable context window of the LLM.
Frequently Asked Questions
What is the difference between Agentic IAM and User IAM?
User IAM verifies the identity of a human interacting with a system, typically via a browser session, focusing on authentication. Agentic IAM governs machine identities operating autonomously, requiring advanced capabilities like chained delegation (tracking which human initiated the agent) and tool-specific ephemeral token exchange.
How does an AI Gateway differ from an API Gateway?
An API Gateway routes HTTP traffic based strictly on URLs and headers. An AI Gateway is entirely LLM-native; it intercepts and parses model-specific outputs (like OpenAI JSON tool calls or Anthropic XML), inspects the specific arguments the LLM generated, and applies security policies before allowing network execution.
Can LangGraph or CrewAI handle identity natively?
While agent orchestration frameworks can easily hold tokens in memory, relying on them for identity enforcement is dangerous. If the LLM context is compromised via prompt injection, the agent can be tricked into misusing the tokens it holds. Identity must be enforced outside the LLM execution environment entirely.
What happens if an agent's context window is compromised?
If an agent's context is compromised (e.g., via indirect prompt injection from a malicious document), an attacker controls the agent's next planned actions. With Agentic IAM and a Gateway in place, the attacker is still strictly constrained by the Gateway's policies; the Gateway will proactively block requests for unauthorized endpoints or invalid payload arguments.
How do you revoke an AI agent's access in real-time?
Because the agent relies on an inline Gateway to exchange its session token for tool-specific tokens on every single call, revoking access is instantaneous. You invalidate the Agent Session Token at the Gateway layer, which immediately cuts off the ability to exchange tokens, blocking all downstream API access instantly.
References & Research
- Keycloak Issue #50690: Examples for Agentic AI use cases
- OpenID Foundation: Identity Management for Agentic AI (PDF)
- Reddit r/Infosec: How to secure AI applications in production environments
- Reddit r/AI_Agents: What's your approach to best AI governance for autonomous agents in production?
- GitHub Issue: Med-Genie unauthenticated /api/agent route
- RFC 8693: OAuth 2.0 Token Exchange
- The Hitchhiker's Guide to Agentic AI (arXiv)