An agent can take an action nobody asked for while the user, the agent, the tool, and every API call are all legitimately allowed. Identity already said yes. The action is still wrong.
On 6 November 2026, Sean Tout, Max Zhurovich, and Adi Raghavendra published how Uber handles that case: Securing AI Agents: Lessons From Real-World Deployment. Uber Engineering shared it on X. When an enterprise asks us to secure agents that can already change records, move money, or call production tools, this write-up is the model. The product names in it are Uber’s. The behavioral contract, the runtime check, and the trace are what we install.
Quick answer
Write a behavioral contract before the agent can act. Check each privileged action against that contract, what the user asked, and the session so far. Replay the check on real traffic before it blocks anyone. Uber runs this as three layers: provisioning-time validation, runtime enforcement, and continuous assurance. Identity still says who may act. The remaining decision is whether this action should happen. Explicit intents reduce the damage from a manipulated instruction and give up some autonomy. On agents that can change a customer record, move money, or touch production, we make that trade. Uber published no false-block rate and no latency number.
Best for: security, platform, and AI leads whose agents already call tools, and who do not have a platform organisation the size of Uber’s. Honest limit: Cipher did not build Uber’s system. We do not sell Argus, AI Guard, LangFx, or a fleet of fine-tuned guardrail models. We install the parts of this model that a smaller team can run, in accounts you own.
Last updated: 9 November 2026. Cipher Projects is an Australian-led engineering studio. We are not an incident-response firm, and we do not issue certificates.
What goes wrong when every credential is valid?
The agent reads untrusted content and can turn that reading into a real action. The content comes from users, webpages, documents, tools, and other agents. Uber names the risks that follow: prompt injection, tool and memory poisoning, goal hijacking, behavioral drift, and hallucination-driven actions. Part of the attack sits in what the request means, after the API has already allowed the caller.
Authorisation still answers who may act, and which resource they may touch. It cannot see that a refund tool ran because a webpage told the agent to, rather than because the customer asked. That is the case in Uber’s post. Every principal is legitimate, and the action is not what the user requested.
Public guidance already says not to leave enforcement inside the prompt. The OWASP AI agent security cheat sheet treats user text, retrieved documents, and tool output as untrusted. AWS’s agentic AI lens says a boundary written only in a system prompt will not hold. Uber’s post is a production account of what they built once agents with valid credentials were already acting.
Why do guardrail products and policy engines miss it?
Before building this layer, Uber evaluated commercial AI guardrail platforms and ordinary policy engines. The platforms detected direct prompt injection, jailbreaks, unsafe content, and sensitive-data exposure. The policy engines decided who could reach a tool or a data store. Uber kept both. Neither stopped an agent from doing an allowed thing for a reason that did not come from the user.
They stopped writing a fresh detection rule for every new way to phrase an injection. A prompt and a proposed action are checked against the agent’s persona, its permitted intents, its constraints, the user’s context, and the turns already in the session. A technique with no signature can still be denied when the action sits outside those boundaries.
What are the three layers, and what do we install?
Uber calls the whole design Uber Secure AI. It covers the life of an agent in three layers. We keep the layers. Argus, AI Guard, and LangFx are Uber’s product names.
| Layer | What Uber runs | What we install |
|---|---|---|
| Provisioning | The AI Registry holds identity, owner, persona, permitted intents, constraints, dependencies, and risk tier. Argus reads code, prompts, configs, dependencies, endpoints, and tool paths, then compares the declared contract with what the agent can actually do. Third-party MCP servers get static and dynamic analysis, composition analysis, reputation checks, and a read of the tool description. Models are reviewed before deployment. A monorepo scan finds agents and MCP endpoints that never registered. | One record per agent, with those same fields, stored where the owning team already tracks systems. We read the code, prompts, and tool paths with them and draft the intents for them to edit. We read a third-party tool’s description and permissions before it is connected. We do not bring the monorepo scanner. Unregistered agents are an inventory job. If the company has several repos and a no-code builder, the scanner Uber runs would not see them anyway. |
| Runtime | The registry is the policy administration point. AI Guard is the decision point. Agent Guard hooks, through LangFx or the AI Guard SDK, are the enforcement points. Small specialised models run locally, in parallel, with in-memory vector search where a semantic match is needed. Uber will not call a large hosted model for every decision. | The same split, inside the runtime the client already deploys. Before a privileged tool call, the check asks why it is happening, and whether it fits the contract and the session. It logs allow and deny, and it blocks only after the owning team has read the denies. Cheap checks (tool on the list, intent tag, user role) run beside any semantic check. The semantic check is reserved for actions that move money, customer data, or production. We do not stand up a fleet of fine-tuned guardrail models as the first step. |
| Continuous assurance | One trace links the request, the agent steps, the tool calls, and the guardrail verdict. Content is stored only when needed. Sensitive data is redacted. Access and retention are limited. Recorded traffic is replayed against a candidate policy before enforcement. Threat modelling feeds scenario tests and ongoing red teaming. Findings go back into the risk score, the policy, the calibration, and the guardrails. | The same trace, with a retention period the team chooses. One replay of a candidate policy on recorded traffic before that policy blocks anyone. A repeat test of the intents, with the findings written back into the contract. Prompt content stays out of the log unless someone needs it for a specific review. |
A shared content filter is still worth running. On AWS, Bedrock Guardrails covers content, denied topics, PII, and grounding. Whether this tool call matches what the user asked is the runtime row in the table.
What goes in the behavioral contract?
Uber’s AI Registry is the authoritative record of an agent’s identity, owner, persona, permitted intents, constraints, dependencies, and risk tier. Those fields are the behavioral contract. They say what the agent is for, and what it is allowed to do.
Argus exists so developers are not left with a blank form. It derives intents from the implementation, and the team reviews the draft. Uber built that path because manual registration was overhead teams would bypass. We do the comparison without a product named Argus. We sit with the owning team, read what the agent can call, draft the persona and the intents, and they correct the draft.
A third-party tool description is another prompt. Uber inspects those descriptions for poisoning and injection, alongside the usual dependency checks. We do that read before the tool is connected. An agent that can write to a package registry is a separate problem. That write is code execution on every machine that pulls from the registry. The lock-down for that path is in our note on CVE-2026-82329.
What does the runtime check decide?
Uber extends a split most security teams already know. The registry holds the contract, AI Guard decides, and the hooks enforce before the tool call proceeds.
The decision is why the action is happening, and whether the current session supports it. The agent can hold a valid credential. The user can be allowed to touch the underlying record. The call can still be refused because it is outside the agent’s intents.
Latency sits on the same path as the user. Uber’s answer is small models, hosted next to the agent, running in parallel. We keep that limit, and we do not start by hosting our own model fleet. A second general-purpose model call on every tool invocation will be switched off by the team that owns the latency budget. Put the expensive check on the privileged actions only.
Uber wires the hooks into its code builders, its no-code builders, and its deploy path, so a new agent inherits the checks. On a client engagement the check has to live in the runtime they already ship. A console that each team rebuilds will be skipped.
What has to be in the trace?
The trace has to connect four things: the user turn, the agent step, the tool call, and the verdict. Uber stores prompt and response content only when someone needs it, redacts sensitive data, restricts who can read the trace, and deletes it on a schedule. Recorded interactions can be replayed against a new policy before that policy blocks a real user. Findings from tests go back into the risk score and the contract.
Prompt provenance and evidence chaining are the control Uber plans to expand. Each privileged action is tied back to what the user actually requested. In the introduction they call this an additional defense against indirect prompt injection, goal hijacking, and unintended behavior. In the conclusion they put provenance among the four controls that matter more as agents run longer without a person watching. The implementation is reserved for a later post. We still require the link in the log now. Once enforcement is on, a privileged call that cannot point at the user turn it claims to serve does not run.
Operating principles are how Uber wants to govern goal-seeking when an agent keeps working after the person has left. That design is also in a later post. Until it is public, the contract carries the stop conditions the team can already state: how many steps, which tools are off when nobody is in the session, and which actions wait for a person.
Which production problems show up first?
Uber names four problems, and they are the four we plan for on an engagement. Security, accuracy, latency, cost, autonomy, and developer experience pull against each other, and Uber treats the guardrail path as a distributed-systems problem as well as a security one. On a smaller platform the same six still conflict. Set the intent boundary first. Spend latency on the actions that can move money, customer data, or production.
| Problem | What Uber did | What we do |
|---|---|---|
| False blocks and false allows | Shadow mode, replay of production traffic, calibration per agent. Uniform thresholds blocked legitimate work. | The check logs allow and deny, and blocks nobody, until the owning team has read the denies on their own traffic. Enforcement is per agent. |
| Latency from stacked checks | They stopped running guardrails one after another on large models. Evaluation runs in parallel, on smaller specialised models. | Keep a general-purpose model off the decision path. Independent checks run in parallel when the platform allows it. |
| Teams route around the control | Argus drafts the persona and the intents. Teams edit the draft instead of starting from a blank form. | We draft the contract from the code and the workflow. The owning team edits it. |
| One control for every agent | Personas, intents, constraints, and calibration come from each agent’s purpose and from production telemetry. A shared filter is only the baseline. | A shared content filter stays. The contract is per agent. A company-wide block list does not know what the payroll agent is for. |
Uber is plain that persona, intent, and constraints need the per-agent work. A single company policy does not produce them.
What did Uber’s controls actually change?
They reduced risk and raised the cost of an exploit. They did not remove the risk. Guardrails caught known patterns. Uber says their effect on new injection techniques is less predictable. The post has no false-block rate, no false-allow rate, and no latency number. Treat the post as an architecture, and take the rates from your own shadow traffic.
The mitigation they found most effective is restricting agents to explicit intents and constraints that govern what may happen, and under what conditions. They call it the least glamorous control they have. It cut the agent’s ability to follow a manipulated instruction. It also cut some of the flexibility people want from an autonomous agent. Uber says that trade is worth making today.
On agents that can change a customer record, move money, or touch production, we make the same trade. The contract lists the intents. Anything outside them does not run.
Four controls get more important as an agent runs longer without a person in the loop: personas, scoped intents, constraints, and provenance with evidence chaining. Constraints tie an action to the conditions that make it legitimate. Operating principles govern the goal-seeking. Provenance keeps a long chain pointed at something a person asked for. Uber does not expect to drop those four when the models improve. They also say durable protection needs safeguards in the model and controls on the agent.
This is the first post in their series. Later posts are planned on Agent Persona, Context-Aware Guardrails, End-to-End Observability, intent filtering, constraints, prompt provenance, and secure onboarding. PersonaGuard is named as a control already in production. Its design is not in this post.
What does not transfer from Uber?
This is one company’s account, written at Uber’s scale, with a platform team behind it. The custom model fleet and the monorepo scanner are built for that scale.
Small models hosted next to the decision path are a reasonable design once the volume makes a large-model call too slow and too costly. We do not stand that fleet up as the first step. The first step is the contract, shadow mode, and a check that does not add a round trip to a general-purpose model.
The monorepo scanner assumes one monorepo, so we do not copy it. We keep an inventory, and an unregistered agent does not get production credentials.
Nobody else can confirm the false-block numbers, because Uber did not publish any. PersonaGuard, the constraint design, and the provenance design are deferred. Until those posts exist, implementing this model means the contract, the shadow-then-enforce order, the supply-chain read on tools, and the trace.
How do we run this with an enterprise?
We start with the AI assurance audit. It covers the AI and systems you already run, where the security and compliance gaps are, a written roadmap, and a delivery session. The fee is AUD $2,650 in Australia, SGD $2,400 in Singapore, and USD $1,830 everywhere else, exclusive of tax. It is credited if you go on to the build. The build is a fixed price after the audit, in accounts you own.
For each agent that can take a real action, the build leaves four things:
- A behavioral contract the owning team can edit: owner, persona, intents, constraints, dependencies, risk tier, and the stop conditions.
- A runtime check on privileged tool calls. It logs first. It blocks only after that team has read the denies.
- A trace of the user turn, the step, the tool call, and the verdict, with redaction and a retention period the team chose.
- One replay of a candidate policy against recorded traffic before that policy blocks anyone.
Identity, SSO, and the policy engine you already have stay in place. They answer who may act. Moving a chat workflow into a production agent covers that work. This page adds the check on whether an allowed action should happen. If a board or a regulator wants a record, the trace is the start of one. The longer version of that evidence problem is whether you can prove the AI you run. When ISO/IEC 42001 is in scope, we prepare the AI management system. A certification body accredited by JAS-ANZ issues the certificate. Details are on the ISO 42001 page.
FAQ
Does SSO stop an agent from doing the wrong thing? SSO and authorisation say who may call the tool. They do not say the call matches what the user asked, or the agent’s intents, or the rest of the session.
Should we still buy a guardrail product? Keep one for direct injection, jailbreaks, unsafe content, and data leaks. Add the contract for the case where every credential is already valid. Uber kept both, and so do we.
Will explicit intents make the agent less useful? It still does the work inside the contract, and it stops outside it. Uber accepts that loss of flexibility. So do we, when the agent can change something a person would have to undo.
Can a smaller team copy Argus? Copy the comparison. Read the code and the tool paths, write the intents you observe, and have the owning team edit them. You do not need Uber’s analysis platform to do that.
What should we log? The user turn, the agent step, the tool call, the verdict, and a pointer from each privileged call back to the turn it claims to serve. Store prompt content only for a specific review. Redact sensitive fields, and delete the trace on a schedule the security team has agreed.
Where should we start? Pick the agent that can change a customer record, move money, or touch production. Write its contract, run the check in shadow, and enforce only after the owning team has read the denies.
Related: Bedrock Guardrails in production · Artifactory, agents, and the registry · From a Claude workflow to a production agent · AI assurance audit fee · Security engineering