Skip to content

ZALANDO 2026-09-24

Read original ↗

Agentic Platform: Open-Sourcing the Agentic Identity Broker

Summary

Zalando open-sourced (MIT license) the Agentic Identity Broker, a component that lets AI agents act on behalf of users across third-party systems without the agent ever holding the user's provider tokens. It is the identity core of an agent platform Zalando is building on Kubernetes from OSS components — kagent (agent runtime) + agentgateway (AI/MCP gateway), wired together via kro from Kubernetes CRD abstractions (Agent, MCP server). The broker records which user delegated which permissions to which agent, holds the resulting third-party sessions (a token vault), and does an OAuth 2.0 token exchange (RFC 8693) at tool-call time so the raw provider credential returns only to the gateway, never to the agent. Authorization goes beyond token exchange: OPA is integrated into agentgateway via its external processing (ExtProc) extension point to authorize individual tool calls against Zalando's enterprise access-management system. This is the follow-up to the sources/2026-08-13-zalando-agentic-engineering-at-zalando-a-snapshot|2026-08-13 "Agentic Engineering at Zalando" snapshot, where the broker was still "forthcoming."

Key takeaways

  1. Three magnified microservice-era identity problems. Agentic identity is three old problems at once: (a) identify agents through their own machine identity, (b) give agents access to many third-party systems that each issue their own tokens, and (c) make access decisions on the intersection of the user's and the agent's permissions. "None of these problems are fundamentally new; we have seen them before with microservices, and as an industry we have partly ignored them."

  2. On-behalf-of is where enterprise value sits — not autonomy. Most enterprise value is in on-behalf-of flows where a human triggers an agent directly or indirectly (a GitHub PR, a Google Chat message, a Linear ticket comment). The advantage: enterprise access management and user permissions already exist. Effective permission = the intersection of the user's authority and the agent's own allowed capability. (Source names the permission-boundary diagram: "a tool call lies inside both the user's authority and the agent's allowed capability".) Canonical instance of OBO agent authorization.

  3. Semi-autonomous / impersonation for chat bridges. Between interactive sessions and fully autonomous agents sit semi-autonomous cases with no direct user presence but some user attestation — a Google Chat bridge, a GitHub app receiving webhooks, a scheduler. These privileged bridge apps are allowed to impersonate users toward agents, so a downstream MCP server still applies the user's effective permissions and the agent acts on the user's behalf.

  4. The broker records delegation + holds sessions + exchanges tokens. 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. MIT-licensed, developed in the open.

  5. The delegation & consent model has three objects.

  6. Permission sets — named, administrator-defined, human-readable groups of OAuth 2.0 provider scopes.
  7. Grants — revocable, optionally time-limited delegations from a user to an agent.

  8. User sessions — hold the encrypted provider tokens for one user and one third-party service, shared by all agents the user has delegated to. Consent names a business capability ("reading repositories"), not a raw OAuth scope string — "provider scope vocabularies are inconsistent and often too coarse for a person to evaluate." A central consent screen lets users reduce an agent's effective permissions.

  9. Front-load token acquisition; keep OAuth ceremonies out of agents and MCP servers. A core 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 all required third-party sessions exist before the agent needs them. A browser portal initiates a standard OAuth 2.0 flow with the broker → triggers consent → ensures third-party sessions exist → issues a token (or delegates issuance upstream). Where no browser user-presence exists, impersonation for chat bridges is supported.

  10. Runtime = a gate splitting agents from tools; the agent never sees a provider token. For each tool call the agent sends its user-agent token only to the trusted gateway. Agentgateway validates it and asks the broker to exchange it for an access token issued by the target's OAuth 2.0 infrastructure (refreshing if needed). That credential returns only to the gateway, which replaces the Authorization header before forwarding to the target. Worked example: a user asks an agent in Google Chat to summarize open GitHub PRs → the Chat bridge impersonates the user → agentgateway asks the broker to exchange the user-agent token for a GitHub token (succeeds only if a grant covers "reading repositories") → agent returns the summary without ever seeing the GitHub token.

  11. Revocation is asymmetric. "A revoked or expired grant blocks future exchanges, but it cannot revoke a provider token that has already been issued." — a first-class caveat of the token-exchange model.

  12. Beyond token exchange: per-tool-call authorization with OPA/ExtProc. Token exchange is a coarse access decision (user's choices ∩ agent's max boundary). To go finer, Zalando integrated Open Policy Agent into agentgateway through its external processing (ExtProc) extension point, reusing existing OPA investment wired to enterprise access management. "Both broker exchange policy and gateway tool-call policy must permit a request" — layered authorization / the out-of-band policy shape.

  13. Central tool approvals — and their limits. Next up: central tool approvals so the platform doesn't rely on local agents making the right choices — users approve tools in the broker's consent UI; the ExtProc extension next to agentgateway enforces the decision, independent of where the agent runs (locally, on the platform, or on another vendor's platform). But "approvals are a crutch: many users will rubber-stamp them once approval fatigue sets in." For high-risk transactions they want CIBA (Client-Initiated Backchannel Authentication) in the broker (e.g. approval via Okta Verify), plus intent-based access control.

  14. STS-per-hop latency drives a move toward SPIFFE. Today the model leans on plain OAuth 2.0 access tokens that tie the user's and agent's identities together. From running their microservice identity infra they know a central STS called on every hop can become expensive or prohibitive in latency, so they plan to extend the model with SPIFFE to separate the attestation of the agent's identity from that of the human (workload identity axis).

Standards leaned on (recorded as prose, not minted)

The post credits fast-tracked identity standardization driven by MCP: - RFC 8693 — OAuth 2.0 Token Exchange (the broker's core exchange primitive). - RFC 9728 — OAuth 2.0 Protected Resource Metadata. - Identity Assertion JWT Authorization Grant / Cross-App Access (XAA) (IETF draft) — focuses on removing per-vendor consent screens; Zalando contrasts it with their choice to keep a central consent screen so users can reduce an agent's permissions. - SPIFFE + IETF WIMSE WG for machine identity, and the newer AI Identity Management System (AIMS) draft tying them together.

These are canonical standards but appear single-source here as named terms and are not in _taxonomy.md; per the taxonomy gate they are recorded as prose + tags (RFC 8693 maps into the existing concepts/oauth-token-lifecycle page), not minted as new pages.

Systems / concepts / patterns extracted

Caveats

  • Asymmetric revocation (takeaway 8): a grant revocation cannot claw back an already-issued provider token; short token lifetimes are the only mitigation the post names.
  • Approval fatigue (takeaway 10): central approvals degrade to rubber-stamping; the post is candid that this is a crutch, pushing toward CIBA for high-risk actions.
  • STS-per-hop latency (takeaway 11): the OAuth-token-per-hop model has a known latency ceiling from their microservice experience; SPIFFE is the planned relief, not yet shipped.
  • Draft standards. XAA / WIMSE / AIMS are IETF drafts; Zalando "will adopt such features when they make sense," so parts of the target model are directional, not implemented.
  • Announcement register. This is an open-sourcing post, but the architecture (delegation-object model, runtime token-exchange flow, OPA/ExtProc layering) is well above the scope bar.

Source

Last updated · 766 distilled / 2,225 read