What happened
In a November 6, 2026 engineering article, Uber engineers Sean Tout, Max Zhurovich, and Adi Raghavendra describe a security framework developed for agentic systems. Uber says agents dynamically reason over user input, webpages, documents, tools, and other agents, then may turn that reasoning into real-world actions. That creates risks including prompt injection, tool and memory poisoning, goal hijacking, behavioral drift, and hallucination-driven actions. Traditional identity and authorization controls can establish who may access a resource, but do not determine whether a proposed action is appropriate in context.
Uber’s framework spans provisioning-time validation, runtime enforcement, and continuous assurance. At provisioning, the Uber AI Registry records an agent’s identity, ownership, persona, permitted intents, constraints, dependencies, and risk tier. Uber says its Argus platform analyzes source code, prompts, configurations, dependencies, endpoints, and tool-invocation paths. It identifies security weaknesses and derives structured intents from an agent’s implementation so declared behavior can be compared with observed capabilities. Uber also evaluates third-party MCP servers and tools through static and dynamic analysis, software composition analysis, reputation signals, and semantic inspection of descriptions and metadata. It says language models undergo security evaluation before deployment, while monorepo scanning looks for unregistered agents and unauthorized MCP endpoints.
At runtime, the registry defines policies; AI Guard evaluates interactions and proposed actions against them; and Agent Guard hooks, LangFx, or the AI Guard SDK enforce the resulting verdict at checkpoints. The checks consider the agent’s persona, permitted intents, semantic constraints, user context, and multi-turn session history. Uber calls this semantic, behavior-based enforcement: an action can be denied even if the agent and user have valid credentials, when the action is outside the agent’s purpose or inconsistent with the conversation.
Uber says runtime checks must meet strict latency budgets because they sit in the execution path. AI Guard uses small specialized models hosted locally, including models fine-tuned for individual guardrail functions. These execute in parallel and can use in-memory vector search for semantic matching. The company says it moved away from uniform thresholds toward continuous, per-agent calibration, balancing protection against false blocks, latency, cost, developer experience, and agent autonomy. It also invested in automated onboarding and guardrail assignment to make the secure path easier for developers.
What the archive adds
New Runtime’s earlier coverage of Uber’s CISO on building an insider threat program for AI (October 16, 2026) focused on organizational controls around insider risk. This is a new, more technical event from Uber: it details a runtime architecture for evaluating whether an agent’s actions fit its purpose and session context.
Trend signal
This supports agent security moves to runtime boundaries: Uber places enforcement in the agent’s execution path and evaluates actions against defined constraints and context, rather than relying on prompts or access checks alone. The account is an implementation example, not independent evidence of effectiveness across deployments.
Why now
Uber says agents’ growing autonomy and access to production tools and sensitive data exposed the limits of conventional controls. The company presents its architecture as a response to the need to govern behavior continuously as agents, capabilities, and attack techniques evolve.
Why it matters
For teams building agents, the design shifts security review from a one-time permission decision to a lifecycle responsibility. A valid token or allowed API call cannot prove that an action is consistent with a user’s request; a behavioral contract and contextual runtime check can add that missing question. Uber’s example also makes the operational tradeoff explicit: controls that block too much may be bypassed, while checks that add unpredictable latency may not fit production workflows. Teams can use the architecture as a checklist—inventory agents and tools, state intended capabilities, enforce at action checkpoints, and retain observability—without assuming Uber’s internal components are available to them. The account offers a useful pattern, but teams still need to test its accuracy, latency, and failure modes in their own systems.
Limits and uncertainty
Uber describes its own architecture and implementation choices; the account does not establish independent security effectiveness or quantify rates of prevented attacks, false positives, or developer adoption. It does not give latency figures, inference costs, model names, deployment scale, or a comparative evaluation against other approaches in the described material. The framework’s named components are Uber systems and integrations, so the account alone does not show how readily another organization could reproduce them or what operational overhead they require.
Reader takeaway
Treat agent security as a runtime and lifecycle problem, not just a permission check or a prompt-writing task. Define what each agent is meant to do, check proposed actions against that purpose and the live session context, and measure the resulting latency and false blocks before relying on the controls in production.