The Confused Deputy MCP Problem

A 1988 Problem In A 2026 Wrapper

• the MCP gateway has a token (the capability) for a downstream service — say, a ticketing system, a CRM, a code host
• a user is talking to an agent through the gateway. the user has some level of access to that downstream service (the authority) — maybe none, maybe partial, maybe full
• the agent calls a tool. the gateway uses its token to hit the downstream API
• did anyone check the user's authority before the call went out?

Why MCP Makes The Confused Deputy Problem Worse By Default

1. MCP servers usually hold service-account credentials. A typical install for Jira, GitHub, or an internal ticketing tool is: paste in one API token, done. That token belongs to whoever generated it — often an admin or a service account. Every downstream call inherits that identity, not the calling user's.
2. The agent acts on untrusted input. An MCP agent reads emails, fetches web pages, summarizes tickets. Any of that content can contain instructions. (See the lethal trifecta for why this is a hard problem on its own.) The "caller" of a tool is not always a human — sometimes it is text that snuck in from a webpage telling the agent to call delete_ticket(id=...).
3. There is no concept of "on behalf of whom" in most MCP server implementations. The protocol carries tool calls. It does not natively carry the caller's identity through to the downstream API. Unless the gateway adds that explicitly, the downstream service has no way to scope the call to the actual user.

What "Per-Identity Tool Routing" Means In Practice

1. know who the calling user is (from the MCP client's auth — see the authentication guide for how that token gets there in the first place)
2. select credentials for that user, not a shared admin token — either the user's own OAuth token to the downstream service, or a delegated grant minted on their behalf (enterprise-managed authorization is one way to do this cleanly)
3. evaluate any tool-call policy with the user's identity as part of the input, not just the tool name and args (AI tool guardrails is where this enforcement lives in Archestra)

# confused deputy. don't do this.
def handle_tool_call(tool_name, args, calling_user):
    creds = SERVICE_ACCOUNT_TOKEN  # one token for everyone
    return downstream_api.call(tool_name, args, auth=creds)

def handle_tool_call(tool_name, args, calling_user):
    # 1. resolve credentials that represent THIS user's authority
    creds = credential_store.for_user(calling_user, downstream="ticketing")
    if creds is None:
        raise NotAuthorized(f"{calling_user} has no creds for ticketing")

    # 2. policy check with identity in the input, not just tool + args
    decision = policy.evaluate(
        tool=tool_name,
        args=args,
        user=calling_user,
        context=current_conversation_context(),
    )
    if decision.block:
        raise Blocked(decision.reason)

    # 3. now call downstream as the user, not as the gateway
    return downstream_api.call(tool_name, args, auth=creds)

Opinion: Per-Identity Routing Should Be A Default, Not A Feature

• which downstream identity was used for this tool call?
• which calling user authorized it?
• if the answers to those two are different, why — and is that intentional (e.g. a deliberate service-to-service call) or accidental (e.g. nobody ever wired user creds through)?