---
id: "lib-2026-11-02-when-neither-side-confirms-destructive-tool"
type: "library"
title: "When Neither Side Confirms: Destructive Tool Approval Across MCP Servers and Hosts"
lang: "EN"
org: "arXiv (Yao et al.)"
source_type: "Other"
date: "2026-11-02"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-02-when-neither-side-confirms-destructive-tool/"
original_url: "https://arxiv.org/abs/2611.02527"
tier: "A"
tier_name: "Strong evidence"
tier_reason: "Five independent researchers measure MCP servers and hosts from pinned source code with a weighted sample, human-checked labels, live runs and counterfactuals; a clear method on a question few had measured end to end."
summary_basis: "full-text"
original_minutes: "25"
tags: ["ai technology", "agent security", "mcp"]
---

# When Neither Side Confirms: Destructive Tool Approval Across MCP Servers and Hosts

Tier A (Strong evidence): Five independent researchers measure MCP servers and hosts from pinned source code with a weighted sample, human-checked labels, live runs and counterfactuals; a clear method on a question few had measured end to end.

Summary based on the full text.

## In short

An arXiv paper (2 November 2026) by five independent researchers on who asks a person before an AI agent calls a destructive tool through the Model Context Protocol (MCP). The specification wants a human able to deny calls but splits the job between the tool server and the host application. Reading source code on both sides, the authors find a human is asked when the host prompts and almost never otherwise. Most hosts do not prompt by default, so most destructive calls run unapproved.

## Key numbers

- 90%: estimated share of destructive MCP tools with no server-side confirmation (95% CI 82-95)
- 32 of 41: popular open-source MCP hosts and agent SDKs with no approval step by default, including all 16 SDKs
- 60.7%: destructive tool and application pairs with no enforced human approval by default (74.9% across all 41 hosts)
- 479 of 960: runs in which four low-cost models executed an injected deletion through four agent SDKs
- 5.4%: unapproved share if hosts prompted for every tool not annotated read-only or non-destructive

## What it reports

- Servers: in a 1,000-repository sample of the official MCP registry, an estimated 90% of destructive tools have no server-side confirmation (70% no confirmation or annotation, 20% annotation only). Among flagged tools with any confirmation, 93% can still complete without a human answer.
- Elicitation (the server asking the user via the host): 168 tools do it by default; 130 of them still run when the host cannot relay the question, 100 by falling back to a flag the model can set.
- Hosts: of 41 open-source hosts, 7 prompt before ordinary MCP calls (including VS Code, Gemini CLI, Zed, Crush) and 32 have no approval step, including Cline, Goose, LibreChat, Open WebUI, n8n, Dify, OpenHands and all 16 SDKs (OpenAI Agents SDK, LangChain adapters, LlamaIndex, crewAI, AutoGen, Google ADK, Vercel AI SDK).
- For 39 of 41 hosts a destructive annotation changed nothing on the default path.
- Combined: 60.7% of tool and application pairs have no enforced approval; 74.9% across all 41 hosts; 47.5% for applications once seven closed-source apps (including Claude Code and Cursor) coded from documentation are added.
- Injection test: a read-only tool returned an instruction to delete "tax records 2025". Four of five low-cost models executed it in 479 of 960 runs; DeepSeek-V4.1-Flash never did. On the flag server, models set confirm=true themselves in 127 of 169 attempts.
- Counterfactuals: universal elicitation support leaves 56.7% unapproved; prompting unless annotated safe cuts it to 5.4%, at the cost of many more prompts.

## How they got it

Registry repositories were pinned to a commit and read as text. A rule-based extractor flagged possibly destructive tools; two LLM coders from different vendors labelled a stratified 366-tool sample (tier agreement 95%, kappa 0.93), with a third model resolving disagreements. Two human annotators matched the LLM tier on 58 of 60 tools, and seeded test repositories were all coded correctly. Host call paths were traced in source by a coding agent, cross-checked by a second agent on 20 hosts, and 7 hosts were run live against a stub server.

## Limits

- Default settings only; many SDKs offer an approval option or hook that application authors may enable.
- The extractor missed 83% of destructive tools in a full-listing audit; the authors correct for this, but shares carry wide intervals for some tiers.
- Closed-source hosts were coded from documentation, not code; host shares weight each host equally regardless of how many people use it.
- Injection runs used five low-cost models and a stub server, not production setups.

## Why it matters for companies

Any team building agents on an SDK should assume no human approval exists unless it configures one: every SDK examined ships with approval off. Tool annotations and confirmation flags do not put a person in the loop, since the model can set the flag itself. The cheapest control sits in the application: prompt for every tool not marked read-only, and refuse calls when no one can approve them in headless runs. Procurement and security reviews of agent platforms should ask for this default explicitly.

Original: https://arxiv.org/abs/2611.02527