Confused Deputy Attack

An attack where a legitimate agent is tricked into using its own authorised access to perform an action the attacker could not do directly. The risk is highest when an agent has broad permissions and accepts untrusted inputs, allowing adversary-driven prompts or documents to redirect valid credentials toward harmful actions.

Expanded Definition

A confused deputy attack occurs when a legitimate AI agent, workflow runner, or service account is induced to use its own privileges on behalf of an attacker. In NHI security, the danger is not stolen credentials alone, but privilege misuse through trusted execution paths that accept untrusted inputs.

Definitions vary across vendors when the target is an AI agent, because some describe the issue as prompt injection, while others frame it as privilege abuse or unsafe tool invocation. The security pattern is the same: an agent with authorised access receives adversary-controlled content, then performs an action that appears valid to the platform but is harmful in context. This is why the OWASP NHI Top 10 treats over-permissioned identities and weak input trust boundaries as a core control problem, not just an application bug, and why MITRE’s adversarial AI guidance is useful for mapping the abuse path.

The most common misapplication is treating every harmful agent action as prompt injection alone, which occurs when the real failure is excessive privilege paired with untrusted tool input.

Examples and Use Cases

Implementing confused deputy protections rigorously often introduces workflow friction, because organisations must separate convenience for automation from the cost of tighter approval, token scoping, and input validation.

• An AI assistant with mailbox access is tricked into forwarding a confidential thread after a malicious attachment asks it to “summarise and share” the contents.
• A CI/CD bot with deployment rights is fed attacker-controlled build instructions, then publishes an unauthorised container image using valid pipeline credentials.
• A customer-support agentic workflow with CRM access follows an embedded prompt in a ticket and exports records that the requester could not retrieve directly.
• An internal document processor with cloud storage permissions is directed to copy sensitive files to an external location because it trusts text inside the document body.

NHIMG’s OWASP NHI Top 10 is useful for framing these risks as a control issue, while the Anthropic report on AI-orchestrated cyber espionage shows how malicious content can be operationalised through agentic workflows.

For incident pattern comparison, The 52 NHI Breaches Report helps teams see how identity misuse, rather than raw exploitation, often becomes the path to impact.

Why It Matters in NHI Security

Confused deputy attacks matter because they exploit the gap between authentication and authorisation context. A service account may be valid, but that does not mean every action it can technically perform is safe when triggered by an untrusted prompt, file, message, or API payload. In NHI programs, this becomes especially dangerous when identities are long-lived, broadly scoped, and difficult to observe. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into service accounts, conditions that make privilege misuse hard to detect until the damage is already underway.

Operationally, the answer is to narrow tool permissions, validate the source and intent of inputs, and design agents so they cannot blindly chain trusted credentials into irreversible actions. NIST guidance on security controls supports this discipline, especially when paired with zero trust thinking and the MITRE ATT&CK model for tracing lateral movement and abuse outcomes. The same logic also appears in Ultimate Guide to NHIs — Key Challenges and Risks, which connects poor visibility and excess privilege to real compromise paths, and in CISA cyber threat advisories, where abuse of legitimate access is a recurring pattern.

Organisations typically encounter the consequences only after an agent has already moved data, changed configuration, or issued a transaction they did not intend, at which point confused deputy analysis becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Attack Surface Management
• Why do OIDC token validation failures create confused deputy risk?
• How can organisations prevent confused deputy problems in API access?
• Why do MCP implementations create confused deputy risk?