Confused Deputy Agent
The confused deputy problem in agent systems occurs when an agent executes requests without checking the requester's permissions and instead applies its own, usually broader, access rights. Access control then evaluates the agent rather than the human behind it.
A confused deputy agent is an AI agent that uses its own broad privileges to perform an action triggered by a less privileged requester, unintentionally enabling privilege escalation.
Explanation
For convenience agents are often run under a single service account that can reach every required system. When an intern asks the agent for revenue figures, the database only sees the privileged agent — and answers. The pattern is old, familiar from compilers and proxy systems, but natural language amplifies it because requests are no longer bound to fixed endpoints. The fix is delegation instead of impersonation: the agent acts with a token carrying the requesting user's rights, complemented by server-side authorisation per tool call and logs that record user and agent separately.
Marketing Relevance
In marketing stacks spanning CRM, ad accounts and customer data this pattern decides whether a helpful assistant quietly becomes a data leak. It is the most frequent cause of unintended data exposure in agent projects.
Example
An internal knowledge agent has read access to every drive so it can answer well. A working student asks about salary bands — the agent finds the file, never checks whether the requester may see it, and summarises it.
Common Pitfalls
The gravest mistake is a single service account with maximum privileges. It renders any later access control useless because the system no longer knows the real identity.
Origin & History
The confused deputy concept originates in a 1988 computer security paper. With the rise of autonomous agents and shared service accounts it was revisited in 2025 and 2026, because classic role-based models do not represent the agent as an intermediary.
Marketing Use Cases
On-behalf-of tokens so the agent acts within the requesting user's permission context.
Server-side authorisation checks on every tool call rather than only in the prompt.
Audit log recording user identity, agent identity and target system separately.
Least-privilege design with separate agents per data class instead of one general-purpose agent.
Frequently Asked Questions
Is instructing the agent about access rules in the prompt enough?
No. Prompt rules are guidance, not enforcement — clever phrasing or an injection defeats them. Permissions must be checked where the data lives, not in the model context.
How does this differ from impersonation?
With impersonation the agent fully poses as the user, destroying traceability. With delegation it acts visibly as an agent but is limited to the requester's rights — only the latter is auditable.
How do you test for the problem?
Ask the same question from two accounts with different permissions. If the agent returns the same answer both times, it is not checking the requester's rights.
Related Services
Go deeper: Agentic AI Hub · Governance & compliance