Zalando Open-Sources AIB for Scoped OAuth Delegation to AI Agents

Summary:Zalando Incubator has open-sourced the Agentic Identity Broker (AIB) under the MIT License. AIB gives AI agents scoped and revocable access to MCP services without exposing the user's underlying OAuth tokens. Users grant consent per agent and service, while the broker stores third-party tokens in encrypted form and performs RFC 8693 token exchange at the gateway. The v0.1 release is reportedly running in production, connecting hundreds of agents to dozens of internal and external MCP servers. Pl

---

The core problem: agents should not receive user tokens

Zalando Incubator has open-sourced the Agentic Identity Broker (AIB), an OAuth 2 delegation layer for AI agents. A user can authorize a specific agent to access a specific MCP service with scoped and revocable permissions, without exposing the underlying third-party OAuth token to the agent itself.

This addresses a common privilege amplification problem in agentic tool use. Passing a Bearer Token directly to a model or agent runtime means that prompt injection, a malicious tool, a supply-chain compromise, or context leakage can potentially expose the token's full authority. AIB moves the credential boundary outside the model. An independent broker stores long-lived credentials, performs token exchange, and centralizes approval and audit records.

The project is released under the MIT License. According to its authors, v0.1 is running in production at Zalando and connects hundreds of agents with dozens of internal and external MCP servers.

Architecture: OAuth delegation, encrypted storage, and RFC 8693 exchange

A typical request path involves four roles:

1. The user grants consent for a designated agent and service.
2. The AIB stores the third-party OAuth token in encrypted form and binds the authorization to a particular agent, target service, and permitted scopes.
3. The gateway performs RFC 8693 OAuth 2.0 Token Exchange when the agent makes a request, converting the user's authorization into a suitable downstream access token.
4. The MCP server only implements its tools and does not need to implement the full OAuth 2.1 flow. The broker or gateway handles token exchange and auditing.

The important property is not merely that the agent has fewer permissions, but that the original third-party token never enters the agent's visible execution environment. Even if an agent can manipulate the gateway into invoking a high-risk tool, it cannot directly read or export the long-lived credential held by the broker.

Token isolation does not, however, eliminate permission abuse. A token issued through exchange may still be recorded or misused by a malicious tool. Scope granularity, approval policy, downstream MCP behavior, and audit quality therefore remain essential parts of the security boundary.

Why the OBO model comes first

AIB currently focuses on the On-Behalf-of (OBO) pattern, in which a human delegates a task to an agent that acts on that user's behalf. This fits enterprise assistants, customer-service workflows, and internal automation because the delegation chain retains an identifiable human principal.

The practical benefit is that authorizations can be correlated with a user, a specific agent, and a specific tool call, while revocation can terminate subsequent delegation. The cost is a nontrivial authorization lifecycle. Token refresh, revocation, employee offboarding, role changes, credential rotation, and audit retention cannot be delegated to the agent's own configuration.

Headless-agent delegation, in which a machine invokes another agent, is on the roadmap. It introduces a different set of questions: which organizational principal a machine represents, who may authorize downstream access, and how delegation is propagated through a workload chain. Workload identity mechanisms such as SPIFFE may eventually provide a stronger trust anchor than static client credentials for this mode.

Engineering trade-offs

AIB consolidates authorization logic that would otherwise be distributed across MCP services, but it also becomes a new high-value control point:

• Centralized credentials reduce distribution, but increase blast radius. Agents no longer hold raw tokens, yet compromise of the broker could affect many services. Key isolation, partitioning, rotation, and restrictive database permissions remain essential.
• Token exchange adds network and processing overhead. Gateways must validate exchange requests, select the target audience, and obtain short-lived tokens. At high agent concurrency, refresh storms, caching, and rate limiting become important.
• Revocability depends on state consistency. Revoking a user's grant must invalidate exchanged-token caches, issued credentials, and downstream sessions through a defined propagation path.
• Centralized auditing improves observability but can become a data leak. Logs should identify the principal, agent, tool, target service, and decision, while excluding raw tokens, sensitive arguments, and full request bodies.
• OAuth 2.1 still has to be enforced by every resource server. AIB removes authentication complexity from MCP tools, but it does not replace scope, audience, audience-restricted token, and least-privilege enforcement upstream.

Intent-based authorization is also planned. The goal is to move from allowing a particular tool call toward allowing it only when a business intent and contextual constraints are satisfied. If intent classification is performed by a model without deterministic constraints, it creates another indirect prompt-injection surface. A safer design is to feed the inferred intent into a policy engine that remains auditable and decides whether a token may be issued or exchanged.

Deployment guidance

For local evaluation, the repository can be started with just compose-up-detached. A production integration should add at least the following controls:

• Define separate scopes for every agent, service, and tool instead of sharing a broad client.
• Protect third-party tokens with an external secrets manager or envelope encryption, and rotate exchange credentials.
• Validate RFC 8693 requests, target audiences, and anti-confusion parameters at the gateway to prevent token redirection.
• Require human approval or policy gating for high-risk tools, with time-limited, action-bound approvals.
• Propagate revocation to token caches, in-flight requests, and downstream sessions.
• Redact audit records and enforce access control, retention periods, and tamper-resistant storage.
• Define fail-closed behavior for refresh failures, user revocation, downstream outages, and partial authorization.

AIB is most useful for teams that already operate multiple MCP services and want agents to act on behalf of users without building an OAuth delegation layer themselves. It does not replace an identity provider, and it cannot by itself solve prompt injection, tool-output poisoning, or vulnerabilities in MCP servers.

Maturity assessment

The project's contribution is not a new OAuth protocol, but a deployable combination of OAuth 2.1 and RFC 8693 tailored to agent identity. Its reported production use demonstrates practical feasibility. However, v0.1 and the available disclosure do not include throughput, token-exchange latency, failure recovery, revocation-propagation delay, key-rotation details, or security-evaluation results.

It is therefore best treated as an open-source infrastructure component worth piloting in enterprise agent platforms, rather than a standardized, universally interoperable identity layer. As IETF agent-identity work converges, AIB's interfaces may still change; adopters should avoid coupling business code tightly to its current internal data model and workflow.

---

Source: Hacker News AI Feed (2026-11-06)

— END —

Tags: #AIB Follow #OAuth 2.1 Follow #RFC 8693 Follow #MCP Follow #Agent Identity Follow