The Model Context Protocol, the common way to plug tools into AI agents, says there should always be a human who can refuse a tool call. It doesn't say who has to ask. A tool server can ask the user through the app it is connected to, and the app (a coding assistant, a chat client, or something a team built on an agent SDK) can ask before passing the call on. A group of independent researchers read the source code on both sides to see whether anyone does.
On the server side, they sampled a large slice of the official MCP registry and coded every tool that could delete data, send messages, move money or run commands. An estimated 90% of those destructive tools have no confirmation of their own. Most of the rest rely on a "confirm" argument that the model calling the tool can fill in itself. Of the handful of servers that do ask the user properly, most go ahead anyway, or fall back to that same flag, when the app on the other end can't pass the question along.
On the app side, 32 of 41 popular open-source agent apps and SDKs had no approval step before an ordinary MCP tool call in a default setup. That includes widely used coding and chat tools such as Cline, OpenHands and LibreChat, and every agent SDK examined, from LangChain's MCP adapters to the OpenAI Agents SDK. Several of the SDKs offer an approval option. It ships switched off.
"Most defaults on each side leave confirmation to the other."
The researchers then planted an instruction in the output of a harmless "list notes" tool telling the agent to also delete a note called "tax records 2025". Run through four SDKs on default settings, most of the low-cost models tested deleted it, in 479 of their combined 960 runs. Whenever a model tried, nothing stood in its way. On the server that demanded a confirm flag, models set the flag themselves, often without the injected text telling them to.
"Measured from source on both sides, the human is present when the host prompts and almost never otherwise."
The authors also modelled fixes. If every app prompted for any tool not explicitly marked as safe, the share of destructive calls running unapproved would fall to about 5%. Making every app support the protocol's ask-the-user mechanism would barely move it, because most servers never use that mechanism in the first place.
There are limits the authors state themselves. They measured default code paths, not how anyone has configured these tools in practice, and they count pairings of app and tool, not users or calls. The injection tests used only a few cheap models, so they say nothing about how a frontier model would behave. The study also can't say whether a person who does see a prompt reads it, and a fix that adds prompts will test that harder.
The more useful lesson, on this evidence, is that the protection belongs in whatever a team builds or installs, not in the tool server it connects to. Each side's author can reasonably assume the other is handling it. The researchers quote one server's docs saying it skips its own check "because MCP clients gate destructive tool calls themselves". A team assembling an internal agent from an SDK and a few registry servers is the person in the middle, and by default nobody below them is asking.
That turns into a short audit. List the agents that touch MCP servers with write access, and check that approval is switched on in each one, not assumed. Treat a tool's "destructive" label or "confirm" parameter as information for the model, not a control, since the model can satisfy it alone. When a vendor or an internal platform team says its agent keeps "a human in the loop", the follow-up question is which component asks, and what happens when that component can't.
The finding is also easy to stretch too far. It doesn't show that most deployed agents are deleting things unasked, since operators can switch approval on and the closed-source apps, coded from their documentation, did somewhat better. What it shows is that when nobody configures anything, nobody is asked, which is a narrower problem and an easier one to fix.
Sources
- Yao, J., Yang, Z., Wang, Z. et al., "When Neither Side Confirms: Destructive Tool Approval Across MCP Servers and Hosts" — https://arxiv.org/abs/2611.02527