AI Agent Security: Why We Built Our Agent Gateway on RFC 8693

In the first piece of this series, we wrote about the four questions every CISO will be asked about AI agents in 2026. Who authorized this. On whose behalf. With what privilege. Can we prove it. In the second, we wrote about why the IETF already shipped the protocol answer to all four in January 2020, and why the hyperscalers have quietly converged on it over the last twelve months.

This piece is about what we built on top of it.

We are not going to make a novelty claim about RFC 8693. The spec is six years old. Microsoft, Okta, Keycloak, and Ping have had token exchange endpoints for years. AWS shipped on-behalf-of exchange in AgentCore Identity earlier this year. Uber and Red Hat have published reference architectures on it. The protocol is settled.

What I want to do is explain which parts of the spec mattered most for agent workloads, the design decisions we made on top of it, and where the standard ends and Oleria's work begins.

Why an authorizer at all

Before getting to the protocol, the bigger question. Why does an AI agent gateway need an authorizer in the architectural position we put it in?

The honest answer is that without one, none of the four questions are answerable in production. The agent platform issues a token at the start of a session and reuses it for every call. The MCP gateway forwards it. The downstream APIs accept it. The audit log records “the agent did it.” When an incident happens, and they have already started happening, there is no way to reconstruct who the action was actually for, what authority the agent should have had for that specific call, or whether the action was within the scope the human originally intended.

The fix is structural. The agent does not get to hold one durable token. It gets to hold a session credential, and every outbound call passes through an authorizer that exchanges that credential for a fresh, narrowly-scoped, audience-bound token with explicit on-behalf-of semantics in the token itself. The credential the agent carries is not a permission slip. It is a proof of identity that the authorizer uses to decide whether to issue a permission slip, for this specific action, in this specific moment.

That is what RFC 8693 was designed for. The agent gateway is the natural place to host it. The authorizer is the component that does the work.

The four spec elements that mattered most

RFC 8693 is a 27 page document. Four parts of it carry most of the weight for agent workloads.

The subject_token and actor_token parameters. Every request to the authorizer carries both. The user's token (the subject) and the agent's token (the actor). This is what makes on-behalf-of explicit at the protocol level rather than implied. The authorizer can verify both, independently, before deciding whether the requested exchange is one the user actually pre-authorized.

The act claim in the issued token. Every token the authorizer returns carries sub as the human and act as the agent. The audit trail at every downstream system records both. There is no point at which an action can be attributed only to “the agent.” The human accountable for the intent is always one field away. When agents chain through multiple hops, the act claims nest, and the full chain of delegation becomes a property of the token itself, not a forensic reconstruction across logs.

The may_act claim in the subject token. This is the quiet star of the spec. The user's token can carry an explicit list of agents authorized to act on the user's behalf. The authorizer checks it on every exchange request. If the agent making the request is not on the list, the exchange is refused. At the identity layer, before any downstream API ever sees the call. Zero-standing-trust for agents, enforced where it belongs.

The resource and audience parameters. Every exchange request specifies which downstream system the resulting token will be used at. The authorizer issues a token bound to that audience, scoped for that resource, and refuses to issue tokens broad enough to be reused at unintended destinations. The agent walks into a finance query with finance scope. It walks into a calendar lookup with calendar scope. Least privilege becomes a property of the runtime, not a policy ideal.

These four primitives, used together, are what makes the four questions answerable. Anything weaker on any of the four (no actor token, no act claim, no may_act enforcement, no audience binding) and one of the questions becomes unanswerable.

Where the standard ends and our work begins

RFC 8693 is a protocol. It specifies the exchange. It does not specify several things that matter for an agent gateway in production.

The standard does not say which exchanges should be allowed. That is a policy decision, and for agents that policy is the entire ballgame. We built the policy engine that decides whether a given user, with a given subject token, can authorize a given agent to act on their behalf for a given scope at a given audience. It is driven by the same Identity Context Graph that powers the rest of our platform. Human, non-human, and AI identities in one composite graph. The exchange is not just a protocol step. It is the enforcement point where policy meets identity.

