Skip to content

SYSTEM Cited by 2 sources

Agentic Identity Broker

Definition

The Agentic Identity Broker is a Zalando-built, MIT-licensed, open-source component (github.com/zalando-incubator/agentic-identity-broker, docs at agenticidentitybroker.dev) that lets AI agents act on behalf of users across third-party systems without the agent ever holding the users' provider tokens. It records which user delegated which permissions to which agent, holds the resulting third-party sessions (a token vault), and exchanges tokens when an agent calls a tool. It is the canonical wiki instance of the identity-broker-for-agent-delegation pattern. (Sources: sources/2026-08-13-zalando-agentic-engineering-at-zalando-a-snapshot, sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker)

Naming note. The 2026-08-13 snapshot referred to this component as the "Identity Broker" while it was still forthcoming. The 2026-09-24 open-sourcing post gives it its shipped name, Agentic Identity Broker. This page is the canonical entry for both.

It does not replace an identity provider: it reuses existing investment and can either mint tokens itself or proxy an existing upstream OAuth 2.0 authorization server. It needs no user management of its own — it relies on a reverse proxy for authentication.

Where it fits

At its core, Zalando's Kubernetes-based agent platform combines kagent (agent runtime) + agentgateway (AI/MCP gateway) with the Agentic Identity Broker for delegated access. Platform abstractions are Kubernetes CRDs (Agent, MCP server); kro translates them into lower-level kagent/agentgateway resources and into configuration of the identity infrastructure, auto-spawning central MCP gateways and agent instances.

At runtime, agentgateway + the broker act as a gate that splits the world into two spheres: agents and tools. The agent can access tool providers on behalf of its user if the agent's permissions and the user's consent allow it — but it never receives a provider token.

The delegation and consent model centers on three objects (Source: sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker):

Object What it is
Permission set Named, administrator-defined, human-readable group of OAuth 2.0 provider scopes.
Grant Revocable, optionally time-limited delegation from a user to an agent.
User session Holds the encrypted provider tokens for one user + one third-party service; shared by all agents the user has delegated to.

Consent names a business capability, not a scope string. Zalando deliberately does not expose OAuth 2.0 scopes as the unit of consent — "provider scope vocabularies are inconsistent and often too coarse for a person to evaluate." Consent reads like "reading repositories." Unlike Cross-App Access (XAA), which aims to remove per-vendor consent screens, Zalando keeps a central consent screen so a user can reduce an agent's effective permissions when uncomfortable granting everything it asks for. Effective permission is the intersection of the user's authority and the agent's own allowed capability (least privilege).

Front-loading: keep OAuth ceremonies out of agents/MCP servers

A core design decision is to keep OAuth 2.0 ceremonies out of both agents and MCP servers to reduce their complexity. The broker front-loads token acquisition so that all required third-party sessions exist before the agent needs them:

  1. A browser-based portal initiates a standard OAuth 2.0 flow with the broker.
  2. This triggers the consent screen and ensures third-party sessions are established.
  3. The broker either issues a token or delegates issuance to an upstream authorization server.
  4. Where no user presence can be proven via a browser, the broker supports impersonation for chat bridges and other privileged clients (a Google Chat bridge, GitHub apps receiving webhooks, schedulers) that carry a user attestation.

The resulting user-agent token is used to call the agent, which passes it on as-is in downstream tool calls; agents are configured to use agentgateway as their MCP endpoint.

Runtime token exchange (agent never sees the provider token)

For each tool call (Source: sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker):

 Agent ──user-agent token──▶ agentgateway (trusted gate)
                                   │ validate token
                                   │ ask broker to exchange it (RFC 8693)
                                   ▼
                               Agentic Identity Broker
                                   │ check live grant + permission set
                                   │ mint/refresh provider access token
                                   ▼
   provider token returns ONLY to the gateway ──▶ gateway swaps the
   Authorization header ──▶ forwards request to the target (e.g. GitHub MCP)

The broker exchanges the user-agent token for an access token issued by the target's OAuth 2.0 infrastructure (via RFC 8693 token exchange), refreshing if needed. That credential returns only to the gateway, which replaces the Authorization header before forwarding.

Worked example. A user asks an agent in Google Chat to summarize their open GitHub PRs. The Chat bridge impersonates the user toward the broker and obtains a user-agent token. When the agent calls the GitHub MCP server through agentgateway, the gateway asks the broker to exchange that token for a GitHub token — succeeding only if the user granted the agent a permission set covering reading repositories. The agent returns the summary without ever seeing the GitHub token.

Asymmetric revocation (caveat). "A revoked or expired grant blocks future exchanges, but it cannot revoke a provider token that has already been issued." Short token lifetimes are the only mitigation named.

Beyond token exchange: layered authorization

Token exchange is a coarse access decision (the user's choices ∩ the agent's maximum boundary). To authorize individual tool calls, Zalando integrated Open Policy Agent (OPA) into agentgateway through its external processing (ExtProc) extension point, reusing existing OPA investment connected to enterprise access management. Both the broker's exchange policy and the gateway's tool-call policy must permit a request — the out-of-band policy shape.

Roadmap: central tool approvals (users approve tools in the broker's consent UI, ExtProc enforces, independent of where the agent runs), then — because approvals invite rubber-stamping / approval fatigue — CIBA (Client-Initiated Backchannel Authentication) in the broker for high-risk transactions (e.g. Okta Verify), plus intent-based access control. To escape STS-per-hop latency, they plan to adopt SPIFFE to separate the attestation of the agent's identity from the human's (workload identity).

Why it matters

On-behalf-of delegation across many heterogeneous OAuth 2.0 infrastructures is the recurring hard problem when agents call tools (and each other) as a user: each hop must carry provable, scoped, short-lived authority rather than a broad long-lived credential. Centralizing this in a broker + token vault keeps the delegation chain auditable (central audit point) and keeps individual agent/MCP-server authors out of the auth business — the confused-deputy defense is structural: the provider token lives at the gateway, never in the agent.

Last updated · 766 distilled / 2,225 read