AI Agents and the Confused Deputy Problem

AI agents can become confused deputies when they use their own authority—such as access to files, email, or business systems—to carry out a request without correctly checking whose interests and permissions should govern the action. Authorization fails when the agent treats a user’s instruction or untrusted content as permission to exercise capabilities the user does not have, or when it cannot reliably distinguish trusted instructions from data.

What the confused deputy problem means

The confused deputy is a classic computer-security problem. A deputy is a program that has authority of its own and performs work for someone else. The problem arises when it is tricked into using that authority in a way the requester could not do directly. The deputy is “confused” about which party’s authority or intent should control.

For example, imagine a file-conversion service that can write to a protected directory. A user may be allowed to request conversions but not to write arbitrary files there. If the service accepts a filename supplied by the user and uses its own write access without checking the destination, it can be misused as a deputy.

An AI agent fits this pattern when it can call tools or services with credentials, permissions, or network access. The model may interpret a request, but the security boundary is the whole system: model, orchestration code, tool integrations, identity checks, and the services that ultimately perform actions.

How AI agents become deputies

An agent commonly receives a goal, decides which tools might help, and sends arguments to those tools. A tool might search company documents, create a calendar event, send email, or update a record. The tool call can run with the agent’s credentials, an application’s service account, or delegated user access.

That creates a gap between the person making a request and the authority used to fulfill it. If an agent has broad access but the requester has narrow access, a weak permission check can let the requester indirectly reach restricted data or actions. The same risk occurs when the agent acts for a user but the system fails to preserve that user’s identity and scope through every tool call.

There is also a distinction between authorization and instruction following. A prompt can tell an agent what to do; it does not, by itself, grant permission. Likewise, a model’s confident explanation that an action is allowed is not proof that the underlying identity and policy checks passed.

Where authorization fails

• Overpowered credentials: The agent uses a shared account or service identity with more access than the requester needs.
• Missing per-action checks: The application checks access when the user opens the agent but not when the agent reads a particular record, sends a message, or changes a setting.
• Lost user identity: A tool receives only the agent’s identity, not the initiating user or the delegated scope, so it cannot enforce the user’s permissions.
• Confused sources: The agent treats text in an email, web page, document, or tool result as an instruction to reveal information or take an action.
• Excessive trust in arguments: A tool accepts a resource identifier, recipient, or destination supplied by the model without independently verifying that it is permitted.
• Unreviewed side effects: The system allows consequential actions, such as external messages or destructive changes, without an appropriate confirmation or policy check.

Prompt injection is related but not identical. It is a way untrusted content may manipulate an agent’s behavior. A confused-deputy failure occurs when the system then uses authority improperly. Filtering suspicious text may help, but it cannot replace authorization at the tool or service boundary.

A concrete example: email and private files

Suppose an employee asks an agent to summarize a shared project folder. The agent can also search a private HR drive because its service account has broad access. A document in the shared folder contains text telling the agent to find salary files and email them to an outside address.

The embedded text is not legitimate authorization. Yet if the agent follows it, searches the HR drive, and sends a message using its own privileges, the system has failed in several ways: it allowed untrusted content to steer the task, gave the agent access beyond what the employee needed, and did not check whether the employee could access the files or whether the recipient was allowed.

A safer design limits the search to resources the employee is authorized to access, treats retrieved documents as data rather than policy, and checks the recipient and message at send time. If the action is sensitive or difficult to reverse, it can require explicit confirmation that shows what will be sent and to whom.

How to prevent authorization failures

Security should not depend on the model correctly refusing every unsafe request. Enforce permissions in ordinary application and service code, where a tool call can be checked against identity, resource, action, and context.

1. Use least privilege. Give each agent and tool only the access needed for its task. Separate read access from write or send capabilities where practical.
2. Carry identity and scope end to end. Preserve the initiating user, delegated permissions, and relevant context through the orchestration layer to the service that performs the action.
3. Authorize every operation. Check access to the specific record and requested action at execution time; do not rely solely on an earlier login or broad agent-level approval.
4. Constrain tools. Validate recipients, paths, resource IDs, and other arguments against server-side rules. Prefer narrow tools such as “summarize these authorized records” over unrestricted access to an entire system.
5. Separate data from policy. Treat retrieved content as untrusted input. Do not let it alter system permissions, tool availability, or the identity under which actions run.
6. Gate consequential actions. Apply policy checks and, where appropriate, human confirmation before external, destructive, or high-impact operations.
7. Keep audit records. Record the user, agent, tool, resource, decision, and result so suspicious actions can be investigated. Avoid logging secrets unnecessarily.

What to monitor and what not to assume

Useful tests include attempts to access another user’s records, use a tool with an unauthorized recipient, follow hostile instructions embedded in retrieved content, and continue acting after delegated access has been revoked. Test the actual tool integrations and service permissions, not just the model’s text responses.

Monitoring can reveal unusual tool calls, unexpected data access, or actions outside a task’s normal scope. It is a detection layer, not a substitute for prevention: an alert after a confidential file has been sent cannot undo the disclosure. Likewise, a human approval button is not a complete fix if the reviewer cannot see the actual destination, data, and effect.

A common misconception is that a more capable or better-prompted model solves the confused deputy problem. Model improvements can reduce some errors, but authorization is a system property. A well-behaved model can still be given excessive credentials, while a model that is manipulated should still be unable to cross boundaries enforced by the tools and services.

Frequently Asked Questions

What is a confused deputy in AI?
A program or agent with its own authority is induced to use that authority for a requester or instruction that is not entitled to it. The failure is in how the system applies permissions, not merely in the agent’s wording.

Is prompt injection the same as a confused deputy attack?
No. Prompt injection is one possible way to influence an agent using untrusted content. It becomes a confused-deputy problem when the agent’s resulting action misuses authority that the content’s source does not possess.

Can an AI agent use a user’s permissions?
It can be designed to act with delegated user access, but the system must pass and enforce the user’s identity and permitted scope for each operation. A label saying “on behalf of the user” is not enough.

Does requiring human approval prevent the problem?
Approval can reduce risk for sensitive actions if the reviewer sees the exact action, resources, and recipients. It does not replace least privilege or server-side authorization, and vague approvals can be ineffective.

What is the most important defense?
Enforce least privilege and per-operation authorization at the tool or service boundary. Treat the model as an untrusted decision-maker for security purposes, even when its ordinary behavior appears reliable.

Related

• DNS-01 vs HTTP-01: Which TLS Validation to Pick
• Core Keeper Dedicated Server Hosting Guide
• Schedule Recurring SaaS Dashboard Screenshots for Audits