MCP's confused deputy runs on the standing token provisioned at install time

A personal access token carries only its scope. When an agent calls a tool on an MCP server, the server presents whatever credential it was configured with, and the authorization decision is made against that credential's reach. Security researchers call this the confused deputy problem: the agent inherits more trust than the task in front of it requires ^[11]. The May 2025 prompt injection against the GitHub MCP server pulled private repository data, and according to The New Stack the token behind it was scoped far wider than the task needed ^[9]. That was roughly six months after MCP went into production ^[23]. The same piece notes that an agent minting its own credentials, instead of inheriting the person's, is how a GitHub personal access token ends up reaching more repositories than the user who authorized it ^[17].

The population figure comes from the SANS 2026 Identity Threats Survey, which polled more than 500 security experts ^[7]. Seventy-six percent of businesses reported an increase in non-human identities ^[6]. Take the 74 percent on standing credentials against a best case of 40 percent for any single control, and at least 34 points of that population runs standing credentials without approval, sandboxing or logging in place ^[22]. The survey counts non-human identities across the estate, not MCP servers. For the number to say anything about your deployment, your agent credentials would have to have been provisioned by the same people, under the same review, as the rest of your service accounts.

The two 2025 cases get cited together, and they fail differently. Days after the GitHub incident, a logic flaw in an Asana MCP integration allowed cross-tenant access because the permission layer never enforced the isolation boundary between customers ^[10]. Customer-side token scoping does not reach that failure. The check that was missing sits in the vendor's code.

GitHub's engineering blog, writing about building secure remote MCP servers, says every instance must have its own secrets for the specific task, all requests must be limited to the acting user, and authorization must be based on the action instead of assumed after the user authenticates ^[12]. Each of those costs something. Per-instance secrets need something that mints and expires them, so a static value in an environment file stops being enough. Request-scoped identity has to be carried through every hop between the agent and the API. An agent running on a schedule has no acting user at all, so someone has to decide what identity a cron job acts as. The New Stack piece puts the swap in one line: "Replace fixed, permanent tokens with dynamic, temporary credentials generated on the fly." ^[13]

The audit itself is short. Ask what each credential can reach now, because scope creeps and no review gets scheduled until something breaks ^[20]. Ask whether authorization is granted per-site, per-repository or per-Workspace, or all or nothing ^[16]. On that second question the article is blunt: "If an integration doesn't give you control over scope at connection time, that's the finding, not a footnote." ^[14] Its author writes that at Webflow, MCP integrations are treated the same way as other third-party components with access to customer data ^[15].