Agent Identity and Access Management for Production AI Systems

uber · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.2 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Agent identity and access management

Uber needed identity attribution and auditability when agents acted across multi-hop workflows on behalf of users.

Constraints:

Architecture

Uber extends its Zero Trust architecture into an AI Agent Mesh. Agents are registered on the internal Agent platform, run inside SPIRE-identified workloads, request per-hop JWTs from a Security Token Service, and carry full actor-chain attribution through agent-to-agent and MCP gateway calls. AI Guard handles redaction and risk controls, MCP Gateway enforces tool authorization, downstream systems receive verifiable user-agent lineage, and observability captures each hop for audit and policy review.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  user-initiator[User initiator] --> oncall-agent[Oncall Agent]
  agent-platform[Agent platform] --> agent-registry[Agent Registry]
  agent-platform --> ai-agent-mesh[AI Agent Mesh]
  spire-workload-identity[SPIRE workload identity] --> security-token-service[Security Token Service]
  agent-registry --> security-token-service
  oncall-agent --> security-token-service
  security-token-service --> oncall-agent
  oncall-agent --> investigation-agent[Investigation Agent]
  investigation-agent --> security-token-service
  investigation-agent --> mcp-gateway[MCP Gateway]
  ai-guard[AI Guard] --> mcp-gateway
  mcp-gateway --> downstream-systems[Downstream systems]
  downstream-systems --> audit-observability[Audit observability]
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
User initiator Human requester on whose behalf agents act. Oncall Agent
Agent platform Internal platform for composing, deploying, and operating production agents. Agent Registry, AI Agent Mesh
AI Agent Mesh Data plane where agents communicate with each other and internal systems. Agent platform, Oncall Agent, Investigation Agent
Agent Registry Verifies which agents are authorized to run on which workloads. Agent platform, Security Token Service
SPIRE workload identity Cryptographic workload identity proving the compute environment. Security Token Service, Oncall Agent, Investigation Agent
Security Token Service Mints short-lived audience-scoped JWTs and embeds actor-chain lineage. Agent Registry, SPIRE workload identity, Oncall Agent, Investigation Agent
Oncall Agent Initial agent acting on behalf of the on-call engineer. User initiator, Security Token Service, Investigation Agent
Investigation Agent Downstream agent that continues the workflow with preserved provenance. Oncall Agent, Security Token Service, MCP Gateway
AI Guard Redaction and safety layer for gateway interactions. MCP Gateway
MCP Gateway Tool gateway that verifies JWTs, checks policies, and redacts sensitive data. Investigation Agent, AI Guard, Downstream systems
Downstream systems Observability, source control, CI, and other internal systems protected by policy. MCP Gateway, Audit observability
Audit observability End-to-end view of actor chains, authorization decisions, and agentic traffic. Downstream systems

Data flow

A user triggers an agent workflow. Each agent obtains workload identity from SPIRE, asks STS for a short-lived JWT scoped to the next-hop audience, passes that token to the next agent or gateway, and repeats token exchange at each hop. The JWT actor chain accumulates user and agent lineage, letting MCP Gateway and downstream systems enforce tool policies and produce complete audit logs.

3 supporting quotes
“Within the Agent Mesh and for outbound calls (such as to MCP tools), AI agents rely on JWT tokens minted by the Security Token Service for authentication. #### STS (Security Token Service) Token minting for AI agents is handled by STS.”article, stated
“Every workload first fetches its own cryptographically signed workload SVID (SPIFFE Verifiable ID) from SPIRE.”article, stated
“* Full contextual attribution. STS manages the token exchange at every step and embeds the fully attested actor chain into the token. This allows the MCP Gateway or downstream system to have the full context of the request;”article, stated

Why this architecture

Uber chose per-hop tokens with full actor-chain provenance because generic service identity hid the real user and intermediate agents. Short-lived, audience-scoped JWTs limit replay risk, SPIRE verifies the workload, and centralized STS/A2A tooling makes the secure path easy enough for thousands of internal agents.

3 supporting quotes
“systems it interacted with could only see a generic service identity at each hop. And the tool invocation appeared to downstream systems as “some service called an API,” even though the real actor was a specific agent acting on behalf of a specific user. As agentic”article, stated
“* Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes.”article, stated
“This client automates the STS JWT exchange and propagation of the actor chain, ensuring the secure path is also the easiest path for developers to implement A2A calls.”article, stated

Scale

Alternatives considered (roads not taken)

Use broad long-lived service credentials

Rejected because: Uber needed scoped per-hop attribution and replay resistance for agent workflows.

“Rather than relying on broad, long-lived service credentials, the STS acts as a dynamic trust broker that issues short-lived, scoped tokens for every hop.”article, stated

Let each agent manually implement provenance exchange

Rejected because: Existing agents were inconsistent, so Uber built a standardized A2A client for token exchange and propagation.

“ensuring every agent consistently performs STS token exchanges and preserves the actor chain. To eliminate these gaps, we shifted from manual compliance to an automated, secure-by-default developer experience.”article, stated

Patterns

safety-policy-enforcement (identity)

Agent actions carry actor-chain attribution for audit and policy enforcement.

“Accountability, the ability to answer “who did what, when and why” is critical for auditing, compliance, and executive trust.”article, stated

tool-use-orchestration (identity)

Agents interact through tool gateways that need authorization and redaction.

“Both agents feed into an MCP Tool Gateway (handling tool authorization and redaction), which then connects to Observability Systems and Source Control/CI (pull requests and tests).”article, stated

Tradeoffs

How to represent agent delegation.

Chose single-hop short-lived JWTs with actor-chain claims over generic service identities or reusable user credentials.

Rationale: Per-hop tokens preserve provenance, limit replay, and let downstream policy evaluate both human and agent identity.

“A token issued for Agent A to call Agent B can’t be intercepted and replayed to call a database or another service”article, stated

How to migrate existing agents onto identity controls.

Chose standardized A2A client and phased migration over manual compliance by every agent team.

Rationale: The A2A client automates token exchange and actor-chain propagation while teams refactor legacy calls.

“This client automates the STS JWT exchange and propagation of the actor chain”article, stated

Gotchas (what bit them)

Traditional service identity drops the original user and intermediate agents.

Root cause: Existing human/workload identity models do not describe agency relationships.

Resolution: Uber added short-lived tokens carrying actor-chain provenance.

“Execution context (originating user, intermediate agents) is dropped across agent hops.”article, stated

Evaluation

Uber tracks token-exchange latency and auditability characteristics.

Metrics: P99 latency · audit completeness

“The solution enables thousands of production agents to operate with complete traceability while maintaining sub-40ms P99 latency for token exchanges, providing comprehensive audit logs and fine-grained access control across agent workflows.”summary, stated

Outcomes

The design supports production-grade agent operation at scale.

“In early 2025, the company built an internal Agent platform that allows teams to compose, deploy, and operate production-grade agents at scale.”article, stated