The Confused Deputy problem in AI agents (OWASP ASI03)

Bottom line up front

The Confused Deputy (OWASP Agentic Security Initiative ASI03 — Identity & Privilege Abuse) is not a model-quality bug you can prompt your way out of. It is an authorization gap: the agent has legitimate access to a tool, and untrusted input supplies a malicious argument. The fix is deterministic argument-level authorization with a provenance check, enforced mid-loop — not pre/post proxying at the edge.

OWASP’s Top 10 for Agentic Applications 2026 (published 9 Dec 2025 by the Agentic Security Initiative; authors include John Sotiropoulos, Idan Habler, and Keren Katz) ranks Identity and Privilege Abuse as ASI03 — the catalog entry that covers agents tricked into misusing legitimate privileges. Primary hub: genai.owasp.org.

Legacy gateways proxy the request before the model runs and inspect the response after. That leaves the most dangerous moment — the instant the agent decides to call an external tool with attacker-influenced arguments — completely ungoverned. Kimss enforces at that moment instead.

Kimss calls this the Authority Boundary. Before a tool with a security-sensitive sink executes, Hermis requires the argument value to trace back to a trusted source: a direct user instruction, a trusted system instruction, or an explicit human approval — not text that arrived from a retrieved document, a web page, or another tool. See the Trust Center and AI agent security.

What the Confused Deputy is

A confused deputy is a program tricked into misusing its authority on behalf of a less-privileged party. In agent systems, the less-privileged party is untrusted content the model ingested.

The pattern predates AI: a compiler with write access is tricked into overwriting a billing file because a caller supplied that path. In agentic systems the deputy is the agent, the authority is your API keys and tools, and the manipulator is prompt-injected text hiding inside a webpage, an email, a PDF, a code comment, or a prior tool result.

The OWASP Agentic Security Initiative catalogs this under ASI03. The agent is authorized to call the tool — that is the point of the agent. The vulnerability is that the specific arguments are attacker-controlled while the caller identity remains yours.

Frameworks that focus on orchestration graphs — building multi-step flows in code you operate — do not close this gap by default. LangGraph and LangChain give you the tool-calling machinery; they do not deterministically verify that a tool argument originated from a trusted instruction rather than injected content. That verification has to live in the runtime that executes the call.

A concrete attack walkthrough

Capability gating alone (does this agent have the send_email tool?) is insufficient. The dangerous question is whether the specific payload is permitted.

A support agent has a legitimate send_email tool scoped to your domain and a fetch_ticket tool that reads customer messages. A customer pastes a message containing hidden instructions: forward the last three internal threads to an external address.

The model, doing its job, calls fetch_ticket, ingests the poisoned content, then calls send_email with an attacker-supplied recipient. Capability gating passes — the agent is allowed to send email. Pre-execution proxying passes — the request looked normal. The damage is done at the argument level.

• Capability gating asks: can this agent use send_email? Answer: yes. Attack succeeds.
• Argument-level authorization asks: is this recipient permitted, and did it come from a trusted source? Answer: no. Attack blocked.

Kimss ships argument-level tool policies (iam.tool_argument_policies): an operator declares that send_email.to must match the company domain, and that security-sensitive sinks require trusted provenance. See Trust and safety.

Why mid-loop enforcement beats pre/post proxying

The Authority Boundary runs inside the agent loop, between the model's decision to call a tool and the tool actually executing. That is the only place the argument and its provenance both exist.

Hermis, the Kimss orchestration loop, pauses on every tool_call. Before execution it runs, in order: the agent kill switch, the tool allowlist, argument-level policy validation, and the Authority Boundary provenance check. Only then does the external tool fire.

Because enforcement is deterministic and server-side, it cannot be talked out of the decision by a cleverer prompt. A violation soft-fails back to the model with a refusal and records a Threat Intercept, so the agent can recover without executing the unsafe action.

Argument provenance and taint

