Access Control for AI Agent Workflows: Uber's Zero Trust Architecture
This article discusses the challenges of implementing robust access control for multi-agent AI workflows, where agents delegate tasks and interact with internal tools. It highlights Uber's internal architecture, which extends its Zero Trust model to propagate agent identity and provenance across these complex workflows, and aligns with Auth0's recommendations for capability-scoped permissions and task-scoped credentials. The core problem addressed is that AI agents don't fit traditional user or service account access models due to their autonomous, multi-step nature.
Read original on InfoQ ArchitectureThe Challenge of AI Agent Identity and Permissions
Traditional access control models are ill-suited for AI agents. Unlike human users with bounded sessions or backend services with predictable code paths, AI agents can perform multi-step tasks, delegate to other agents, and invoke internal tools on behalf of a user without direct human interaction for every single action. This necessitates a new approach to ensure security, auditability, and adherence to the principle of least privilege in complex agentic workflows.
Uber's Zero Trust Architecture for AI Agents
Uber has developed an internal architecture that extends its existing Zero Trust framework to manage access for AI agent systems. This architecture introduces several key components designed to handle agent registration, identity propagation, and policy enforcement across multi-hop workflows:
- Agent Registry: Stores the allowed relationships between an agent and its hosted workloads.
- Security Token Service (STS): Issues short-lived JSON Web Tokens (JWTs) for each hop, verifying agent relationships.
- AI Agent Mesh: The network of interacting AI agents.
- Model Context Protocol (MCP) Gateway: Mediates access from the agent mesh to internal systems, performs tool access checks, and redacts sensitive data.
- AI Gateway/AI Guard: Likely acts as an entry point and initial policy enforcement layer.
Key Design Choice: Per-Hop Token Exchange
Instead of relying on a single, long-lived user credential or service account, Uber's system uses a per-hop token exchange. Each agent requests a new, short-lived (minutes TTL) token from the Security Token Service. These tokens include specific `Audience` claims and leverage SPIRE-issued workload identities, conceptually based on OAuth 2.0 Token Exchange but customized for agent identity and provenance. This significantly limits the blast radius of a compromised token.