AI Agent Identity: Scoped, Revocable Access for Agents

What it is

A way for an agent worker to act as itself: its own credential, its own scope, its own audit trail, rather than borrowing a human's session or sharing a generic service account that could have been anyone. The umbrella term the industry has settled on is agentic identity, or non-human identity (NHI), and the mechanic underneath most implementations is scope attenuation: every hop in a delegation chain narrows what the next hop can do, never widens it, so an agent calling an agent calling a service can't accumulate more authority than it started with.

Fig. 1

A human authorizes once; every delegation hop after that carries a narrower, short-lived credential than the one before it, and the whole chain still resolves to a responsible person in the log. Hover a box to trace its connections. Original diagram, not a reproduction. Click to enlarge.

Why you need it (in a large team)

The cheap alternative, an agent reusing a human's login or a shared service account, works right up until something needs to be undone. At that point every action the agent ever took looks identical to every action every other holder of that credential took, and there's no way to narrow the blast radius of a bad run to just that run.
Uber names the failure mode directly. Existing identity models "don't capture agent delegation relationships," and "execution context (originating user, intermediate agents) is dropped across agent hops," so an agent calling an agent calling a service left nobody accountable at the end of the chain. At Uber's scale, with Cortana alone running more than 20,000 sessions a day, that isn't a hypothetical, it's a certainty waiting to happen on some session, some day.
The other cost is coarser but just as real. A shared credential grants everything that credential can do, not just what the current task needs, so every agent run inherits the same maximum blast radius regardless of how small the task actually is. Giving each agent worker its own scoped identity is what makes it possible to grant only what one task needs and revoke it the moment the task ends.

How it should work

A human or a system authorizes an agent once, and everything downstream of that authorization should get narrower, never wider. Uber's Agent Registry binds every agent to a Kubernetes workload, issues it a SPIRE-signed workload credential, and has a Security Token Service mint short-lived, audience-scoped JWTs for every hop, each one carrying an actor chain back to a responsible human. P99 latency on that token exchange stays under 40 milliseconds, evidence that scoping every hop doesn't have to mean a slow one. Block's version reaches for the same outcome through a different mechanism: short-lived, narrowly-scoped delegated tokens plus a consent control plane, built specifically so audit trails can tell an agent's action apart from the human's own.

Grab pushes the same idea further into infrastructure rather than tokens alone. Its Palana runtime gives each agent its own Kubernetes namespace, holds no direct credentials inside that namespace at all, routes every outbound call through a mediated proxy, and can kill any agent centrally if it misbehaves. Mercari solves a narrower version of the same problem: an internal key server issues ephemeral OAuth-derived credentials instead of static API keys, with auto-renewal for agents that run long and dedicated support for CI-based review, so there's never a static secret sitting around to leak. Zalando's Identity Broker, still on its roadmap rather than shipped, aims at the same target from the delegation side: brokering OAuth2 chains between agents and MCP servers so a scoped credential, not a standing one, is what makes it possible to let an agent run a task unsupervised in the first place.

Where it fits into a software factory

This is what makes every other pattern in this series safe to leave unattended. The MCP gateway can enforce policy on a call, but only if it can tell which agent, and which human behind that agent, actually made the call. A background agent can be trusted to open a PR or touch a live system precisely because its identity, not a borrowed one, is what shows up in the log when something goes wrong. Skip this layer and every other pattern still runs, it just runs with an accountability gap sitting underneath all of it, invisible until the day someone needs to answer "who did this."

What you should look for when deciding on one

This is one of the genuinely contested patterns in the corpus, not a settled best practice with laggards. Most of the companies here converge on the same instinct: constrain scope tightly and attribute every action to a human, whether through Uber's actor-chain JWTs, Block's consent plane, or Grab's credential-free namespaces. Ramp reaches the opposite conclusion on purpose: its agents get the same tool access an engineer would get, a sanitized production database replica, Datadog, LaunchDarkly, Buildkite, Slack, Linear, no restricted subset, because Ramp's stated position is that agents need the same context as software engineers, not a narrower one. Neither camp is obviously wrong. The constrain-and-attribute side is betting that narrow, revocable scope is worth the machinery it takes to build; Ramp is betting that a restricted agent is a less useful one, and that disposable, sandboxed environments plus review are where the actual safety work should happen instead. The question to ask isn't "does this vendor support agent identity," it's which side of that bet your organization is actually making, and whether your infrastructure matches it:

If you're constraining, whether scope narrows on every hop or just the first one. An agent that can re-delegate its own full grant to a sub-agent has built an escape hatch, not a control.
Whether the credential is short-lived by default or long-lived until someone remembers to rotate it. Mercari's ephemeral keys and Uber's per-hop tokens both treat a static secret as the failure to design out.
If you're granting broad access instead, what's substituting for the scoping you're skipping. In Ramp's case that's a sanitized replica rather than production data, plus a separate review pass on every PR, not the absence of any control at all.