Because they execute under the developer’s identity while reading attacker-controlled instructions from repositories, issues, or web content. The agent becomes the deputy that can be tricked into acting for the wrong principal. That means a normal setup task can become privileged local execution unless repository content is treated as hostile by default.
Why the deputy problem shows up in coding agents
The confused-deputy pattern appears when a tool has legitimate authority, but it is asked to act on untrusted instructions. In developer workflows, the agent can read repository files, issue text, build logs, or web content, then use the developer’s credentials to perform actions. That creates a gap between who supplied the instruction and whose authority is actually being used.
This is why the risk is not limited to “bad prompts.” Any content source the agent is allowed to inspect can become an instruction channel if it is not clearly separated from trusted operator intent. The same setup action that helps the developer can become a delegated action that benefits an attacker instead.
When teams already use ai coding assistant in editors, terminals, and CI, the deputy problem becomes easier to miss because the workflow feels normal. The agent is often treated as part of the developer’s productivity stack, but from a security perspective it is executing with borrowed trust and borrowed reach.
How attacker-controlled content turns ordinary tasks into privileged actions
Repository files, pull requests, issues, readme content, dependency metadata, and copied snippets can all carry instructions that the agent may treat as relevant context. If the agent is allowed to follow those instructions and also has access to secrets, tokens, or local execution, an attacker can steer it toward actions the developer never intended.
That can mean running a command, altering a file, installing a package, or exposing environment data. The core failure is not the content alone, it is the combination of untrusted input, implicit authority, and a toolchain that does not clearly distinguish between “read” and “act.”
In practice, the dangerous cases are the ones where the agent can bridge from interpretation to execution. If a repo note says to “fix” something and the agent can also invoke shell commands, access cloud credentials, or open network connections, the workflow has already crossed into delegated authority territory.
A useful way to think about this is that the agent should never be allowed to decide that hostile content is part of the operator’s intent. That boundary needs to be explicit in the design, not inferred from context.
Why the blast radius depends on identity, permissions, and trust boundaries
The severity of the confused-deputy risk is driven by what the agent can reach with the developer’s identity. If the agent can sign commits, touch production-adjacent systems, read local secrets, or invoke cloud resources, the same prompt injection can move from nuisance to real compromise.
One of the clearest controls is to narrow the authority of the agent to the smallest task scope possible. NHIMG’s AI Coding Agents Security Guide is useful here because it frames the problem around secrets in context, sandboxing, and over-scoped tokens, which are the conditions that make deputy abuse material. A separate but related control view is to use AI Agent Authorisation Guide patterns so the agent gets task-scoped, just-in-time permissions instead of standing access.
When the agent can act across trust boundaries, the issue is no longer just content safety. It becomes a question of whether the workflow enforces least privilege, explicit approval gates, and separations between reading untrusted material and using privileged capabilities.
Risk and Threat Considerations
Confused-deputy risk matters because an attacker does not need to steal the developer’s password if they can influence a tool already trusted to use that developer’s authority. The workflow may look like a normal coding task while actually becoming an execution path for malicious instructions.
Failure mechanism: The agent consumes attacker-controlled text as if it were operational guidance, then uses the developer’s authenticated context to run commands, access secrets, or modify resources outside the user’s real intent.
Impact: The result can be local code execution, secret exposure, unauthorized file changes, unsafe dependency installs, or downstream access to systems the developer could legitimately reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The agent acts with excessive authority in a workflow trust boundary. |
| NHI-02 — Secret Leakage | Attackers can steer the agent toward exposing secrets from context or environment. | |
| Recommendation — Reduce agent permissions to the minimum task scope and remove standing access. Keep secrets out of agent context and restrict what the tool can read. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question is about an agent being tricked into using the wrong principal's authority. |
| ASI02 — Tool Misuse | The deputy risk emerges when untrusted content drives harmful tool actions. | |
| Recommendation — Bind each agent action to explicit authorization and least privilege. Require approval or policy checks before the agent uses powerful tools. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | AI coding agents and connected services need authenticated, bounded machine-to-machine access. |
| AC-6 — Least Privilege | The risk grows when the agent can act with more privilege than the task requires. | |
| Recommendation — Authenticate tool and service interactions with constrained, attributable credentials. Limit agent permissions to the minimum needed for the current task. | ||
Practitioner Guidance
What to verify: Check whether the agent can both ingest untrusted repository or web content and invoke privileged actions in the same session. If yes, assume the workflow is susceptible unless there is a hard boundary between observation and execution.
Decision rule: If the agent can touch secrets, shells, package managers, or cloud credentials, treat every external repository artifact as hostile by default and require explicit human confirmation before any action that changes state or expands access.
What good looks like: The agent can assist with reading, summarising, and drafting, but cannot silently upgrade itself from helper to operator. High-risk actions are either blocked, isolated in a sandbox, or forced through a visible approval step.
Practitioner takeaway: The key control is not “better prompt hygiene,” it is making sure the agent never inherits enough authority to turn untrusted instructions into privileged execution.