Zalando’s incubator released the open-source Agentic Identity Broker on April 10, 2025, a tool designed to solve OAuth delegation for autonomous AI agents — first highlighted in a Show HN thread that garnered 17 points. It provides a secure middleware layer, allowing agents to act on a user's behalf without ever handling raw OAuth tokens directly.
Project: Agentic Identity Broker | License: Apache 2.0 | Language: Go
Protocol: OAuth 2.0 Device Authorization Grant | Source: GitHub
How It Works: Delegation, Not Storage
The broker acts as a secure intermediary between an AI agent and third-party OAuth-protected services (like Google Calendar or GitHub). Instead of an agent requesting and storing a user's access token—a major security risk—the agent requests a short-lived, scoped delegation token from the broker.
The broker, which holds the master OAuth tokens after initial user consent, validates the agent's request against predefined policies. If approved, it issues a delegation token valid only for the specific API call, timeframe, and scope the agent needs. This means a compromised agent cannot exfiltrate a reusable token for broader access.
The Security Shift for Agentic Workflows
Current agent frameworks like LangGraph or CrewAI require developers to manually manage OAuth token flow, often leading to tokens being embedded in environment variables or agent memory. This creates a persistent attack surface.
The Agentic Identity Broker introduces a zero-trust model for agent permissions. Each agent request is individually authorized. The system uses the OAuth 2.0 Device Authorization Grant flow for the initial, secure user login, a pattern proven in CLI tools and IoT devices. Early discussion on Hacker News noted this directly addresses the "token leakage problem" as agents move from prototypes to production.
Bottom line: It shifts security from protecting static credentials to authorizing individual agent actions.
How to Try It: Local Deployment
The project is designed for local or private cloud deployment, putting the user in control of their token vault. Setup is a three-step process:
- Clone and configure:
git clonethe repository and set environment variables for your OAuth client IDs and secrets from target services (e.g., Google Cloud Console). - Deploy the broker: Run
docker-compose upto start the broker and its associated PostgreSQL database for token storage. - Integrate an agent: Modify your agent's code to call the broker's API for a delegation token before calling a service like the Gmail API. The repository includes example API call structures.
"Technical context: The Device Flow"
The broker uses the OAuth 2.0 Device Authorization Grant (RFC 8628). Here's the user sequence:
Pros and Cons: The Trade-offs
Advantages:
- Eliminates Token Leakage: Agents cannot be tricked into revealing primary OAuth tokens.
- Fine-Grained Control: Policies can restrict agents to specific API endpoints or data fields.
- Audit Trail: All delegation events are logged by the broker.
- Provider Agnostic: Works with any OAuth 2.0-compliant service.
Limitations:
- Deployment Overhead: Requires running and securing your own broker instance.
- Agent Modification Required: Existing agents must be refactored to use the broker's API.
- Initial Setup Complexity: Configuring OAuth apps with multiple providers is necessary.
Alternatives and Comparisons
The main alternative is manual token management within agent frameworks. A more direct competitor is Cloudflare's Zero Trust Access Tokens, but it's a cloud service, not self-hosted software.
| Feature | Agentic Identity Broker | Manual Token Handling | Cloud Service (e.g., Cloudflare) |
|---|---|---|---|
| Token Security | High (delegated, short-lived) | Low (persistent, long-lived) | High (managed) |
| Deployment | Self-hosted | N/A (within app) | Cloud-hosted |
| Audit Logging | Built-in | Custom implementation | Provider-dependent |
| Setup Complexity | Medium-High | Low | Low-Medium |
| Cost | Free (infrastructure only) | Free | Subscription-based |
Who Should Use This
Use this if: You are developing multi-agent systems for production that require access to user data via OAuth (e.g., personal assistant agents, automated workflow tools). It's critical for applications where agent code may interact with untrusted data or plugins, a common pattern in AI engineering.
Skip this for now if: You are building single-user, local prototypes or agents that only use API keys (not user OAuth). The deployment complexity outweighs the benefit for early-stage experimentation. For simple chatbots using a single service, the provider's SDK (like the Google Client Library) remains sufficient.
The Bottom Line
The Agentic Identity Broker is a specialized but vital tool for hardening production AI agents. It solves a concrete security problem—OAuth token lifecycle management—that becomes a critical vulnerability as agents gain more autonomy and data access. While it adds initial development overhead, it provides the architectural foundation for trustworthy, user-delegated agentic systems.
This move towards formalizing agent identity and authorization signals the industry's shift from building capabilities to implementing safeguards, a necessary step before widespread agent deployment.
Top comments (0)