# How to adapt Uber's production AI agent security model

Uber combines registration, runtime behavior checks and replay. The practical lesson is to verify why an agent wants an action, even when its credentials allow it.[1]

Uber published a production security framework for AI agents on November 6, 2026. It adds behavioral checks to ordinary identity and authorization: an action must match the user's request, the agent's declared purpose, the user's role and the preceding session evidence.[1]

The framework has three layers. Provisioning records ownership, permitted intents, tools and risk. Runtime hooks inspect prompts and proposed actions. Continuous assurance keeps traces for replay, red-team testing and policy improvement.[1]

Teams do not need Uber's internal platforms to use the design. Start with an inventory and a narrow behavioral contract, place checks before sensitive tools, preserve evidence from request to action and test bypasses. Model-based checks can add latency and false blocks, so high-risk actions still need deterministic limits and human confirmation.[1]

## Why ordinary authorization is insufficient

[Uber's engineering team published the framework on November 6, 2026 [1]](https://www.uber.com/us/en/blog/securing-ai-agents/). An agent and its user can both have valid access while a proposed action still conflicts with the user's request. Indirect prompt injection, poisoned tool descriptions or a mistaken plan can all produce an authorized but inappropriate call.

A useful policy therefore asks two different questions. Access control asks whether the caller may use a resource. Behavioral authorization asks whether this action belongs to the agent's purpose and follows from the current request and session history.

Keep deterministic boundaries around both layers. A model can classify intent, but code should still cap transaction values, restrict destinations, validate schemas, enforce tenant boundaries and require confirmation for irreversible actions.

## Provision an explicit behavioral contract

Uber records each agent's identity, owner, persona, permitted intents, constraints, dependencies and risk tier in a registry.[1] A smaller team can begin with a versioned file or database record, provided the deployment reads it and rejects missing ownership or policy.

List every model, MCP server, tool and data source. For each tool, specify allowed operations, resource scope, required evidence and whether a person must approve the call. Tool descriptions are untrusted input because an agent may use them when deciding what to do.

Compare the declared contract with the code and observed calls. Uber describes automated analysis of source, prompts, configuration, endpoints and tool paths. Teams without that platform can combine static configuration checks, integration tests and runtime inventory logs.

## Place checks at action boundaries

A guard that only scans the user's first prompt cannot see a later document, tool result or memory item that redirects the agent. Check again before retrieval of sensitive data, privilege changes, messages, payments, deletion, deployment and other consequential calls.

Uber's design evaluates the agent's persona, allowed intents, semantic constraints, user context and multi-turn history.[1] Log which rule allowed or denied the call and retain the evidence that linked it to the user's request.

Model-based decisions introduce cost, latency and variable output. Uber uses smaller specialized models close to the execution path and calibrates them by agent risk.[1] A practical alternative is to reserve semantic checks for risky boundaries and use deterministic validation elsewhere.

## Build an evidence chain and replay loop

Prompt provenance links an action back to the user request and the intermediate evidence that influenced it. This helps reviewers separate an instruction from an untrusted page or tool result.[1]

Store prompts and retrieved content according to privacy and retention rules. Redact secrets, separate tenants and limit who can replay sessions. A complete trace can itself contain credentials, personal data and adversarial instructions.

Turn incidents and near misses into repeatable tests. Replay the relevant context against the current policy, add variants and verify that the action is blocked or routed to confirmation without preventing the intended task.

## A practical rollout checklist

- Inventory every production agent, owner, model, tool, credential and reachable data store.
- Choose one agent with bounded tools and write its allowed intents, forbidden actions and confirmation points.
- Enforce tenant, destination, amount and operation limits in code before adding model-based checks.
- Add a policy hook immediately before each sensitive tool call and fail closed when policy data is missing.
- Record the user request, relevant evidence, proposed action, policy version and verdict without storing unnecessary secrets.
- Test direct and indirect prompt injection, poisoned tool metadata, stale memory, role changes and reordered tool results.
- Measure false allows, false blocks, added latency, guard cost and how often people override a verdict.
- Expand only after the owner reviews failures and the team can replay and explain every sensitive decision.

## Limits and trade-offs

- Uber describes its internal architecture and lessons, but it does not publish controlled detection rates for every guardrail.
- Semantic policies can miss novel attacks or block legitimate requests, and model updates can change both rates.
- A registry becomes stale unless deployments and tool calls are checked against it automatically.
- Evidence retention improves investigations but increases privacy, access-control and storage obligations.
- Small local classifiers reduce network latency, but teams must still patch, monitor and evaluate those models.
- Behavior checks do not replace sandboxing, least privilege, output validation, rate limits or human approval.

## Frequently asked questions

- What is behavioral authorization? It checks whether a proposed action fits the user's request, the agent's stated purpose and the current session, in addition to ordinary resource permission.
- Should every tool call use an LLM guard? No. Use deterministic checks where the rule is exact, and reserve semantic judgment for boundaries that require context.
- What should an agent registry contain? At minimum: owner, purpose, users, risk tier, model, tools, data scope, credentials, permitted intents and approval rules.
- How do we test indirect prompt injection? Place adversarial instructions in documents, web pages, tool metadata and memory, then verify that the agent cannot cross a sensitive action boundary.
- Can this framework make an autonomous agent safe? It reduces risk and improves investigation, but no published evaluation proves that it catches every failure. Keep authority narrow and require people for high-consequence actions.

## Sources

- [[1] Uber Engineering: Securing AI Agents, November 6, 2026](https://www.uber.com/us/en/blog/securing-ai-agents/)
- [[2] OWASP: Agentic AI Threats and Mitigations](https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/)
- [[3] NIST: AI Risk Management Framework Generative AI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence)