How should security teams prevent confused deputy attacks in multi-user AI agents?

Security teams should enforce authorization at the moment of execution, not at prompt time. Use a runtime that evaluates the agent identity, the delegated user identity, and the task context before each tool call. Keep credentials isolated from the model context window, and require the effective permission to be the intersection of agent and user rights.

Why confused deputy attacks happen in multi-user AI agents

A confused deputy problem appears when an AI agent can act with more authority than the user who triggered it, or when the system cannot cleanly separate one user’s request from another’s privileges. In multi-user settings, the risk rises because the agent may hold shared credentials, cached context, or broad tool access that outlives the original user request.

The core failure is not “the model made a bad guess”, but that the execution layer trusted the wrong authority boundary. When an agent can browse, post, delete, query, or trigger side effects, the runtime must know which user is being represented and which authority is actually in force for that specific action.

That distinction matters most when the agent serves many users at once. A design that looks safe in a single-user demo can become unsafe once one user can influence a shared tool session, steer the agent into acting on a different tenant’s data, or cause the agent to reuse a permission grant that was valid for a previous task.

What the runtime must check before every tool call

The safest pattern is to treat each tool invocation as a fresh authorization decision, not as a one-time prompt-level approval. The runtime should evaluate the agent identity, the delegated user identity, the intended action, and the current resource context immediately before execution, then allow only the minimum effective permission required for that call.

That runtime decision is stronger than static role assignment because it can account for task scope, user scope, resource scope, and time scope together. It also creates a natural place to enforce step-up approval, deny cross-tenant access, and stop the agent from inheriting broader standing access than the user actually intended to delegate.

Isolation of credentials is just as important as the authorization rule itself. If tokens, API keys, or session material are present in the model context window, the agent can be tricked into surfacing or replaying them. Keep those materials outside the prompt boundary and hand them to a policy layer or execution layer only when the requested action has already passed authorization.

How to design the permission boundary for shared agents

In practice, the effective permission should be the intersection of what the agent is allowed to do and what the delegated user is allowed to do. That prevents a powerful agent from becoming a back door into a weaker user’s request, and it also prevents a user prompt from expanding an otherwise constrained agent into actions that were never intended for that user session.

This is where per-action policy checks and explicit delegation records matter. A good implementation can tell you which human request initiated the action, which agent instance executed it, which tool was called, and why the runtime allowed that specific step. Without that traceability, it becomes difficult to prove that a later action was still within the original delegated scope.

For a practical pattern, use AI Agent Authorisation Guide for task-scoped access and per-action authorization, and pair that with Zero Trust for AI Agents to enforce continuous verification instead of standing trust. Where the agent’s identity lifecycle itself matters, Agentic AI Identity Guide helps teams structure delegation, registration, and retirement so authority stays attributable.

What breaks when confused deputy controls are missing

The failure mode is usually privilege confusion, not a single obvious exploit. One user can indirectly cause the agent to operate on another user’s data, use the wrong tenant context, or submit a tool request that succeeds because the agent’s credentials are stronger than the user’s rights. In multi-user systems, that can turn one harmless prompt into an unauthorized action path.

That is why the execution environment must treat shared tool access as a security boundary, not just an engineering convenience. If the agent can act across mail, storage, tickets, code, or SaaS systems, then every step that can produce side effects needs a policy decision, a scoped credential, and a clear identity trail.

For a deeper threat-modeling view, Threat Modelling AI Agents is useful for mapping trust boundaries and delegated authority, while Model Context Protocol: Authorization specification shows how resource-server style authorization and audience-bound tokens reduce token passthrough risk in tool-mediated flows.

Risk and Threat Considerations

Multi-user agents create an unusually sharp exposure because the same runtime may hold multiple principals, multiple tool permissions, and multiple active tasks at once. If the system confuses those boundaries, an attacker can steer an apparently legitimate request into unauthorized access, lateral data exposure, or actions that execute under the wrong authority.

Failure mechanism: The agent or tool runtime reuses standing credentials, fails to bind the current user to the current action, or lets prompt content influence authorization instead of enforcing policy at execution time.

Impact: A single delegated task can become cross-user data access, unauthorized side effects, token misuse, or a broader trust failure that is hard to attribute after the fact.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Confused deputy attacks exploit mismatched user and agent authority.
Recommendation — Enforce per-action authorization so the agent cannot exceed delegated user rights.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	The answer hinges on limiting effective permissions to the minimum needed per task.
	IA-9 — Service Identification and Authentication	Multi-user agents and tools need strong runtime identity binding for each call.
	AC-3 — Access Enforcement	Authorization must be enforced at execution time for each action.
Recommendation — Restrict each tool call to the minimum permissions needed for that action. Authenticate services and agents before allowing tool-mediated execution. Apply access enforcement at the moment of each tool invocation.
NIST Zero Trust (SP 800-207)	undefined — Never Trust, Always Verify	Execution-time verification and least privilege match zero-trust agent workflows.
Recommendation — Verify principal, action, and context before every privileged tool call.

Practitioner Guidance

What to prioritise: Put the policy decision point closest to execution, not closest to the prompt. If a tool call can change data, reveal data, or trigger an external side effect, it needs an authorization check that is specific to that action and that user session.

What to verify: Confirm that every tool call carries the current agent identity, delegated user identity, tenant or resource context, and a bounded credential that cannot be replayed outside the intended task. If you cannot produce that evidence, the boundary is not mature enough for shared use.

Common mistake: Teams often secure the chat interface and forget the execution path. That leaves a gap where the model can be well-behaved at prompt time but still become a confused deputy when it reaches tools, connectors, or downstream APIs.

Practitioner takeaway: The security goal is not to make the agent “less powerful” in general, but to make every powerful action explicitly attributable, context-bound, and re-authorized at the moment it happens.