MCP Security in 2026: The Human-in-the-Loop Gap in the Spec

The Model Context Protocol’s own specification admits, in plain language, that it cannot enforce human approval before an AI tool acts — that guarantee is a recommendation for the application built on top of MCP, not a rule MCP itself checks. For any agency connecting its own AI, or a client’s, to real business systems over MCP, that single sentence is the whole risk model. The protocol tells your AI what tools exist and what they claim to do. Whether a human actually sees and approves what’s about to happen is left entirely up to whoever built the client.

What does the MCP spec actually say about consent?

The specification’s own “Key Principles” section is direct about the limits of what the protocol guarantees:

“1. User Consent and Control — Users must explicitly consent to and understand all data access and operations… 3. Tool Safety — Tools represent arbitrary code execution and must be treated with appropriate caution… Hosts must obtain explicit user consent before invoking any tool.”

And then, immediately after:

“While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications…”

That’s the gap in one paragraph. The principles are written with lowercase “must,” which under the convention MCP’s specification follows means recommendation, not protocol-level requirement. The separate Tools specification repeats the same structure in its “User Interaction Model”: “there SHOULD always be a human in the loop with the ability to deny tool invocations,” alongside guidance that applications “SHOULD… present confirmation prompts to the user for operations.” Recommended. Not enforced. Not something an MCP server can verify a client actually does.

This isn’t a flaw unique to MCP — no protocol can force an application built on top of it to behave a certain way. But it does mean “our AI is connected over MCP” tells you nothing about whether a human is actually in the loop. That’s a claim about the specific application, and it has to be verified there, not assumed from the protocol name.

What happens when that gap gets exploited

Three documented incidents show what the gap costs in practice, at three different points in the chain.

Asana, June 2025 — the isolation failure. Asana launched an MCP integration on 1 May 2025. A tenant-isolation bug was identified on 4 June, and the integration was taken offline for roughly two weeks while it was fixed. The flaw let data from one organisation — tasks, project metadata, team details, comments and uploaded files — become visible across organisational boundaries. Roughly 1,000 customers were affected, and the vulnerability had existed since the feature’s first day. This wasn’t a human-in-the-loop failure specifically — it’s a reminder that the isolation boundary around what an MCP integration can reach matters as much as who approves the call.

GitHub, May 2025 — the “toxic agent flow.” Security researchers at Invariant Labs demonstrated an attack where a developer asked an AI agent, connected via GitHub’s MCP server, to review open issues on a public repository. One planted issue contained hidden instructions. The agent read them, then used its own already-authorised access to the developer’s private repositories to pull sensitive information and post it in a pull request visible on the public repo. Every individual tool call the agent made was one the user had genuinely authorised. What wasn’t authorised — and what no single approval prompt would have caught — was the combination: read a public issue, then act on private data, then publish externally. Invariant’s own conclusion was blunt: “This vulnerability cannot be resolved through server-side patches.” It’s an architectural problem in how permissions compose across tool calls, not a bug in GitHub’s code.

Microsoft, 30 June 2026 — the re-approval gap. Microsoft’s security team published a direct warning about a mechanic baked into the trust model itself: a tool’s description — the text a user reads and approves before letting an AI use it — can change after that approval, and nothing in the protocol requires the client to ask again. Microsoft’s own words: “In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.” A tool that looked safe on day one can be quietly redefined on day thirty, and a user who approved it once has no reason to know it happened. Microsoft described MCP as “the fastest-growing part of the agentic AI supply chain” — which is exactly why this particular gap matters more every month it goes unaddressed.

Alongside these, two concrete CVEs are worth knowing if you’re evaluating any MCP tooling: CVE-2025-49596, a critical (CVSS 9.4) remote code execution flaw in Anthropic’s own MCP Inspector tool, and CVE-2025-6514, a critical (CVSS 9.6) command-injection vulnerability in the widely-used mcp-remote package, triggered by a malicious server’s authorization URL. Both are patched, but both illustrate that the tooling around MCP has had the same class of gap as the protocol’s trust model: things a user reasonably assumed were inert turned out not to be.

What “human-in-the-loop” needs to mean, in practice

Given that the protocol won’t enforce it, the questions worth asking about any AI-connected tool — including sSystm’s own — are the ones that turn “human-in-the-loop” from a slogan into something checkable:

1. Does a write actually wait for a person, every time, or only on first use? A single approval at connection time is not the same guarantee as approval per action.
2. If a tool’s description or behaviour changes, does that trigger re-approval, or does it silently take effect? This is precisely the gap Microsoft flagged in June 2026.
3. Is the token or credential scoped to one organisation’s data, or could a compromised session reach across tenants? This is what failed at Asana — not the approval step, but the isolation boundary behind it.
4. Is there an audit trail of what the AI actually did, separate from what it was asked to do? Composed attacks like the GitHub case only show up in hindsight if the individual steps were logged.
5. Who governs the specification, and how actively is the security model evolving? MCP was donated to the Agentic AI Foundation under the Linux Foundation on 9 December 2025, with Anthropic, Block, OpenAI, Google, Microsoft, AWS and Cloudflare all named as involved — a sign the ecosystem is consolidating around shared governance rather than each vendor patching independently.

sSystm’s own MCP endpoint issues a per-user token scoped to that user’s organisation, and every write an AI proposes — through the built-in Build AI or a connected external client — sits as a pending action until a person approves it. That’s not a claim that MCP enforces this; it’s the opposite point. Because the protocol doesn’t, it has to be built deliberately into the application, and it’s worth checking for explicitly rather than assuming from “it uses MCP.” Read more about how the approval boundary works in how AI and humans share the sSystm workspace, what the isolation model looks like in our security architecture, and the mechanics of connecting external AI over MCP in how to connect your AI to your agency with MCP.