Okta Agent Gateway vs Keycloak for MCP Authorization

Okta Agent Gateway, first announced in March 2026 and the center of the runtime enforcement Okta announced at Oktane in September 2026, is a proxy that sits between AI agents and the tools they call, mostly MCP servers, and checks identity and policy on every tool call while brokering short-lived credentials to the tools behind it. Keycloak does a different job: it is an OAuth authorization server, the component that authenticates the agent and issues tokens scoped to a specific API. The two work as separate layers rather than as alternatives to each other. A gateway enforces decisions at runtime, but something still has to mint the audience-bound tokens that the MCP authorization specification requires, and that is the role Keycloak fills whether or not you put a gateway in front of your tools.

Key Takeaways

• At Oktane in September 2026, Okta announced runtime enforcement through Agent Gateway, an inline policy point for agent tool calls, with general availability planned for the third quarter.
• The MCP authorization specification (2026-07-28) requires audience-bound tokens and forbids token passthrough, which is authorization server work.
• Keycloak 26.x covers that role with per-agent clients, short tokens and audience mappers.
• Add a runtime gateway when you need per-call policy and tool aggregation, not by default.

What did Okta announce at Oktane 2026?

Agent Gateway itself is not new. Okta first described it on 16 March 2026, in its “Okta Announces New Blueprint for the Secure Agentic Enterprise” release, as a centralized control layer for agent access to applications, APIs and databases, and offered it as a research release in July. Oktane is where it became the center of Okta’s runtime story. On 22 September 2026, SiliconANGLE reported in “Okta adds AI agent runtime gateway, forms Blueprint Alliance with AWS and CrowdStrike” that Okta had launched runtime enforcement for its Okta for AI Agents platform. The Agent Gateway, in SiliconANGLE’s description, “sits in the execution path between an agent and the tools it calls, enforcing policy and logging each interaction as it happens.” Okta’s developer documentation describes it as an identity-native proxy that aggregates tools from several remote MCP servers behind one Okta-secured endpoint, which Okta calls a virtual MCP server.

Okta’s product materials describe the runtime check as validating the agent’s identity and the user behind it, checking the policies that govern that agent, and brokering a short-lived credential for the downstream tool, with no code changes to the agent. It names Claude Code, GitHub Copilot, Salesforce Agentforce and Amazon Bedrock AgentCore as examples of agents that can connect. The downstream connection types include authorization servers, vaulted credentials, service accounts, SaaS applications and MCP servers.

The strategic shift is that Okta is moving inline. In a 29 September follow-up, “Agent gateway lets Okta police AI agent runtime actions”, SiliconANGLE quoted Ric Smith, Okta’s president of products and technology, explaining that Okta had mostly not been inline before, and that being in the request path lets it make many more authorization decisions. The same coverage said being inline lets Okta watch for threats using detection from its Permiso acquisition, and that Okta plans to add intent-based authorization, using an agent’s context and permitted tools to inform access decisions, in 2027. That last item is a roadmap statement, not a shipped feature.

Two more announcements came alongside it. Okta said it is extending its agent kill switch so it can revoke active tokens at the gateway, not only block new sessions, with general availability for that expansion planned for the fourth quarter. And Okta formed the Blueprint Alliance with eleven other vendors, including AWS, CrowdStrike, Google Cloud, Salesforce and ServiceNow, to turn its agent security framework into a multi-vendor reference architecture.

Is Okta Agent Gateway generally available?

We found no general availability notice at the time of writing. Okta for AI Agents itself became generally available on 30 April 2026. Okta’s Oktane announcements said Agent Gateway was planned for general availability in the third quarter, and the Virtual MCP Servers API in Okta’s developer documentation is labeled beta and requires an Okta for AI Agents subscription. Check Okta’s release notes before planning around a specific date.

What is an agent gateway?

An agent gateway is a policy enforcement point for agent traffic. It works like an API gateway, except the requests it sees are tool calls from AI agents, usually over MCP, rather than ordinary HTTP API calls from applications. The gateway can check who the agent is, decide whether this particular tool call is allowed, swap the agent’s token for a credential the tool accepts, and log the whole exchange in one place.

