Zalando's broker lets you revoke one agent without disconnecting all of them

An agent can lose its permission to use your account without taking every other agent down with it. Zalando’s Agentic Identity Broker gives that distinction an actual control: revoke the agent’s grant, or terminate the underlying service session. The choice depends on whether the problem belongs to one agent or to the service session they share.

The delegation model keeps one active grant per user and agent. A grant names the permitted sets of actions and can have an expiration time. The session holds the service tokens, and multiple delegated agents can use that same session. Ending it removes access for the dependent agents; the interface shows which ones will be affected before you proceed.

That avoids turning every agent breakup into an account-wide separation. Permission sets also have human-readable names, such as repository reading, so the consent screen can explain what the agent wants without asking the user to decipher a pile of OAuth scopes. A consent screen with a vocabulary (fancy that) gives the user something to judge before the agent receives its grant.

Zalando’s repository describes the project as “currently in active development” and says it uses it internally in production for several MCP servers. That’s the team’s deployment report, rather than an independent security assessment. The same README describes central approval before actions such as sending email or sharing documents, with the approval record kept outside whichever agent interface happens to be in use.

The introduction puts a gateway in the request path. It exchanges an agent token for the service token through RFC 8693 token exchange. The broker keeps and refreshes the underlying credentials. Agent developers get to stop reimplementing that storage and refresh work in each integration, which is plumbing most people only notice after it leaks.

Human login still comes from your existing identity infrastructure. A trusted reverse proxy authenticates the user and passes their identity in a header; the broker enforces the delegation. Calling this an identity broker doesn’t make that header magically trustworthy. The system you put in front of it remains part of the security boundary.

Encryption is mandatory at startup. The documentation says there is “no plaintext mode or fallback” and binds encrypted values to the service they belong to. Its production backend uses AWS KMS with cached intermediate keys in DynamoDB. The development backend holds a raw key in the process environment, with an explicit warning against using it for real credentials.

The local tutorial offers a useful way to inspect the exchange. Docker Compose starts a sample agent, mock OAuth providers and a mock MCP tool. The sample client displays its broker-token claims alongside the claims the tool receives after the gateway exchanges the token. You can inspect the handoff without connecting a real service account.

That test stack uses an in-memory store and simulated user authentication. The instructions warn, “Do not expose it to other machines.” Eight service images get built on the first run, so the quick experiment has a little more luggage than a command-line toy. The mock tool returns decoded claims for inspection, and the tutorial cautions that its decoder does not verify signatures.

More shared tools could make per-agent consent useful well beyond the first integration, provided revocation survives the full deployed request path. Zalando still lists user-facing activity logs among its roadmap topics. Users can withdraw access today according to the documentation, while the planned activity view still needs work before it can explain those agents’ actions to them.

Permission to leave is already included.