Authorizer Puts Agents on the Org Chart: A2A Token Exchange, OAuth-2.1 MCP, and Secretless Kubernetes Identity

Somewhere in your infrastructure right now, an AI agent is holding a credential that can do far more than the task it was given. It might be a long-lived API key with full account scope, pasted into an agent's environment six months ago. It might be your own user token, forwarded hop to hop because nobody built a better way to say "act on my behalf, but only this much." Either way, the fastest-growing class of operator in your fleet authenticates like it is 2012: one static secret, standing authority, no record of who delegated what to whom.

Authorizer 2.4, the August 2026 release of the open-source self-hosted auth server that surfaced on Show HN in early September, is a direct answer to that problem. Maintainer Lakhan Samani framed the release with one sentence: authentication is no longer only about users. Applications now have to deal with services, workloads, organizations, and AI agents — and the release gives each of them a first-class identity. Three pieces matter most for anyone running agents against infrastructure they own: agent-to-agent delegation through RFC 8693 token exchange, a remote MCP server protected as a real OAuth 2.1 resource server, and secretless Kubernetes workload identity through RFC 7523. Together they sketch what treating agents as delegatable identities rather than long-lived API keys actually looks like in a stack you can self-host today.

Delegation, not impersonation: the RFC 8693 exchange​

The core primitive is OAuth token exchange (RFC 8693), and the release announcement explains it with the simplest possible diagram: User, then Agent A, then Agent B. Each step down that chain can hold fewer permissions than the previous one. That sounds obvious until you compare it with the status quo it replaces — handing Agent B the user's original access token, full scope and all, because minting a narrower credential mid-chain was too much work.

Concretely, when Agent A needs Agent B to do something on the user's behalf, it calls the token endpoint with the token-exchange grant, presenting the user's token as the subject and its own credential as the actor. What comes back is a new, delegated token with three properties worth naming precisely:

• The chain is visible. The subject stays the user while a nested act claim records the path: sub is the user, act.sub is Agent A, and a further hop nests again inside act.act. Anyone validating the token reads the full delegation path instead of guessing who is really behind the call.
• Scope only attenuates. The effective scope is bounded by the intersection of what the user has, what the agent is allowed, and what was requested — fail-closed, so a confused request yields less authority, never more.
• The audience is exactly one. The exchange requires a single RFC 8707 resource parameter, and the issued token's aud is that resource. A token minted for the MCP endpoint is not a general-purpose credential.

The implementation details show a team that has thought about adversarial agents, not just cooperative ones. The act and client_id claims are reserved, so a custom token script cannot forge or rewrite the delegation chain. Nested actor chains carry a hard depth cap, so a runaway delegation loop cannot build an unbounded token. And the "exactly one resource" rule is enforced in both directions — zero or multiple resources are rejected — which closes the "mint one token, use it everywhere" shortcut that audience checks are supposed to prevent.

For a deploy-from-chat roadmap, this is the missing credential verb. Today a chat instruction like "roll back the canary" typically resolves to an agent holding a standing deploy key. Under token exchange, it resolves to a short-lived token that says: this user, through this agent session, for this deploy endpoint, with rollback scope only. Revoke the session and every downstream delegation dies with it, because each hop re-resolves against the chain rather than carrying independent standing authority.

The MCP server grows up: an OAuth 2.1 resource server​

The second piece is where those delegated tokens get spent. Authorizer 2.4 exposes its MCP surface as a remote server over Streamable HTTP and protects it with OAuth 2.1 — which sounds like table stakes until you look at how most MCP servers actually authenticate today. The common pattern is a static bearer token in an environment variable, or worse, the MCP server forwarding whatever token the client handed it straight upstream. The MCP authorization spec explicitly forbids that passthrough: the token a server receives from a client must never be reused at an upstream API, precisely because it lets a compromised tool inherit the user's whole identity.

Doing this properly means the MCP server behaves as an OAuth 2.1 resource server, and the handshake has four concrete steps:

1. Discovery. The server publishes Protected Resource Metadata (RFC 9728) at the well-known endpoint, telling any conformant client where the authorization server lives and what it needs.
2. Registration. Authorizer supports Dynamic Client Registration and Client ID Metadata Documents, so agents do not need a human pre-registering every client.
3. Audience-bound issuance. The client requests a token naming the MCP endpoint as the RFC 8707 resource, and the authorization server mints an access token bound to that endpoint alone.
4. Verification. The server verifies the token itself, via JWKS or introspection, before running a single tool.

The payoff is containment. A token stolen from an agent's MCP session is useful only against that MCP endpoint, only within its attenuated scope, and only until its short expiry — not against the auth server, not against your cloud APIs, not forever. If you operate a deploy/rollback/logs MCP server that agents code against, that boundary is the difference between "an agent workflow broke" and "an agent workflow became a lateral-movement path." It also makes the tool surface a real contract: scopes declared in resource metadata are checkable in CI, so a renamed tool or a widened permission fails a build instead of silently breaking every agent that depended on it.