Okta is not alone in this category. The open-source agentgateway project describes itself as an agentic proxy for AI agents and MCP servers, and Google Cloud documents an Agent Gateway for its Gemini Enterprise agent platform. All three vendors use the term, so it does not yet belong to any single product.

The important point for architecture is that a gateway consumes tokens. It validates the token the agent presents and, in Okta’s design, exchanges it for a downstream credential through a token service. Neither step works unless something upstream issued a token with the right subject, audience and lifetime in the first place.

What does MCP authorization require that a gateway cannot provide?

The MCP authorization specification, in its current 2026-07-28 revision, puts specific requirements on tokens. MCP clients “MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707”, which means asking the authorization server for a token for one named MCP server. MCP servers “MUST validate that access tokens were issued specifically for them as the intended audience”, and the specification’s security considerations explicitly forbid token passthrough, where a server forwards the token it received to another service.

Those rules describe authorization server behavior. The authorization server is the only component that:

• Authenticates the agent as an OAuth client, with a client secret, a signed JWT or a federated credential.
• Decides which scopes and audiences a token may carry, so a token for the calendar tool cannot be replayed against the billing tool.
• Sets token lifetimes and refresh rules, which determine how long a leaked token stays useful.
• Revokes at the source, by disabling the client or ending the session, so no new tokens are issued.

A gateway can add a second check on top of all of this, and it can do things an authorization server cannot, such as inspecting the arguments of an individual tool call. It cannot replace the token issuer, and in Okta’s own architecture it relies on one.

How do you set up AI agent authorization with Keycloak?

Keycloak, the open-source identity and access management server behind many identity management as a service offerings, handles agent authorization with the same OAuth features it uses for any client. A pattern we recommend for Keycloak 26.x looks like this:

1. One confidential client per agent class. Give the support agent, the coding agent and the reporting agent separate applications, so each has its own scopes, audit trail and off switch. Our guide to authentication for AI agents in Keycloak covers the client settings.
2. No stored secrets where you can avoid them. Keycloak 26.6 promoted federated client authentication to supported, so agents in Kubernetes or on a cloud that issues OIDC workload tokens can authenticate with a token they already have.
3. Short access tokens. Keycloak’s default access token lifespan is five minutes. Keep agent clients at or below that, and turn on refresh token rotation (the realm’s “Revoke Refresh Token” setting) so a stolen refresh token only works once.
4. An audience per MCP server. Add an audience mapper on a client scope named after each MCP server, so tokens carry that server’s identifier in aud and the server can reject everything else. This is the fix described in our post on MCP 401 errors caused by the audience claim, and you can check the result by pasting a token into our JWT Token Analyzer.
5. Token exchange for downstream calls. When an agent or gateway needs a token for a second service, use standard token exchange (RFC 8693, supported since Keycloak 26.2) instead of passing the original token along, which is what the spec’s ban on token passthrough pushes you toward. Keycloak’s standard token exchange targets a client audience rather than an RFC 8707 resource. The Keycloak token exchange guide shows the request.
6. Disable the client to stop the agent. Turning off an agent’s client stops it from getting new tokens straight away. Access tokens it already holds stay valid until they expire, unless your MCP servers check tokens through introspection, which is one more reason to keep lifespans short.

How close is Keycloak to the MCP authorization spec?

Keycloak gets closer with each release, but it does not meet the full specification yet. The Keycloak project’s guide “Integrating with Model Context Protocol (MCP)” for 26.7.4 lists dynamic client registration as supported (although the 2026-07-28 MCP revision deprecates it in favor of Client ID Metadata Documents), and Client ID Metadata Documents (which let clients such as VS Code identify themselves by URL instead of registering) as an experimental feature behind the cimd flag. RFC 8707 resource indicators are not supported in any released 26.x version, so the same guide rates the newest MCP revisions as partially supported. An experimental resource-indicators flag already exists in the 26.6 and 26.7 code, the development-branch guide now documents it, and the upstream tracking issue is milestoned for Keycloak 27.0. The audience mapper in step 4 is how you meet the MCP audience requirement in production today. For the full setup, see securing MCP servers with Keycloak.

