Zalando open-sources a broker that gives AI agents scoped, revocable access

Zalando, the European fashion retailer, has released the Agentic Identity Broker, an MIT-licensed project that manages how AI agents get permission to act for a user. The code is in the zalando-incubator organisation on GitHub, and a Show HN post on 6 November 2026 introduced it. The details below come from the project's README and architecture document; they describe what the authors say it does.

What it does

The README describes the broker as managing delegation chains for on-behalf-of flows, bridging separate OAuth2 setups and providing a token vault. A user sees a consent screen and grants an agent specific permissions on services the README names as Google, GitHub, Databricks and Linear. The agent holds a single user token, not the credentials for each service.

The broker is meant to sit in the call path behind a gateway. The architecture document describes a separate gateway extension process that exchanges tokens and asks the broker for tool approvals. The README lists audit logging in structured JSON, redaction of sensitive values and a fail-closed design.

The problem it targets

The README argues that frameworks such as FastMCP can implement the full OAuth 2.1 flow the MCP specification requires, but then every MCP server you deploy needs that configuration, secure storage and, in effect, its own authorization server. With the broker and a gateway, the authors say, a server only has to provide tools; the OAuth steps, token vaulting and token translation happen centrally, and agents can reach many servers through one channel.

It lists five uses: internal MCP servers, MCP servers a SaaS company offers to customers (with a consent record of which agents were used), hosted agents, delegation without the user present (for example a Slack or Google Chat bridge acting for a user), and a central approval step before an agent sends an email or shares a document.

What is not known

The authors say Zalando uses the project in production internally for several MCP servers. They give no figures for users, agents, latency or cost. They also say it is under active development and that they are coding in the open to see whether others find it useful. The roadmap names agent-to-agent token exchange, intent-based authorization and user-facing activity logs as future work, so those are not available now.

The architecture document says the setup shown assumes a trusted authentication proxy in front of the broker, and that deployments must restrict administrative access and stop clients forging proxy headers. That is operator work the project leaves to you. It also needs PostgreSQL, and its encryption setup uses AWS KMS and DynamoDB.

What commenters said

The thread had 13 points and 3 comments when I read it, so treat it as early. One commenter asked why plain OAuth delegation is not enough, who beyond large enterprises needs this, and what day-to-day cases it solves, and suggested the site spend more time on the problem than on the mechanics. Another quoted the README's consent-and-audit claims and asked for the reasoning behind them. A third asked how the broker handles transitive cases, where one agent calls another. I did not see replies from the authors in the thread.

What to do with it

Treat this as a reference design. If you run, or plan, several internal MCP servers, list which credentials each agent holds and who can revoke them. Then check whether your gateway can call out for token exchange and approvals, as this project's design assumes. A pilot with one low-risk tool, such as read-only access to a ticket system, would show whether the consent screen and audit trail are workable for your staff.