Uber Just Published the Agent Identity Blueprint. Now Let’s Talk About the Missing Control Plane.

Permit.io’s Substack

SubscribeSign in

Uber Just Published the Agent Identity Blueprint. Now Let’s Talk About the Missing Control Plane.<br>Verifiable agents, scoped tokens, and actor chains are the floor. Intent-aware authorization is the ceiling — and that's where agent security actually gets decided.

Or Weis<br>Jun 02, 2026

Share

Every once in a while, an engineering blog post lands and you can feel the market click one notch forward.<br>Uber’s post, “Solving the Identity Crisis for AI Agents”, is one of those pieces.<br>It is serious. It is technical. It is generous. And most importantly, it treats agent identity not as a slideware problem, but as infrastructure.<br>Uber walks through the real plumbing: agent registries, short-lived credentials, actor chains, MCP gateways, policy enforcement, audit trails, latency budgets, and developer adoption. This is exactly the level of maturity the industry needs right now.<br>So first: kudos to Uber.<br>Not just for building this. For sharing it.<br>Because the identity stack for AI agents is being invented in public. And the more high-quality architecture we get into the open, the faster the whole industry gets to something sane.<br>But I also think Uber’s post points to a deeper question:<br>Once we know who the agent is, how do we decide what it is allowed to become?

Subscribe

That is where things get really interesting.<br>The real identity crisis is not “who is this agent?” It is “what is this agent right now?”

The obvious version of agent identity sounds familiar:<br>Who owns this agent?<br>Which workload is it running in?<br>Which user delegated authority to it?<br>Which tools can it call?<br>All important.<br>But agents introduce a stranger problem.<br>A human identity is relatively stable. A service identity is relatively deterministic. An agent is neither.<br>An agent can change behavior because the model changed, the prompt changed, the retrieved context changed, a tool response changed, or because a poisoned document quietly smuggled in a new instruction.

That is why I wrote in The Agent’s Alibi that agent security has to care about premeditated intent .<br>Traditional IAM asks:<br>Who are you, and are you allowed to do this?

Agentic security has to ask:<br>Who are you acting for, what were you asked to do, what have you already done, what data have you seen, and does this next action still belong to the original mission?

This is the shift.<br>The agent’s identity is not just its name. It is the relationship between the delegating human, the workflow, the approved intent, the tools, the resources, and the runtime context.<br>Leave out any part of that chain and the agent can become a confused deputy with a very convincing alibi.<br>Uber’s actor-chain model is exactly the right primitive

One of the strongest ideas in Uber’s architecture is the actor chain.<br>In their design, each hop in a multi-agent workflow carries forward provenance: the human, the first agent, the next agent, and the downstream tool call. So when an action finally hits a sensitive system, the system can still answer the question:<br>Who is really behind this?<br>That is a big deal.<br>Because without actor chains, every downstream system sees some generic service account, some opaque token, or some “AI platform” identity. That is not accountability. That is fog.<br>The right model is closer to:<br>Human → Agent → Intent → Tool → Resource → Action → Destination<br>This chain is also where authorization becomes much more interesting than authentication.

A token can say, “this request came from Agent X.”<br>A control plane needs to decide, “Agent X, acting for Alice, during this workflow, with this stated purpose, should or should not be allowed to touch this specific data right now.”<br>That is the difference between identity and permissioned behavior.<br>At Permit, this is why we keep framing the problem as agent identity security, not just agent authentication.<br>Authentication tells you who showed up.<br>Authorization decides whether the next move still makes sense.<br>The architecture rhymes strongly with Permit’s PDP + OPAL philosophy

Uber’s architecture has a few key components: an Agent Registry, STS, AI Agent Mesh, MCP Gateway, AI Gateway, and downstream systems.<br>The pattern is familiar: separate trust foundation, enforcement points, policy decisions, and the systems being protected.<br>This is very close to the architecture we have been building around Permit for years.<br>At the core of Permit is the Policy Decision Point: a local authorization microservice that can run close to the service, gateway, API, or application making the authorization check.

The PDP answers a deceptively simple question:<br>Can this subject perform this action on this resource, in this context?<br>But the power comes from where that question is asked.<br>Not once during login.<br>Not once when a token is minted.<br>But continuously, at runtime, near the thing being protected.<br>Then there is OPAL, the Open Policy...