The standard does not say how to revoke. RFC 8693 issues tokens. It does not invalidate them. We built a revocation path that propagates from the user, the agent, or the policy layer through to every active token issued for that subject-actor pair. When a user offboards, every agent acting on their behalf loses its tokens at the next call boundary. When an agent is decommissioned, every downstream session terminates. When a policy changes, the next exchange picks it up.

The standard does not say how to audit. RFC 8693 produces tokens with on-behalf-of semantics. It does not produce a queryable record of every exchange and every downstream use. We built that record into the gateway directly. Every exchange, every issued token, every downstream call resolves to a single row that answers all four questions. Who, on whose behalf, with what privilege, with what result. Available to your SIEM, your investigation tools, and your auditors in seconds, not after a multi-week forensic project.

The standard does not say what to do about workloads that do not speak OAuth. Most agent infrastructure today is a mix of standards-compliant identity providers, MCP servers that use their own token formats, A2A protocols, and bespoke service APIs. The gateway has to bridge them. We built the translation layer that lets non-OAuth workloads participate in the same exchange semantics. The same act claim, the same audience binding, the same audit trail, without forcing every downstream system to be RFC 8693-aware on day one.

These are the parts of the work that the standard does not do for you. They are also the parts that decide whether the agent estate is actually governable in production, or whether you have a beautiful protocol implementation that cannot answer the four questions when the auditor walks in.

What this gives you in practice

If you operate an environment with AI agents in it, and almost every meaningful enterprise now does, the runtime properties that matter are these.

Every agent call carries on-behalf-of semantics in the token itself. No reconstruction. No correlation. The answer to whose behalf the agent is acting on right now is one field in the token, available to every downstream system, at the moment of the call.

Every agent operates with task-scoped authority. The scopes the agent was originally granted are not the scopes it walks into a specific call with. The authorizer narrows scope on every exchange. Compromise of a single token compromises a single call's worth of authority, not the agent's full lifetime privilege.

Every agent can be turned off in one place. The credential the agent holds is a session credential, not a permission slip. Revoke it, and the next exchange refuses. No chasing tokens across systems, no waiting for OAuth grants to expire, no manual cleanup.

Every action by every agent resolves to a single row in the audit log that answers all four questions. Available to your investigation tooling and your auditors at query speed, not after a multi-week project.

These are the properties any defensible agent estate needs today. They are also the properties RFC 8693 makes possible, and the properties no proprietary alternative produces without a lot more work and a lot less interoperability.

What identity and security leaders should do this week

• If you have not yet, read RFC 8693 itself. It is short. It is unambiguous. It is the most useful 27 pages of agent identity reading you can do this year.
• Ask your existing IdP whether its token exchange endpoint is enabled, and whether your agent platforms can use it. The protocol is already present in Microsoft Entra, Okta, Keycloak, Ping, and several others. The configuration usually is not turned on.
• For any agent gateway, MCP infrastructure, or agent identity product you are evaluating, add one line to your RFP. Does this implement RFC 8693 conformant token exchange with act and may_act claim support, and where does the on-behalf-of audit trail live. The answers will sort the field in a single round.
• Stop accepting “the agent did it” as an audit log entry. It is not a defensible record. It is a missing record.

The bigger pattern

The agent era has produced two kinds of identity vendors. The ones inventing proprietary frameworks for problems that already have standards, and the ones implementing the standards and putting the product work where it actually matters. Policy, revocation, audit, and the parts of the runtime the protocol does not specify.

We built on RFC 8693 because it is the only available answer to the four questions, because the hyperscalers have already settled the protocol question, and because the product surface area worth building in 2026 is not the protocol. It is everything around it.

The next piece in this series introduces the gateway by name, the authorizer that powers it, and what we are doing on top of the standard that the standard cannot do on its own.

If you would like to see it before the announcement, get in touch.