Why do confused deputy attacks happen even when authorisation is working?

Why the attack succeeds when permissions are still correct

confused deputy attacks succeed because the security boundary that matters is not just whether the deputy is allowed to act, but whose instructions it trusts. A system can enforce authorisation correctly and still be tricked into treating attacker-controlled input as legitimate task context. The compromise is therefore about instruction provenance, not broken permission checks.

That distinction matters in practice because many controls only answer “may this identity do this action?” They do not answer “did the request originate from the trusted party, and is the agent still acting on that party’s behalf?” When those two questions are conflated, the deputy becomes a relay for hostile intent while remaining fully authorised.

In agentic and protocol-driven systems, this failure often appears when a service, tool, or workflow consumes external input and then reuses its own authority to fetch, post, approve, or disclose something. The action may be allowed, but the decision to take it was captured upstream. That is why confused deputy issues are commonly discovered only after the fact, when the log shows a permitted action but not the provenance break that caused it.

Where the trust collapse happens

The weak point is usually the handoff between user intent, application logic, and privileged execution. If the deputy accepts instructions from one source but executes them using a different source of authority, the attacker can smuggle in directives that look like part of the legitimate workload. This is especially dangerous where the deputy can call tools, read scoped resources, or move tokens across trust boundaries.

A practical example is an assistant, gateway, or backend service that has valid credentials but no robust binding between a user request and the resource being accessed. The resulting error is not “unauthorised access” in the classic sense. It is misattributed authority, where the deputy acts with permission but for the wrong principal. That is why confused deputy attack often survive basic access review.

For protocol-heavy environments, explicit authorisation design becomes critical. MCP Security Guide is relevant here because the pattern depends on how a server validates audience, token use, and request context, not just whether authentication succeeded. The same principle also shows up in Model Context Protocol: Authorization specification, which makes audience-bound tokens and no token passthrough central to preventing a trusted component from acting on the wrong instructions.

How to recognise and contain the pattern

Confused deputy problems usually emerge when an identity is reused across multiple trust relationships, especially when one side can influence parameters, URLs, resource IDs, or tool calls. The more privilege the deputy has, the more damaging the error becomes. That is why the issue often looks like an authorisation success in telemetry, even though the real failure is that the deputy accepted attacker-framed context.

Good containment focuses on binding authority to intent. Authorisation Models Guide helps because confused deputy prevention often requires policy decisions that include context, relationship, and resource ownership, not just coarse role membership. Where delegated action is involved, least privilege and per-action checks should reduce how much damage a captured instruction can cause.

When the system is a workload, service, or cloud automation path, Cloud Workload Identity Guide is a useful reference because confused deputy cases frequently arise from cross-service trust, temporary credentials, and federated access. The stronger the identity binding, the easier it becomes to prove whether the deputy was acting for the expected principal or simply executing a hostile request.

Red Teaming AI Agents for Identity Abuse is also relevant where autonomous systems can be steered into privilege misuse or delegation abuse. In those cases, the attack is not that the agent lacks rights, but that it uses valid rights against the wrong objective after being manipulated.

Practitioner Guidance

What to verify: Check whether every privileged action is bound to a specific user intent, resource, and audience, not merely to a valid session or token. If the control can succeed without preserving that chain of custody, treat it as vulnerable to deputy abuse.

Decision rule: If a component can reach multiple resources or tenants with the same authority, assume confused deputy risk unless the request context is explicitly bound and rechecked at the point of use. If the component can act on behalf of others, constrain it to the smallest viable scope and avoid implicit trust in forwarded input.

What practitioners underestimate: Audit logs often show the deputy’s allowed action, which can hide the attacker’s role in shaping the request. The important evidence is not only who executed the call, but whether the call was authorised for that specific instruction provenance.

Practitioner takeaway: Confused deputy attacks are a trust-binding failure, so the fix is to make authority conditional on provenance, context, and audience, not to add another layer of generic permission checking.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why is NHI governance critical in the age of AI attacks?
• Why do Shai Hulud style attacks matter to NHI governance?
• Why do spoofing attacks keep working even when users are trained?