Where does a gateway fit in a Keycloak MCP architecture?

In a typical MCP deployment the roles line up like this: the agent is the OAuth client, Keycloak is the authorization server, each MCP server is a resource server, and a gateway, if you add one, is an optional policy enforcement point in front of the resource servers.

Agent (OAuth client)
   |  1. token request for resource=https://mcp.example.com
   v
Keycloak (authorization server) --- issues token, aud=https://mcp.example.com
   |
   |  2. tool call with bearer token
   v
Optional gateway (policy enforcement point)
   |  checks per-call policy, may exchange token for a downstream one
   v
MCP server (resource server) --- validates iss, aud, exp, signature

Without a gateway, each MCP server validates tokens itself, and that works well when you run a handful of MCP servers you control. A gateway earns its place when you have many tools from different owners and want one place to apply per-call rules and collect logs, or when you need to broker credentials for SaaS tools that do not accept your Keycloak tokens at all.

How do Okta Agent Gateway, Auth0 Agent Gateway and Keycloak compare?

Okta also has a customer-identity sibling. Auth0 announced “Auth0 Agent Gateway Beta: Secure Customer-Facing AI Agents” on its blog in September 2026, positioning it as a control plane for SaaS teams to govern which customer-facing agents can reach which tools and data. The table compares the three models, not prices.

When is Keycloak enough, and when do you want a runtime gateway?

For most teams starting with agents, Keycloak on its own covers the essentials: distinct clients per agent class, short-lived audience-bound tokens, token exchange instead of passthrough, and a client you can disable. Each MCP server validates its own tokens, and your existing logging collects Keycloak’s events (on Skycloak these appear as audit logs, and the realm settings above apply unchanged).

A runtime gateway becomes worth the extra moving part when one of these is true:

• You have many MCP servers from different teams or vendors, and you want one place to apply policy and log tool calls rather than trusting every server’s implementation.
• You need per-call decisions, for example allowing an agent to read a record but blocking it from exporting a whole table, which is finer than a token scope.
• You need credential brokering for tools that do not accept your Keycloak tokens and need their own API keys or OAuth grants.

If those needs are real, you can buy them as part of Okta’s platform or pair Keycloak with an independent gateway. The second route keeps the token issuer portable, which matters if you want to be able to change gateways later without re-registering every agent.

How does this relate to Okta’s Cross App Access and Agent SSO?

Okta has also extended Agent SSO, built on its Cross App Access work and the ID-JAG (Identity Assertion JWT Authorization Grant) draft, to its SSO customers. That covers a different step: how an agent gets a token for a second application on a user’s behalf, through the user’s identity provider. We covered it in detail in Cross App Access and ID-JAG for AI agents and in our round-up of September 2026 agentic IAM launches. Okta has not said that Agent Gateway itself depends on ID-JAG, so treat them as two separate features.

For Microsoft’s take on the same problem, see Microsoft Entra Agent ID vs Keycloak, and for Okta’s MCP server for administrators, see Okta’s managed MCP server vs Keycloak.

Frequently Asked Questions

What is Okta Agent Gateway?

Okta Agent Gateway is a proxy, first announced in March 2026 and the center of the runtime enforcement Okta announced at Oktane in September 2026, that sits between AI agents and the tools they call. It aggregates tools from several MCP servers behind one endpoint, checks identity and policy on each tool call, brokers short-lived credentials to downstream tools, and logs every interaction. Okta said general availability was planned for the third quarter.

Does an agent gateway replace an OAuth authorization server?

No. The MCP authorization specification (2026-07-28) requires clients to request audience-bound tokens through RFC 8707 and requires servers to validate the audience. An authorization server issues those tokens. A gateway validates or exchanges them and adds per-call policy, so the two work together rather than replacing each other.

Can Keycloak act as the authorization server for MCP servers?

