The class of AI agent compromise people are still preparing for is prompt injection. The class that is already showing up in production incidents is the confused deputy attack — a delegation-of-authority failure that prompt-injection defenses, credential isolation, and even most AI-specific security stacks were never designed to catch. VentureBeat's Tuesday security feature put a name on the pattern and argued it spans every major agent surface mid-market IT teams are deploying right now — Claude Code, Codex, Copilot, Claude in Chrome, the Codex Chrome Extension, Gemini Deep Research, and the long tail of MCP-connected internal agents.
Confused-deputy attacks deserve their own vocabulary because they break the most reassuring sentence in agent security: “the agent is authenticated and authorized, so anything it does is authorized too.” An authorized agent gets tricked into executing actions on behalf of an unauthorized request, using its own legitimate credentials. The agent was delegated into doing something its caller had no right to ask for, and the downstream system has no way to tell the difference.
This post is the audit. Eight rows, each a specific dimension of agent authority that mid-market IT teams should be testing quarterly against every agent surface in production. The matrix is intentionally boring — checklist-shaped, not framework-shaped — because that is the form factor most 25-to-250-seat firms in Auburn, Fort Wayne, and the rest of Northeast Indiana can actually execute without standing up a dedicated AI security function. Cloud Radix runs this matrix as the operational specification behind the Secure AI Gateway. The point of publishing it is that any IT team with quarterly review cycles can run it whether they buy the gateway from us or not.
Key Takeaways
- A confused-deputy attack happens when an authorized AI agent is tricked into executing actions on behalf of an unauthorized request, using the agent's own credentials. It is distinct from prompt injection and from credential theft, and most agent security stacks do not detect it.
- The vulnerability class shows up identically in coding agents (Claude Code, Codex, Copilot) and browser agents (Claude in Chrome, Codex Chrome Extension, Gemini Deep Research) — the delegation pattern is the same on both surfaces.
- Credential isolation is necessary but not sufficient. The agent's credentials are not stolen; they are misused on behalf of a confused authorization chain.
- The 8-row confused-deputy AI agent audit matrix later in this post covers scope-of-authority, request-source verification, downstream-tool authority, OAuth token binding, user-intent confirmation, signed-tool descriptors, cross-surface session isolation, and runtime detection logs.
- For NE Indiana 25-to-250-seat firms running mixed Claude Code + Microsoft Copilot + browser-agent stacks with no dedicated AI security FTE, the matrix folds into the Secure AI Gateway as a single chokepoint — but the diagnostic value of the checklist is independent of the gateway.
- The matrix maps cleanly onto OWASP LLM06 “Excessive Agency” and the NIST AI RMF Govern/Map/Measure/Manage functions. It is not a new framework; it is a per-surface checklist that operationalizes the existing ones.
What Is a Confused-Deputy Attack in the AI Agent Context?
The confused deputy problem is not new. Computer scientist Norm Hardy named it in a 1988 ACM paper, describing a compiler on a timesharing service that could be tricked into overwriting a billing file because it executed user-supplied filename requests using its own elevated permissions rather than the requester's. The compiler was the “deputy” — it had legitimate authority — and it was confused into using that authority on behalf of a request that had no right to it. The vulnerability is a delegation failure, not a credential failure.
The AI agent version of the same pattern is structurally identical. An AI agent has a set of authorized credentials and scopes — read this S3 bucket, send email from this address, write to this repo, execute this internal API. The agent is, by design, willing to perform actions inside those scopes on behalf of whoever is talking to it. The vulnerability is that “whoever is talking to it” is increasingly hard to verify. Prompt content can come from the user, from a webpage the agent is reading, from a document an upstream agent retrieved, from a tool's output, from a previous session's memory, or from a downstream system replaying state. When the agent acts, the downstream service sees only that an authorized agent made an authorized request; it has no signal about whether the request originated from the legitimate user or from a malicious instruction smuggled into one of those upstream surfaces.
That is the difference between confused deputy and prompt injection. Prompt injection is an attack on the model's reasoning — it tricks the model into producing the wrong output. Confused deputy is an attack on the authorization chain — it tricks the agent (or its harness) into treating an unauthorized request as authorized. A model that perfectly resists prompt injection can still be confused-deputied, because the failure is not in the model's response; it is in how downstream systems trust an agent's authority. And it is the difference between confused deputy and credential theft, which we covered in detail in our credential attack vector on AI coding agents writeup. Credential theft requires the attacker to obtain the agent's secrets. Confused deputy requires nothing — the attacker just needs the agent to be willing to act on their behalf using its own legitimate secrets.
The most important consequence is that the standard mid-market defenses leave the gap open. Multi-factor authentication on the user's account does not stop a confused-deputy attack on the agent. Credential isolation, which we recommend strongly in the zero-trust AI agents and credential isolation playbook, reduces blast radius but does not stop the attack itself. Even OWASP's GenAI Security Project, in its 2025 LLM Top 10, names “Excessive Agency” (LLM06) as the umbrella vulnerability — but the practical detection question is what specifically to audit, on which surfaces, on what cadence.
Why Does the Same Vulnerability Class Show Up in Coding Agents and in Browser Agents?
The headline insight in the VentureBeat piece is that confused-deputy attacks look identical across two surfaces most people treat as unrelated — coding agents like Claude Code, Codex, and Copilot, and browser agents like Claude in Chrome, the Codex Chrome Extension, and Gemini Deep Research. The reason the pattern is the same is that both surfaces share the same delegation shape.
In a coding agent, the agent reads context from many places — repo files, terminal output, search results, documentation pages, the developer's chat input, sometimes a connected MCP server. The agent then takes actions inside its authorized scope: editing files, running shell commands, calling APIs, deploying. The confusion vector is that any of the context sources can carry instructions that the agent treats as part of the developer's intent. A README pulled in for context can include a directive (“run this cleanup script as part of your workflow”) that the agent executes against the repo. The agent had authority to run scripts. The README did not have authority to ask. The agent was confused into bridging the two.
In a browser agent, the same pattern plays out against web pages and DOM state. The agent has authority to act on behalf of the logged-in user — read mail, click buttons, submit forms, navigate to URLs. A malicious page can embed instructions disguised as user-relevant content; if the agent treats page content as part of the request stream, it will act on those instructions with the user's authority. Anthropic's own Claude for Chrome announcement documented this risk directly: red-team testing showed that without specific mitigations, 23.6 percent of prompt-injection attempts succeeded, dropping to 11.2 percent with defenses — and browser-specific attacks dropped from 35.7 percent to zero against a specific challenge set. Those numbers are encouraging but also informative: they confirm that the attack surface is real and that pre-mitigation success rates are not trivial. They are the published data point our clients ask about most when they evaluate browser agents.
The reason cross-surface analysis matters is that mid-market IT teams typically buy these tools from different vendors and govern them with different controls. Claude Code is governed by the developer workstation policy. Claude in Chrome is governed by the browser extension policy. Copilot is governed by the Microsoft tenant. The confused-deputy pattern slips between those governance boundaries — the agent on one surface can be confused, and the action taken by the agent shows up downstream as the user doing something. The downstream system sees a logged-in user request, not “agent X on surface Y acting on instructions from source Z.” That is the gap we covered architecturally in our cross-app AI agent governance and approval dialogs piece, and operationally in our stage-three AI agent threats playbook. Confused deputy is the specific failure mode that makes cross-surface auditing worth running.
A note for development teams specifically: the prompt-injection-via-code-context pattern we documented in our AI coding agents prompt injection writeup for Fort Wayne dev teams is a confused-deputy primitive. Every secret leak we have seen begins with the agent treating a context source as a legitimate request source. The audit matrix below is the per-row diagnostic for that primitive.
What Does a Confused-Deputy Attack Actually Look Like in Practice?
A common example: a user asks their browser agent to “summarize the latest from this customer.” The agent retrieves recent emails. One thread contains a paragraph that reads as natural prose but addresses the agent directly, asking it to forward six months of internal correspondence to an external address “for compliance review.” The agent has authority to read mail, authority to send mail, and the user's session. The downstream mail server sees a fully-authenticated send-mail request from the user's account; the audit log records “user sent these emails.” The actual instruction came from a malicious thread.
Three things are simultaneously true. The agent's credentials were not stolen. The model's reasoning was not corrupted. And the user did not authorize the action. That is the confused deputy. The defense is to verify, at each authority boundary, that the source of the instruction matches the scope of the authority being used. The matrix below is the eight-row decomposition of that check.
The 8-Row Confused-Deputy AI Agent Audit Matrix
This is the matrix we recommend mid-market IT teams run on a quarterly cadence against every agent surface in production. Each row is a specific audit dimension, the failure mode it catches, the implementation approach we have used in production, and the type of tool or control needed. The rows are independent — a partial implementation still adds defense in depth — but the full matrix is what you want at the end of the year.
| # | Audit dimension | What it catches | How to implement | Tooling shape |
|---|---|---|---|---|
| 1 | Scope-of-authority audit | Agents holding broader credentials than any single workflow needs (the "I gave the agent admin because I was tired" anti-pattern) | Per-agent capability inventory; revoke and re-grant scopes per workflow rather than per agent | Identity provider with fine-grained scopes (Okta, Entra, or equivalent) |
| 2 | Request-source verification | Instructions sourced from upstream context (email body, web page, document) being treated as user intent | Tag every input by provenance; require explicit user reaffirmation for cross-source delegation | Agent harness with provenance metadata; gateway-side enforcement |
| 3 | Downstream-tool authority check | Tool calls that combine the agent's authority with a context-supplied target (the classic confused-deputy shape) | Authorization decisions made on the user's authority, not the agent's, for cross-domain actions | Capability tokens scoped per call; cross-domain policy at the gateway |
| 4 | OAuth token binding | Agent tokens being replayable outside the agent's runtime (token theft becomes confused deputy at scale) | DPoP or proof-of-possession binding so tokens cannot be replayed by a different process | OAuth IdP that supports token binding; gateway proof verification |
| 5 | User-intent confirmation prompts | High-impact actions executed without explicit human confirmation | Risk-tier the action surface; require user approval for tier-2/3 actions; log approvals | Approval-dialog component plus audit storage |
| 6 | Signed-tool-descriptor verification | Tool definitions and schemas being silently swapped (poisoned MCP server, malicious extension) | Sign tool descriptors at registration; verify signatures at runtime; fail closed on mismatch | MCP gateway with signature enforcement (this is what the Secure AI Gateway does) |
| 7 | Cross-surface session isolation | The same logged-in user session being shared between a browser agent and a coding agent — instructions from one surface affecting the other | Per-surface session contexts; deny cross-surface state replay | Browser extension policy plus IdP session management |
| 8 | Runtime confused-deputy detection | Live detection of the request-source-vs-authority mismatch pattern | Streaming evaluators on the agent's tool-call graph that flag instruction-from-context patterns | Anomaly detection on agent telemetry; SIEM integration |
Three notes on running this matrix. First, the order of the rows is approximately the order of return on investment for a mid-market firm with no current confused-deputy program: rows 1–3 catch the largest share of the easy attacks, rows 4–6 require infrastructure investment, and rows 7–8 reward firms with mature observability. Second, the matrix is consistent with the NIST AI Risk Management Framework's Govern/Map/Measure/Manage functions — rows 1–3 sit in Map, rows 4–6 in Manage, rows 7–8 in Measure. Third, the matrix is not a substitute for the broader agent-identity work covered in our AI agent identity and IAM gap piece for Fort Wayne IT — that work is the substrate the confused-deputy guards run on top of.
A current example of the toolchain risk in row 6: the MITRE ATLAS adversarial AI threat catalog tracks tool-poisoning and tool-descriptor-swap attacks as named techniques, which means defenders now have a vocabulary to map their detections to. Rows 6 and 8 of the matrix are the operational hooks for those techniques.
What Does This Look Like for a 75-Seat Allen County Professional-Services Firm?
The audit matrix is industry-agnostic, but the implementation realities are not. The 25-to-250-seat firms we work with across Allen, DeKalb, Whitley, and Noble Counties tend to share a specific operating profile that shapes how the matrix gets executed.
The typical Allen County professional-services firm — call it a 75-seat advisory practice with mixed engagements across financial services, legal, and accounting clients — runs a Microsoft 365 tenant, a Copilot deployment, two or three Claude Code workstations in the engineering or systems team, a small fleet of Claude-in-Chrome users for research and document workflows, and a handful of internal MCP servers wired to file shares and CRM. There is one IT director, one or two systems administrators, and no dedicated AI security FTE. The firm passes a HIPAA or financial-industry audit annually, and the auditors are starting to ask AI questions that did not appear on last year's checklist.
Running the matrix in that environment has a specific shape. Row 1 (scope-of-authority audit) usually surfaces two or three over-broad agent scopes that were granted during the pilot phase and never tightened — a Copilot connector wired to a SharePoint site that should have been restricted, a Claude Code workstation with admin on the build server because someone was tired of permission prompts during a sprint. The remediation is unglamorous but cheap. Rows 2 and 3 (request-source verification, downstream-tool authority) tend to be where the firm needs help, because they require a piece of middleware — a gateway, a harness adapter, or a homegrown logging layer — that does not exist out of the box in most vendor stacks. The Cloud Radix Secure AI Gateway is the chokepoint we install for exactly this layer; firms that prefer to build their own can implement an equivalent on top of an open-source MCP gateway. Rows 4–6 are usually quarterly projects rather than week-one wins, and rows 7–8 are typically rolled into the firm's broader SIEM project rather than standing up a new tool.
The most common pitfall we see is that a firm runs the matrix once during a vendor evaluation and then never runs it again. The attack surface evolves quarterly — new agents get deployed, new context sources get connected, vendors push updates that change scopes — and a one-time audit ages out in a single budget cycle. The Cloud Radix recommendation is quarterly cadence at minimum, with a fresh row-1 inventory whenever a new agent surface is added. For Whitley and Noble County firms with thinner IT budgets, the practical compromise is to run rows 1, 2, 3, and 5 in-house and outsource rows 4, 6, 7, and 8 to a managed-service provider.
How Cloud Radix Folds the Matrix Into the Secure AI Gateway
The reason we publish the audit matrix as standalone work is that it is useful whether or not a firm buys a Cloud Radix product. The reason we operate it as part of the Secure AI Gateway is that running eight independent controls across multiple agent surfaces with no central enforcement point is exactly the operational shape mid-market firms do not have the headcount to maintain.
The gateway acts as a single chokepoint between the agent surface and every downstream system the agent is authorized to touch. Tool descriptors are signed at registration and verified at runtime (row 6). Cross-domain calls require capability tokens scoped per call (row 3). OAuth tokens are proof-bound to the runtime that minted them (row 4). High-tier actions trigger approval dialogs and write to the firm's audit store (row 5). Agent telemetry streams to the firm's SIEM for runtime anomaly detection (row 8). Per-surface session contexts are enforced at the gateway boundary (row 7). The remaining two rows — scope-of-authority audit (row 1) and request-source verification (row 2) — are the rows that depend on the firm's identity provider and the agent harness; the gateway integrates with both but does not replace them.
The Cloud Radix AI Employees we deploy for NE Indiana mid-market firms ship behind the gateway by default. The matrix is the operational specification; the gateway is the implementation. We publish the matrix so that the work survives the vendor choice — a firm that decides to build its own gateway, or run its agents behind a different vendor, can still run the audit and still know what it is auditing. The firms we see succeed at agent security past year one are the ones that treat the matrix as routine quarterly work, not a one-off evaluation.
Run a Confused-Deputy Audit Pilot for Your NE Indiana Firm
If your mid-market IT team is running any combination of Claude Code, Claude in Chrome, Microsoft Copilot, Codex, or internal MCP-connected agents, the confused-deputy audit matrix is the diagnostic worth running this quarter. Cloud Radix offers a regional pilot for Auburn, Fort Wayne, DeKalb, Allen, Whitley, and Noble County firms — we run the eight-row matrix against your current agent surfaces, deliver a written remediation plan, and (if useful) stand up the Secure AI Gateway as the single chokepoint for the rows that benefit most from one. The pilot is sized for 25-to-250-seat firms and intentionally short — two weeks for the audit, four weeks for the highest-priority remediation. Reach out through the AI Employees intake if the matrix is something you want run against your stack before your next compliance review.
Frequently Asked Questions
Q1.What is a confused deputy attack on an AI agent?
A confused-deputy attack on an AI agent is a security failure in which an authorized agent is tricked into executing actions on behalf of an unauthorized request, using the agent's own legitimate credentials. The agent's secrets are not stolen and the model's reasoning is not corrupted; the failure is in the authorization chain — the agent treats an instruction from an upstream context source (a webpage, an email, a document, another agent) as if it came from the legitimate user, and downstream systems see only that an authenticated agent made a request. The classic example outside AI was Norm Hardy's 1988 compiler attack; the AI agent version follows the same shape across coding agents and browser agents.
Q2.How is confused deputy different from prompt injection?
Prompt injection attacks the model's reasoning — a malicious input tricks the model into producing the wrong output. Confused deputy attacks the authorization chain — the agent treats an unauthorized request as authorized and acts with its own credentials. A model that perfectly resists prompt injection can still be confused-deputied. Both attacks often appear together in real incidents, which is why most agent security stacks need to defend both layers separately.
Q3.Why does the same attack work on Claude Code and Claude in Chrome?
Both surfaces share the same delegation shape — the agent has authority to act on the user's behalf, and the agent reads context from many sources before deciding what to do. Coding agents read repo files, terminal output, search results, and documentation; browser agents read web pages, email content, and DOM state. Any of those context sources can carry an instruction the agent treats as part of the user's intent. The downstream system sees an authorized agent making an authorized request, with no signal about which context source actually originated the instruction.
Q4.Is credential isolation enough to defend against confused deputy?
No, but it is a necessary precondition. Credential isolation reduces blast radius — if the agent is confused into doing something destructive, the damage is bounded to the scopes it actually holds. But credential isolation does not stop the attack itself, because the agent's credentials are not stolen; they are misused on behalf of a confused authorization chain. The full defense requires per-call capability tokens, request-source verification, user-intent confirmation for high-tier actions, and runtime detection of the instruction-from-context pattern — which is exactly what the eight-row audit matrix covers.
Q5.How often should a mid-market firm run the audit matrix?
Quarterly at minimum, with a fresh row-1 scope-of-authority inventory whenever a new agent surface is added. The reason quarterly is the right cadence is that mid-market agent stacks change faster than annual audits can track — vendor updates change default scopes, new MCP servers get connected, pilot deployments graduate to production. A one-time audit ages out within a single budget cycle. The eight rows are intentionally checklist-shaped so a quarterly review is a few hours of work for a typical 75-seat firm, not a week-long engagement.
Q6.How does this map to OWASP and NIST guidance?
The OWASP LLM Top 10 for 2025 names "Excessive Agency" (LLM06) as the umbrella vulnerability that confused deputy attacks live under, and "Prompt Injection" (LLM01) as the most common upstream primitive. The audit matrix is the operational decomposition of those two items into eight specific controls. The NIST AI Risk Management Framework maps the rows across its Govern/Map/Measure/Manage functions — scope-of-authority and request-source live in Map, the infrastructure rows in Manage, and the runtime detection rows in Measure. The matrix is not a new framework; it is the per-surface checklist that operationalizes the existing ones.
Q7.What is the first step for a Fort Wayne or NE Indiana firm that has never run a confused-deputy audit?
Start with row 1 — a scope-of-authority inventory of every agent surface deployed. For the typical 25-to-250-seat firm in Auburn, Fort Wayne, DeKalb, Allen, Whitley, or Noble County, that means writing down each agent (Claude Code workstation, Claude in Chrome user, Copilot tenant, internal MCP server), the credentials it holds, and the smallest scope that would let it do its job. Most mid-market deployments in our region find at least two over-broad scopes from the pilot phase that were never tightened. Closing those gaps is the cheapest single remediation in the entire matrix, and usually takes less than a day for a 75-seat firm.
Sources & Further Reading
- VentureBeat: venturebeat.com/security/claude-confused-deputy-audit-matrix-security-blind-spots — Running Claude Code or Claude in Chrome? Here's the audit matrix for every blind spot your security stack misses (2026-05-12).
- OWASP GenAI Security Project: genai.owasp.org/llm-top-10 — OWASP Top 10 for LLM Applications 2025, including LLM06 Excessive Agency.
- NIST: nist.gov/itl/ai-risk-management-framework — AI Risk Management Framework (Govern/Map/Measure/Manage functions).
- Anthropic: claude.com/blog/claude-for-chrome — Claude for Chrome security design and red-team results (2025-08-25).
- ACM / Wikipedia: en.wikipedia.org/wiki/Confused_deputy_problem — The Confused Deputy Problem (Norm Hardy, 1988).
- MITRE: atlas.mitre.org — MITRE ATLAS, the Adversarial Threat Landscape for AI Systems.
Run the Confused-Deputy Audit on Your Stack
We will run the eight-row matrix against your current Claude Code, Copilot, browser-agent, and MCP surfaces, deliver a written remediation plan, and stand up the Secure AI Gateway as a single chokepoint where it makes sense.
Book a Confused-Deputy Audit PilotSized for 25-to-250-seat NE Indiana firms. Two weeks for audit; four weeks for priority remediation.
