Uber has published one of the clearest enterprise responses yet to the AI agent identity crisis: an extension of Zero Trust built for software agents that delegate work, call other agents, and touch production systems. In a new engineering post, the company lays out a three-part design — Agent Registry, AI Agent Mesh, and a Security Token Service — that keeps identity, authorization, and audit lineage intact across multi-step agent workflows.
Uber shipped a concrete design while standards groups are still drafting
6,000+
engineers at Uber
Cited in the reporting context provided by the editor
500+
agentic skills
Cited in the reporting context provided by the editor
Uber’s new engineering write-up matters because it is not a generic warning about autonomous systems. It is a detailed architecture description from a large operating company that says traditional identity models break when agents act as intermediaries, delegate tasks, and trigger multi-step workflows across internal systems. The post frames the problem in practical terms: without clear lineage, attribution gets lost, and auditing, compliance, and trust all degrade. That is the core of the AI agent identity crisis Uber is trying to solve.
The timing is notable. Open standards work around agent identity, delegation, and inter-agent authorization has been moving across groups such as the OpenID Foundation and the Model Context Protocol ecosystem, but Uber is describing something deployed enough to write about in production architecture terms. The company’s scale gives that more weight than a lab demo. Uber says it operates with more than 6,000 engineers and more than 500 agentic skills, which turns identity from a future concern into an immediate systems problem.
This is also one of the first detailed architecture papers from a major non-AI-lab company focused narrowly on agent identity rather than model performance. Readers have seen plenty of agent demos. Far fewer have seen a large enterprise explain how an agent should prove who initiated a request, what chain of delegation occurred, and what downstream systems are allowed to trust.
Uber is describing a production-oriented identity pattern for agents before a single dominant standard for agent-to-agent trust has fully settled.
“Traditional identity models were built for humans and static workloads, not AI agents acting as intermediaries across multi-step workflows.”
Uber Engineering, “Solving the identity crisis for AI agents”
Why traditional identity breaks when agents delegate work
Uber’s diagnosis is straightforward and hard to argue with. Identity systems in most enterprises were designed around two broad classes of actor: humans and relatively static machine workloads. Agents do not fit neatly into either bucket. They receive intent from a user or another system, make decisions, call tools, invoke other agents, and continue a chain of work that may span several services. In that model, the immediate caller is often not the real source of intent.
That creates three failures at once. First, agents act as intermediaries, so a downstream service may only see the last hop and miss the original user or upstream agent that set the task in motion. Second, multi-step processes lose attribution, making it difficult to answer basic questions after the fact: who asked for this, which agent delegated it, and what authority was supposed to carry forward? Third, auditing, compliance, and trust break without clear lineage. A policy engine can only enforce what it can verify.
This is where the AI agent identity crisis becomes more than a catchy phrase. In a human workflow, a person logs in and takes an action. In an agent workflow, one request can fan out into several delegated actions, each with different scopes and destinations. If identity is flattened to the last service account in the chain, security teams lose the context needed to apply least privilege or investigate misuse.
If downstream systems only trust the immediate caller, they can miss the original user intent and the full delegation chain behind an agent action.
| Traditional model | Agent workflow reality | What breaks |
|---|---|---|
| Human logs in directly | User asks an agent, which calls other agents and tools | Original intent is obscured |
| Static service account calls one API | Dynamic chains span multiple services and agents | Attribution gets lost across hops |
| Authorization checks immediate caller | Policy needs full request lineage | Audit and compliance weaken |
The architecture: Agent Registry, AI Agent Mesh, and a Security Token Service
Uber says its answer is not to replace Zero Trust, but to extend it. The architecture has three named components. The Agent Registry is a central directory of registered agents with cryptographic identity. The AI Agent Mesh is the communication layer for agent-to-agent interactions. The Security Token Service, or STS, issues dynamic, short-lived JWTs and acts as the trust broker across the chain.
That division of labor is important. The registry gives agents durable identity and discoverability. The mesh provides a controlled path for communication rather than ad hoc calls between tools and services. The STS handles the hard part: minting tokens that are scoped to specific destinations and short enough in lifetime to reduce replay risk. Uber is effectively saying that agent systems need the same rigor cloud platforms brought to service identity, but adapted for delegation-heavy workflows.
The design also avoids a common mistake in enterprise agent deployments: treating the agent itself as a monolithic principal with broad standing permissions. Uber’s model is more granular. Identity is registered centrally, communication is mediated, and authorization material is issued dynamically for each step. That is a more credible answer to the AI agent identity crisis than simply giving an orchestration layer a powerful service account and hoping logs will reconstruct the rest later.
Uber extends Zero Trust with dynamic token issuance and lineage-aware delegation instead of relying on static service identities.
| Component | Role | Why it matters |
|---|---|---|
| Agent Registry | Central directory of registered agents with cryptographic identity | Creates a verifiable identity layer for agents |
| AI Agent Mesh | Agent-to-agent communication layer | Controls and structures delegated interactions |
| Security Token Service | Issues dynamic, short-lived JWTs and brokers trust | Enables scoped, auditable authorization per hop |
The key mechanism is multi-hop JWT propagation
The most consequential part of Uber’s design is the mechanism it calls multi-hop JWT propagation. Each hop in an agent workflow gets its own JWT. Those tokens are scoped to specific destinations, and their short time-to-live is meant to prevent replay attacks. The token also carries a verifiable history list that preserves the chain of delegation. Uber’s example is simple and revealing: [user1, oncall-agent, investigation-agent].
That means a downstream system does not just see the last agent in the chain. It sees the complete request lineage. Uber says downstream MCP Gateway and other systems can evaluate the verified history and enforce policies on the intent of the entire chain, not only the immediate caller. That is a major shift in how authorization is applied. In older models, the last service identity often becomes the only identity that matters. In Uber’s model, the chain itself becomes part of the security decision.
This is the clearest technical answer in the article to the AI agent identity crisis. It preserves attribution across delegation without requiring every downstream system to invent its own custom audit stitching. It also looks a lot like a practical combination of token exchange and audit trail, which is exactly the area standards bodies have been trying to formalize for agent ecosystems.
{
"sub": "investigation-agent",
"aud": "mcp-gateway",
"exp": 1760000000,
"lineage": ["user1", "oncall-agent", "investigation-agent"],
"scope": ["read:incident", "run:diagnostics"]
}“Policies are enforced on the verified intent of the entire chain, not just the immediate caller.”
Uber Engineering, “Solving the identity crisis for AI agents”
Why the STS comparison to AWS matters
Uber’s Security Token Service is conceptually familiar to anyone who has worked with cloud IAM. The closest analogy is AWS STS: a broker that issues temporary credentials instead of relying on long-lived secrets. That makes Uber’s choice notable because it borrows a proven cloud-security pattern and adapts it to agent chains, where one actor may need to prove both its own identity and the delegated context it received from upstream.
The difference is the point. AWS STS is built for cloud principals assuming roles and obtaining temporary credentials for infrastructure access. Uber’s STS is designed for agent → agent → API chains, where the authorization question is not only can this principal access this resource? but also under whose intent, through which delegation path, and for which exact destination? That is a narrower and more modern problem than classic service-to-service auth.
For enterprise architects, this makes Uber’s post easier to reason about. The company is not inventing a magical new trust model from scratch. It is extending a familiar Zero Trust and short-lived-credential pattern into the domain where the AI agent identity crisis is most acute: delegated, multi-hop workflows that need both security and auditability.
Think of Uber’s STS as AWS STS adapted for delegated agent workflows, with lineage preserved inside the authorization flow.
| System | Common purpose | Key difference |
|---|---|---|
| AWS STS | Issue temporary credentials | Built for cloud principals and role assumption |
| Uber STS | Issue short-lived JWTs | Built for agent-to-agent delegation with lineage |
The MCP Gateway mention is a real enterprise adoption signal
One small phrase in Uber’s post carries outsized significance: the company says downstream MCP Gateway and other systems can see the complete request lineage. That matters because it confirms Uber is using Model Context Protocol natively in this architecture, not merely discussing agents in abstract terms. MCP is still being adopted, and it is far from universal, but a major enterprise naming it directly in an identity design is a meaningful signal.
The signal is not that MCP has won. It has not. The signal is that enterprises are beginning to wire identity and authorization decisions into MCP-adjacent infrastructure rather than treating protocol choice as separate from trust. If MCP gateways become common entry points for tools and internal systems, they will need to understand not just tool schemas and context exchange, but also who initiated a request and what delegation chain brought it there.
Uber’s design suggests that protocol adoption and identity design are converging. That is where the AI agent identity crisis stops being a standards debate and becomes an implementation question for platform teams: what metadata travels with an agent request, which gateway verifies it, and how are policies enforced consistently across tools, APIs, and downstream services?
What this means for OpenID and agent identity standards
Uber’s post does not replace standards work, but it does raise the bar for it. The company has described a pattern that looks very close to the combination many standards groups are circling: token exchange for delegated authority, short-lived credentials, and a portable audit trail that survives multiple hops. In practice, Uber appears to have shipped an enterprise version of the problem statement that standards bodies are still trying to make interoperable.
That creates pressure in two directions. Standards groups now have a concrete reference point from a large operating environment. Enterprise buyers, meanwhile, have a sharper set of questions for vendors claiming agent security. Can their systems preserve lineage across hops? Can they scope credentials per destination? Can downstream gateways enforce policy on the full chain rather than the last caller? Those are more useful questions than asking whether a platform merely supports agents.
The broader takeaway is simple. The AI agent identity crisis is not about whether agents can authenticate at all. It is about whether delegated intent remains verifiable as work moves across agents, gateways, and APIs. Uber’s answer is one implementation, not the final standard. Still, it is one of the clearest signs yet that agent identity is moving from whiteboard theory into production infrastructure.
Uber has turned agent identity from an abstract standards problem into a concrete enterprise architecture pattern.
Frequently asked questions
Uber published an engineering post describing an extension of Zero Trust for AI agents built around an Agent Registry, AI Agent Mesh, and Security Token Service. The design is meant to preserve identity, delegation, and audit lineage across multi-step agent workflows.
Uber says each hop gets its own short-lived, destination-scoped JWT carrying a verifiable history list, so downstream systems can evaluate the full request chain rather than only the immediate caller. The company explains this in its engineering write-up.
It confirms that Uber references an MCP Gateway in the architecture, which is a meaningful enterprise adoption signal. For protocol context, readers can review the Model Context Protocol specification.
Primary sources
- Uber: Automate design specs — Uber
- Pragmatic Engineer: How Uber uses AI for development — Pragmatic Engineer
- Adaptive Engineer: How Uber saved 140,000 hours monthly — Adaptive Engineer
- Model Context Protocol specification — GitHub
- StartupHub.ai summary of Uber tackles AI agent identity — StartupHub.ai
Last updated: May 22, 2026. Related: Identity Provenance.