Yes, although it is not fully conformant yet. Audience mappers let Keycloak 26.x issue audience-bound tokens that MCP servers can validate today. Dynamic client registration works but is deprecated by the 2026-07-28 MCP revision, Client ID Metadata Documents are experimental in 26.6 and 26.7, and RFC 8707 resource indicators are not yet supported in a released version, with support tracked for Keycloak 27.0.

What is the difference between Okta Agent Gateway and Auth0 Agent Gateway?

Okta Agent Gateway targets workforce agents inside an enterprise, and Auth0 Agent Gateway, announced in beta in September 2026, targets customer-facing agents in SaaS products. Both sit inline between agents and tools. Each uses its own platform as the token issuer.

How do I revoke an AI agent’s access in Keycloak?

Disable the agent’s client, which stops it from getting new tokens immediately, and end its sessions. Access tokens already issued remain valid until they expire, which is five minutes by default in Keycloak, unless your MCP servers validate tokens through introspection. Refresh token rotation limits how long a stolen refresh token can be reused.

What to do next

Map your agent traffic before you buy anything. List the agents, the MCP servers and tools they call, and who owns each one. Set up Keycloak as the authorization server with one client per agent class, audience mappers per MCP server and short token lifespans, and make every MCP server validate aud. If you then find you need per-call policy or credential brokering across many tools, add a gateway in front, and choose one that consumes your Keycloak tokens rather than one that has to replace them.

Sources

• SiliconANGLE, “Okta adds AI agent runtime gateway, forms Blueprint Alliance with AWS and CrowdStrike”, 2026-09-22, retrieved 2026-09-30, https://siliconangle.com/2026/09/22/okta-adds-ai-agent-runtime-gateway-forms-blueprint-alliance-with-aws-and-crowdstrike/
• SiliconANGLE, “Agent gateway lets Okta police AI agent runtime actions”, 2026-09-29, retrieved 2026-09-30, https://siliconangle.com/2026/09/29/agent-gateway-lets-okta-police-ai-runtime-actions-oktane/
• Okta, “Okta Announces New Blueprint for the Secure Agentic Enterprise”, press release, 2026-03-16, retrieved 2026-09-30, https://www.businesswire.com/news/home/20260316388961/en/Okta-Announces-New-Blueprint-for-the-Secure-Agentic-Enterprise
• Okta, “New Okta for AI Agents innovations increase visibility into agent behavior, secure connections at runtime, and enforce continuous agent governance”, press release, September 2026, retrieved 2026-09-30, https://www.okta.com/newsroom/press-releases/ai-innovations-oktane-2026/
• Okta Developer, “Okta Agent Gateway”, retrieved 2026-09-30, https://developer.okta.com/docs/concepts/agent-gateway/
• Okta, “Industry Leaders Form the Blueprint Alliance to Advance a Shared Architecture for Securing AI Agents”, 2026-09-22, retrieved 2026-09-30, https://investor.okta.com/news-and-events/news-releases/news-details/2026/Industry-Leaders-Form-the-Blueprint-Alliance-to-Advance-a-Shared-Architecture-for-Securing-AI-Agents/default.aspx
• Auth0, “Auth0 Agent Gateway Beta: Secure Customer-Facing AI Agents”, September 2026, retrieved 2026-09-30, https://auth0.com/blog/auth0-agent-gateway-beta/
• Model Context Protocol, “Authorization” specification, revision 2026-07-28, retrieved 2026-09-30, https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• Model Context Protocol, “Client Registration” (authorization), revision 2026-07-28, retrieved 2026-09-30, https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration
• Keycloak project, “Integrating with Model Context Protocol (MCP)” guide source at 26.7.4, retrieved 2026-09-30, https://github.com/keycloak/keycloak/blob/26.7.4/docs/guides/securing-apps/mcp-authz-server.adoc
• Keycloak project, “Resource Indicators for OAuth 2.0 (RFC 8707)”, issue #14355, retrieved 2026-09-30, https://github.com/keycloak/keycloak/issues/14355