The first credential without a secret: RFC 7523 workload identity​

Delegation and MCP auth answer "how does an agent act with less than full power." Workload identity answers the prior question: how does the thing running the agent prove who it is in the first place, without a static secret that somebody has to rotate, leak, and revoke?

Authorizer 2.4 adds first-class service accounts on the OAuth client_credentials flow, and — the important part — lets those accounts authenticate with RFC 7523 JWT-bearer client assertions instead of a client secret. On Kubernetes, the assertion is a projected ServiceAccount token: the kubelet mounts a short-lived, audience-bound JWT into the pod, the workload presents it as its client_assertion, and Authorizer validates it against the cluster's JWKS. No secret is ever created, stored, or rotated. The pod's identity is its existence in the cluster, attested by the platform itself. Kubernetes TokenReview is supported as a fallback path, and SPIFFE JWT-SVID acceptance is in preview.

Two operational gotchas deserve attention, because both bite exactly the self-hosted operator this release courts. First, the SSRF guard: Authorizer refuses to fetch signing keys from just anywhere, so clusters still on the default kubernetes.default.svc issuer — an address that resolves only inside the cluster — must configure jwks_url to point at a reachable mirror of the key set. On EKS, GKE, and AKS this is a non-issue (public OIDC issuers with reachable discovery documents), but a private or air-gapped cluster needs the mirror set up deliberately. Second, the configured Kubernetes API server URL is security-sensitive: Authorizer sends its own ServiceAccount token there for TokenReview, so that host is a trusted host — pin it, do not point it at anything you would not hand a cluster credential.

Get those two right and the bootstrap story is genuinely secretless: a pod is born, the kubelet attests it, Authorizer believes the attestation, and the workload holds a credential with a minutes-long lifetime that it never had to fetch from a vault. For agent sandboxes that spin up per task and die minutes later, that is the only credential lifecycle fast enough to keep up.

What changes for a deploy-from-chat credential model​

Put the three pieces together and the credential model for agents stops looking like a pile of API keys and starts looking like an org chart — hence the title. Each principal has an identity, a bounded scope, and a recorded delegation path:

Map that onto the three things an ops agent does — deploy, diagnose, remediate — and each gets its own least-privilege shape. A deploy action carries a token exchanged for the deploy endpoint with exactly the release scope. A diagnose action carries read-only observability scope and cannot mutate anything even if the model misbehaves. A remediate action carries the narrowest write scope for the broken component, and the act chain records which agent session ordered it, so the 3 a.m. rollback has a signed paper trail instead of a shared key in five agents' environments.

Honest limits apply, and they are worth stating before anyone treats this as solved:

• act claims are informational by default. The delegation-chain splicing issue disclosed to the OAuth working group in February 2026 showed that a naive implementation lets a compromised intermediary mix tokens from different delegation contexts. Enforcement — reserved claims, may_act constraints, depth caps — is doing real work here, not the RFC alone.
• Every hop phones home. Each delegation is a round trip to the authorization server, which makes the AS a latency and availability participant in long agent chains rather than a sign-once gate.
• Cross-cluster identity is still rough. SPIFFE JWT-SVID support is in preview and tracks an expired draft, so workload identity beyond single-cluster Kubernetes OIDC remains the edge to probe before betting production deploys on it.

Agents join the org chart​

Step back and the shape of the release is a bet about where identity is going: users stop being the only principals that matter, and the auth server stops being a login page with an API attached. Service accounts become first-class subjects in the authorization layer, so a policy can say "this workload may restart that Deployment" the same way it says "this user may merge to main." Delegated agent tokens carry their own provenance. Short-lived, audience-bound, scope-attenuated credentials replace standing secrets at every layer an agent touches.

For teams self-hosting a PaaS with a deploy-from-chat roadmap, the adoption order writes itself. Start with workload identity — kill the static secrets in your agent sandboxes first, because every other improvement inherits the standing-key risk until you do. Then put your MCP deploy tools behind OAuth 2.1 with audience-bound tokens, so a leaked agent token stops at one endpoint. Then introduce token exchange for user-delegated actions, so "the agent did it" always comes with a chain showing on whose behalf and with what scope. Each step is independently shippable against Authorizer 2.4's changelog, and each one shrinks the blast radius the next step inherits.

The god-key era of agent auth worked while agents were demos. Now that they deploy, diagnose, and remediate against real infrastructure, they need what every other operator already has: an identity, a bounded scope, and a record of who told them to act. That is what it means to put agents on the org chart.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.