Uber Shares Agent Security Practice: Secure AI's Three-Layer Defense Design
Uber Engineering shared its internal agent security system, Secure AI. In addition to checking agent permissions, it also verifies whether specific actions match the user's request. It consists of three parts: pre-launch review, runtime constraints, and continuous testing, but it did not disclose quantitative protection results. Before launch, the AI Registry records the agent's purpose, owner, allowed behaviors, and risk level, while Argus analyzes the code, prompts, and tool-calling paths; at runtime, AI Guard makes judgments based on the user's request, role, session context, and agent purpose, and uses small local specialized models to run checks in parallel to control latency. The team adopted a shadow mode that observes without blocking first and calibrates agent by agent, while acknowledging that protection can only reduce risk and that effectiveness against novel prompt injection remains difficult to predict.
Why read this
AI score 59
The original article breaks down the three-layer defense design of Uber's internal Secure AI and points out the practical deployment challenge of balancing rule strictness and flexibility.
Topics
View original posthttps://t.co/XFWteI3jUO
View original
https://t.co/XFWteI3jUO
Body · AI translation
Uber's Agent Security Practices: Having Permission to Execute Does Not Mean It Aligns with User Intent
From @UberEng, another quality share as always: Uber's internal security system Secure AI doesn't just check whether an agent has permission, it also checks whether the specific action matches the user's request. It combines pre-launch review, runtime constraints, and continuous testing, but it has not published quantitative protection results. https://t.co/iyVjrkQAge
Why traditional permissions are not enough
Agents read web pages, documents, and tool results, then decide the next step on their own. Even if the account, tools, and API calls are all legitimate, it can still be steered by malicious instructions in external content and perform operations the user never requested.
Therefore, beyond authentication and authorization, another question must be answered: why did this action happen, and does the basis come from the user or from untrusted content?
How the three layers of protection work together
1. Define boundaries before launch. The AI Registry records the agent's purpose, owner, allowed behaviors, and risk level; Argus analyzes code, prompts, and tool invocation paths, comparing declared purpose with actual capabilities. Third-party tools, MCP servers, and models also undergo security checks.
2. Verify actions at runtime. AI Guard makes judgments based on the user request, role, session context, and agent purpose, and then runtime components enforce them. The key design is to trace high-privilege actions back to the request the user actually made, preventing instructions in web pages or documents from impersonating authorization. To control latency, Uber uses small local specialized models to run multiple checks in parallel.
3. Continuously calibrate after launch. The system tracks actions, tool calls, and protection judgments, replays historical interactions to test new rules, and then adjusts policies based on red-team testing. Prompts and responses are stored only when necessary, with measures for handling sensitive information, access restrictions, and expiration-based deletion.
The hard part is not detection, but trade-offs
Rules that are too strict block normal work, while rules that are too loose miss attacks. Uber adopts a shadow mode that observes first without blocking, and calibrates agent by agent rather than relying on a uniform threshold.
The team also acknowledges that protection can only reduce risk and raise the cost of attack, and that effectiveness against new types of prompt injection remains hard to predict. The full text does not disclose interception rates, false-blocking rates, or latency data, so it should be viewed as deployment experience, not as complete proof of effectiveness.