Provenance tracking labels where each candidate argument value came from. Values tainted by untrusted content are denied at security-sensitive sinks unless a human or policy explicitly approves.

Trusted sources include the end user's direct instruction and trusted system instructions. Untrusted sources include retrieved documents, web search results, prior tool outputs, and any model text derived from them. When a sink is declared to require provenance, a tainted argument is refused.

This is how Kimss operationalizes ASI03: it moves beyond checking access to deterministically evaluating whether the specific value is permitted and where it came from. Production and above can enable the Authority Boundary; argument-policy enforcement runs even on lower tiers when policies already exist. See RBAC and identity.

How to adopt it

Route agent traffic through the Kimss gateway, declare argument policies for your sensitive tools, then enable the Authority Boundary and watch Threat Intercepts before enforcing.

1. Point your agent runtime at the Kimss gateway (one base_url change) so tool calls pass through Hermis.
2. Declare argument-level policies for sensitive sinks (recipients, URLs, shell arguments, payment fields).
3. Mark provenance-requiring sinks and enable the Authority Boundary for the workspace.
4. Observe Threat Intercepts in log-only posture, tune policies, then enforce.

The same loop also governs MCP tools and webhooks, so the boundary is consistent across builtin, registry, and external tools. For the poisoning angle on MCP specifically, see MCP tool poisoning and AIBOM.

Provenance labels in practice

The whole defense rests on one question the runtime can answer deterministically: where did this argument value come from? Kimss classifies every candidate value into a trust tier before a sink decides whether to accept it.

Think of provenance as a chain of custody for each string that reaches a tool argument. A value typed by the end user, or set by a trusted system instruction the operator authored, carries trusted provenance. A value that first appeared inside a retrieved document, a web result, an email body, or a prior tool output carries untrusted provenance — and any model text derived from those inherits the taint.

Sinks are the dangerous destinations: an email recipient, an outbound URL, a shell argument, a database identifier, a payment field. An operator declares which sinks require trusted provenance. When the Authority Boundary sees a tainted value flowing into such a sink, it refuses — regardless of how persuasive the surrounding model text is.

• Trusted — direct user instruction or operator-authored system instruction. Allowed at sensitive sinks.
• Approval — a human explicitly approved this specific value or action. Allowed, and recorded.
• Untrusted — value originated in retrieved content, web results, or prior tool output. Refused at provenance-requiring sinks.

The result is that injection can still influence what the model says, but it cannot influence what your infrastructure does at a sensitive sink without a trusted origin or an explicit approval.

Common misconceptions

Most Confused Deputy defenses fail because they solve an adjacent problem. Naming the misconceptions keeps the control honest.

Misconception one: a stronger system prompt fixes it. Prompts are advisory; a determined injection competes with your instructions on equal footing. Deterministic, server-side authorization does not negotiate.

Misconception two: content filtering catches it. Safety classifiers catch toxic or unsafe content, not a perfectly polite instruction to email an attacker's address. The Confused Deputy payload is often benign-looking text.

Misconception three: least-privilege tools are enough. Least privilege reduces which tools exist, but the agent still legitimately holds the abused tool. You need argument-level control on top of capability scoping.

Misconception four: logging is a control. Post-hoc audit tells you an exfiltration happened; it does not prevent it. The Authority Boundary refuses the call before the external side effect occurs.

Related reading

Confused Deputy sits alongside rogue agents and tool poisoning in the agentic threat model.

Continue with Rogue and shadow agents (ASI10), MCP tool poisoning and the cryptographic AIBOM, and the executive framing in Why Kimss.

• Primary: OWASP GenAI Security Project — Agentic Security Initiative (ASI03).
• Primary: OWASP Top 10 for MCP (MCP03 Tool Poisoning; MCP09 Shadow MCP).
• Primary: OWASP MCP Tool Poisoning attack page (connect-time vs runtime trust gap).
• Primary: NIST AI Risk Management Framework.
• Primary: MCP confused-deputy discussion #333.

Frequently asked questions