Agentic Identity Broker: Using OAuth to Solve Identity Delegation for AI Agents

AI agents are starting to operate external services on behalf of users, but one fundamental question still has no elegant answer: how exactly does an agent obtain access permission? Agentic Identity Broker, which appeared on Hacker News, offers one approach—extending OAuth's delegation mechanism to the AI agent scenario so that permission grants become auditable and revocable.

Agents Need Identity, and OAuth Wasn't Designed for It

The OAuth protocol was born in the context of "a user authorizing a third-party application to access resources," with the classic scenario being "log in to some website with your Google account." When an agent calls APIs such as email, calendars, and code repositories on a user's behalf, an autonomous intermediary enters the chain. Handing the user's token directly to the agent is a common shortcut, at the cost of overly broad permissions, poor traceability, and difficulty revoking them. Agentic Identity Broker is positioned precisely to fill this missing layer: it acts as an identity intermediary between agents and resource servers, where the user grants limited permissions to the intermediary, and the agent then accesses resources indirectly through it.

The significance of this design is that it turns "what an agent can do" from invisible runtime behavior into an explicit, configurable authorization policy. For teams that need multiple agents to work together, whether permission boundaries are clear is often more critical than the capabilities of the agents themselves.

The core of OAuth 2.0 is delegated authorization: the resource owner (user) issues an access token to the client through an authorization server, and the client uses the token to access the resource server without sharing the password at any point. The standard defines four grant types (authorization code, implicit, client credentials, resource owner password), of which the authorization code flow combined with PKCE is currently the most recommended pattern. Tokens typically carry scope (permission range) and expires_in (validity period), and can be renewed via a refresh token.

However, OAuth's trust model assumes the client is a static application pre-registered by a developer, whose behavior is largely determined at the time of authorization. AI agents are different: they autonomously decide which APIs to call, in what order, and how many times, resulting in a behavioral space far larger than that of traditional clients. OAuth has no built-in mechanism to express "under what conditions, at what frequency, and which specific resources this agent may access"—which is exactly why an additional identity layer is needed in the agent scenario.

How the Identity Middle Layer Works

Following the conventional structure of the OAuth delegation model, brokers of this kind typically assume three roles: requesting authorization from the user, holding and refreshing tokens, and issuing short-lived credentials according to policy when an agent initiates a request. The agent never needs to touch the user's long-lived credentials, and the broker becomes the single control point for permission flow.

The direct benefit of this pattern is that revocation becomes simple—revoke the authorization at the broker, and all agents that depend on it immediately lose access. Auditing also becomes feasible: every agent request can be mapped to a specific authorization decision, rather than a vague "the user is logged in." For enterprise environments, this traceability is often a prerequisite for agents to enter production systems.

It should be noted that the project's specific policy expression capabilities, token lifecycle design, and whether it supports fine-grained scopes are not elaborated in the current Show HN post. Community feedback on the post is also quite limited, and no discussion has yet yielded practical experience.

In the OAuth ecosystem, the broker pattern is not a new concept. For example, OAuth 2.0 Token Exchange (RFC 8693) allows a service to exchange a received token for another token with a different audience; OpenID Connect's third-party identity federation also often relies on brokers. Enterprise identity platforms (such as Auth0 and Okta) likewise offer token broker capabilities for cross-domain trust propagation.

What sets Agentic Identity Broker apart is that it changes the broker's delegation target from "another application" to "an autonomous agent." This means the broker must not only issue short-lived credentials but may also need to evaluate at runtime whether an agent's request intent conforms to the user's preset policy—which is already close to the responsibility of a policy decision point (PDP). Understanding this helps judge the functional boundary between such components and existing IdPs: the broker is a supplement, not a replacement; it addresses the dynamic authorization problems specific to agents.

Why This Problem Matters Now

Agentic AI is being deployed far faster than identity infrastructure can keep up. Developers are building agents that can complete tasks automatically while continuing to rely on old methods such as manually configuring API keys or directly reusing user tokens. These practices are fine for small-scale trials, but once the number of agents grows and tasks involve sensitive data, permission management becomes a bottleneck.

Agentic Identity Broker represents a directional judgment: the identity problem of agents should be solved at the protocol layer, rather than every application reinventing the wheel. This is similar to the logic by which OAuth once solved the "password sharing" problem—exposing credentials to third parties has never been good design.

What Remains to Be Seen

At present, the only confirmable information is the project's publication on Hacker News itself; both points and comment counts are very low, indicating the project is still at an early stage. Whether components like identity brokers are ultimately adopted depends on their integration cost with existing identity providers (IdPs), the degree of adaptation to agent frameworks, and whether developers are willing to introduce another layer on top of OAuth. These are all questions the project needs to answer going forward.

The value of following this direction is that it pushes permission governance for AI agents from "remediation after the fact" toward "design in advance." As agents move from demos to production, this shift in design awareness may carry more weight than the success or failure of any single project.