What is Agent Gateway?
Agent Gateway is a runtime identity enforcement layer within Okta for AI Agents. It validates every agent-to-tool request against identity policies using RFC 8693 token exchange. Unlike traditional gateways that rely on shared service keys, Agent Gateway requires credentials naming both the acting AI agent and the human user, preventing confused deputy attacks and unauthorized permission inheritance.
If an AI agent in your environment went rogue right now, could you say who it was acting for, what it touched, and when? Many security teams can't.
AI agents are shipping faster than the controls meant to govern them. Gateways can connect agents to tools. However, not many can tell you who an agent is acting on behalf of. That's a gap attackers can exploit, and it won’t appear until something's already gone wrong.
Gateways are sold as a control, but most can't verify who's actually behind a request. Without that, they're not controlling anything—they're just routing calls and logging what happened, using whatever authority they've been handed. Without identity as its foundation, a gateway is a checkpoint with no rules to enforce, no agent to attribute, and no governance to apply.
Okta’s Agent Gateway closes that gap. It is the runtime enforcement layer within Okta for AI Agents. Wherever an AI agent can be configured to call an external Model Context Protocol (MCP), Agent Gateway validates every agent-to-tool call against policy, isolates credentials at the moment of action, and produces a unified audit trail.
Okta for AI Agents adds the identity and governance foundation around Agent Gateway: agent discovery, registration as first-class identities, access workflows, certification campaigns, and cross-system audit correlation. Agent Gateway is Generally Available today as part of Okta for AI Agents. It answers the third question from the blueprint for the secure agentic enterprise: "What are my agents doing?"
In this blog, you'll learn about one of the major problems with most agent gateways: they can connect an agent to a tool, but they can't verify who an agent is acting on behalf of. And you'll see how Okta’s Agent Gateway is different: it won't process a call unless the credential names both the user and the agent behind it, helping ensure authority isn't borrowed, shared, or inherited by accident.
Why do traditional MCP gateways fail to secure AI agents?
Traditional MCP gateways can route agent requests to tools, but they often lack a critical safeguard: they can't verify who an agent is acting on behalf of.
The confused deputy vulnerability explained
Let's start with an example scenario where your agents don’t have a gateway:
- Broad credential provisioning: Your team builds an HR assistant to answer questions about employee records. To make it work for whoever asks, someone gives it a service account with read access to all of them.
- Unauthorized user request: Katie is a contractor. She asks the agent for the CEO's compensation.
- Policy bypass: The agent gives it to her, using access it legitimately holds.
- Audit failure: The request looks completely clean in the audit log.
Nothing was hacked. The only thing standing between Katie and that data was the agent's own judgment.
That's the confused deputy problem: the request carries the user's query, but not their authority. The agent acts on what it can access, not on what the person asking is actually allowed to know. It's a decades-old flaw in how permissions work, and it's exactly what shows up when you hand an agent broad access and trust it to self-govern.
Limitations of traditional MCP architectures
All-or-nothing revocation
Revoking a shared gateway credential breaks access for all connected agents, leading admins to leave overly permissive credentials permanently active:
- The admin configures a gateway connected to a GitHub MCP server using one shared credential
- Every agent connecting through that gateway inherits the same broad access
- Revoking the credential breaks access for all agents operating behind it
- The result: Nobody revokes it
Single-identity bearer tokens
MCP was designed with the confused deputy problem in mind. But there's a fundamental constraint: MCP runs on OAuth 2.1 bearer tokens, which name only one identity. A gateway can't pass the agent's token through—it has to mint a fresh one. So even if a gateway wants to tell GitHub "this is Katie's coding agent, acting for Katie," it can't. Whatever identity it picks becomes the only one GitHub sees.
Prompt engineering safeguards fail
You could try fixing this in the prompt by telling the agent never to access compensation data. It probably won't. But the credential still opens everything, so the most effective safeguard is for the agent to choose not to look—which was the original problem.
Okta’s Agent Gateway: An identity-native runtime enforcement for AI agents connecting to enterprise tools
Agent Gateway, a new Okta for AI Agents capability, is the runtime control point that enforces what an agent can connect to and what it can do during every action. It will not process a call unless the caller presents a credential that names both parties—the user requesting the action and the agent making the request. This requirement to enforce identity is what differentiates it from a gateway that just relays traffic.
Configuring an Agent Gateway.
A typical gateway can authenticate that something is allowed to connect. Agent Gateway verifies which user the request is for, which AI agent is acting, and whether that agent has been authorized to act on that user’s behalf—then enforces policy at the moment the tool call is made.
Every tool call is attributed to a managed agent identity, end user, tool, and outcome.
Say Katie is an employee, and an agent is about to make a call on her behalf. Some gateways authenticate the caller with a platform key and take the user as a parameter:
POST /mcp HTTP/1.1
Authorization: Bearer <platform api key>
{ "user_id": "Katie", "tool": "read_file", ... }
A gateway built this way can verify the key, but it cannot verify Katie. Her name is just text in the request, typed by whoever made the call, so anyone holding that key can claim to be anyone.
Agent Gateway does not accept this type of credential at all. Instead, Agent Gateway implements RFC 8693 delegation, requiring every tool call to present a credential issued by your identity provider containing two distinct identity claims:
- The subject (
sub): The authenticated end-user requesting the action - The actor (
act): The registered AI agent executing the request
This is what Agent Gateway expects on every call:
{
"sub": "00uKatie456",
"aud": "https://acme.gateway.okta.com/mcp/servers/eng-tools",
"act": {
"sub": "0oafxqCAJWWGELFTYASJ",
"sub_profile": "ai_agent web_app"
}
}
The call is for sub, and act indicates who is making it. sub_profile says the caller is an application and an agent.
Nothing is inherited, so Agent Gateway cannot invent a user. The sub in that credential is the only user that Agent Gateway may act on behalf of on this call. When Agent Gateway needs a credential for the MCP server, it exchanges the agent's credential with Okta and receives one bound to the same user, which aligns with the on-behalf-of semantics defined in RFC 8693. Okta can only return that credential because the user previously consented on the MCP server using an administrator-registered connection.
So an agent cannot talk Agent Gateway into acting for someone else. Katie can still ask. However, Agent Gateway now acts on her behalf with a credential bound to her, ensuring the agent can only do what Katie could do herself.
Identity enforcement capabilities matrix
In general, a gateway can only act on what's already in the credential it receives. Whether that credential carries the real user and agent identity, or none at all, is decided the moment it is created.
| Type of credential received by a gateway | User context captured | Agent context captured | Agent context captured |
|---|---|---|---|
| Shared service key | None | None | Low: No governance or attribution possible |
| User-only token | User only | None; every agent looks the same | Medium: Can’t distinguish agent activity from user activity |
| Delegated token (RFC 8693) | Verified user | Verified agent | High: Full runtime policy enforcement and attribution |
Okta’s Agent Gateway only operates at the third row. It will not process a call unless the credential is a verified, delegated token naming both the user and the agent.
Effective agent access rules
In practice, what an agent can actually do is bounded by the exact intersection of Agent Gateway’s permissions and user entitlements:
What the agent can do = What the gateway allows ∩ What the user can already do
What the gateway allows ← enforced by the gateway
What the user can already do ← enforced by the MCP server
Agent Gateway knows which agent is calling and which tools are exposed. The MCP server knows its own records and which users may access them. You need both.
Agent Gateway itself is a registered workload with its own principal and no standing permission to reach anything. An administrator configures two things before any call resolves:
- Delegation link: Grants a specific agent permission to delegate to this gateway on the user’s behalf. Without one, the exchange is rejected.
- Resource connection: Grants this gateway permission to reach a specific MCP server and defines exactly which of that server's tools are exposed.
Neither permission is inferred from the caller nor granted by the agent’s credential. Access is limited to the delegation and resource permissions an administrator configures.
Identity governance is also the foundation for cost governance
AI agents do not just create access risk—they can create spend at machine speed. An agent that repeatedly calls a premium API, triggers costly workflows, or invokes high-consumption tools can generate unexpected costs long before a human notices.
Cost governance starts with attribution. If multiple agents share a credential, it is difficult to answer basic questions, such as: Which agent generated the activity? Who was it acting for? Which tool or resource drove the cost?
Okta’s Agent Gateway creates the identity context needed to answer those questions. Because each request is tied to both the user and the agent acting on their behalf, organizations can correlate agent activity with the tools and resources it accesses. That creates a clearer foundation for monitoring usage, investigating unexpected activity, and applying governance as agent deployments scale.
Coming soon: Cross App Access support and a kill switch through Agent Gateway
Agent Gateway support for Cross App Access
Agents need to reach ordinary SaaS apps, such as Slack or Salesforce, and Okta has an open-standard protocol for that: Cross App Access. When support launches, Cross App Access will allow AI agents to securely access applications on a user's behalf, keeping both identities intact. The admin approves which apps agents can use, once, instead of every employee approving every app themselves.
Doing that through a gateway offers real payoff: it provides a central control point to turn an agent's access on or off, rather than managing it app by app.
Agent Gateway will support Cross App Access in the near future. It will allow the gateway to show "this request came from a grant you already approved," then trade that assertion for a fresh token without any changes needed on the app's side. That mechanism is proposed in the Identity Continuation Assertion IETF draft.
Agent Gateway-based kill switch
Finally, because every tool call passes through a single runtime enforcement point, Agent Gateway can stop requests in real time. When available, the kill switch functionality will make agent deactivation immediate, down to tokens already issued, by rejecting any request carrying a token issued to a deactivated agent. Since this will be enforced at Okta's boundary, there will be no waiting for each connected app to revoke access independently.
How to evaluate an AI agent gateway: Four critical questions to ask
Four questions will tell you where any gateway stands:
- Issuer verification: What credential does the MCP server receive, and who issued it?
- User identity proof: Can the gateway show which user a call is for, or is the user a parameter the caller supplies?
- Consent lineage: Whose consent authorized the agent's access to that MCP server?
- Bypass risk: Does the agent ever hold a credential that works without the gateway in the path?
Agent Gateway is built to answer all four.
Agent Gateway is one piece of a bigger picture: Okta for AI Agents is the broader platform that provides the visibility, control, and governance you need to secure the agents your business deploys.
Agent Gateway is available with Okta for AI Agents at no additional cost.
Current customers: Reach out to your account representative to start using it today.
Not an Okta for AI Agents customer yet? Download our datasheet to learn how Okta for AI Agents can help you securely manage your AI agents from a single control plane.
Any mention of future products, features, functionalities, or certifications in this blog is for informational purposes only. These items are not commitments to deliver and should not be relied upon to make purchasing decisions.
These materials are for general informational purposes only and do not constitute legal, privacy, security, compliance, or business advice.
The content may not reflect the most current security, legal, and/or privacy developments. You are solely responsible for obtaining advice from your own legal and/or professional advisor and should not rely on these materials for compliance, implementation, or purchasing decisions.
Okta makes no representations or warranties regarding this content and is not liable for any loss or damages resulting from your implementation of these recommendations. Information on Okta’s contractual assurances to its customers may be found at okta.com/agreements.
