MCP tool presence is not proof of user permission to invoke it

A tool can advertise that it is read-only, or a server can ask a host to display a confirmation. Neither guarantees that a human actually authorized a destructive call. A 2026 study inspected MCP hosts and sampled tools to locate where approval is enforced, then tested a separate malicious-result fixture. Research.

In the authors' selected 25-application frame, 60.7% of weighted host-tool pairs had no enforced human approval by default. The corresponding figure for 41 hosts, including SDKs, was 74.9%. The host populations and weightings are different, so neither number describes the proportion of all MCP users or of deployed destructive actions. At the host level, 16 of 25 applications and 32 of 41 hosts lacked a default per-call approval step.

The live checks expose a second boundary: in an annotation-only server, some clients executed a benign requested deletion without prompting; in a flag-based server, the model itself could set the confirm=true argument. A flag the agent can provide is not independent human approval. A fail-closed server-side elicitation gate behaved differently from a descriptive tool annotation. In a separate injected-note experiment, four of five tested low-cost models executed unintended deletions in 479 of 960 runs for those four models; the fifth produced no such deletions in its 240 trials. The fixtures were controlled, not reported customer harm. Live checks, Tables 2 and 3.

The operational test is twofold. First, the backend must reject actions outside the authenticated principal's rights. Second, any action requiring a human must carry independent confirmation for the exact target and effect, not an agent-chosen boolean or an instruction inside a returned note. This is also why agent-readable email OTPs and effect-bound approval belong in the same architecture discussion but not the same incident count.