MCP security: keeping confidential data out of tool calls

A guide for teams running MCP servers and agents. About 6 minutes.

The Model Context Protocol gave agents a clean way to reach tools, files, and services, and with it, a security field appeared almost overnight. Researchers reported more than 40 CVEs against MCP in the first four months of 2026 alone, and audits of real-world servers keep finding the same structural gaps: one 2026 analysis put roughly 40% of publicly exposed MCP services as having no authentication at all.

Most of that attention, correctly, goes to the loud failures: prompt injection, tool poisoning, missing auth, servers you did not vet. This page is about a quieter one that those defenses do not cover: the confidential data that passes through tool calls in the ordinary course of an agent doing its job.

First, what this is not

MCP security is a broad field, and confidentiality is one slice of it. To be useful you have to say what a tool does not do, so here it is plainly. This page, and the approach it describes, is not about:

• Prompt injection or tool poisoning, where a malicious input or a booby-trapped tool steers the agent. That needs input controls and tool vetting.
• Authentication and server trust, the 40% with no auth, token passthrough, the servers you should not have connected. That needs auth and supply-chain hygiene.
• Command injection, path traversal, SSRF and the rest of the CVE surface. That needs the usual application-security work on the servers themselves.

Those are real and they are not the subject here. The subject is narrower and, precisely because it is quieter, often unowned: when your agent is legitimately allowed to act, is the content it moves reaching a place that is allowed to see it?

The confidentiality gap in a tool call

A tool call carries content: the text of a document, a record, a summary the agent assembled. Confidentiality is contextual, the same record is fine for one destination and a breach for another, and an agent that serves more than one context has no built-in sense of which is which. Frontier models already fail this test on their own: in the ConfAIde benchmark (ICLR 2024), GPT-4 revealed information a person would have kept private in 39% of scenarios, and a 2026 study found multi-turn agent settings pushed that above 45%, with leakage staying over 37.8% even when the agents were explicitly instructed not to leak.

MCP raises the stakes because the content does not just get generated, it gets moved: from one server to another, into a message, out to a destination. Researchers have noted that static analysis catches known-bad patterns but misses sequence-level cases, where each authorized tool call looks fine and the exfiltration is in how they combine. That is the shape of a confidentiality leak: no single call is the villain, but the wrong subject reached the wrong recipient across them.

Why the check has to be local

The instinct is to route tool inputs and outputs through a security service that inspects them. For confidentiality specifically, that instinct backfires: security researchers have flagged that SaaS-based inspection can itself become an exfiltration path, because the tool inputs and outputs, the very content you are trying to protect, leave your controlled environment to be checked. Sending your confidential data to a cloud to ask whether it is safe to send is the leak you were trying to prevent.

So the check has to run where the data already is: on your own machine, with nothing leaving it.

Where Signato fits

Signato is a deterministic check you wire into the point where an agent acts. Before a tool call executes, it checks the content and its destination against who-can-know-what, and blocks a forbidden pair before the call completes. On Claude Code it wires in as a PreToolUse hook; on other setups it runs as the `signato check` step you call at the tool boundary. It is deterministic (same input and policy, same decision, not a model's guess) and it runs 100% on your machine, so the content it inspects never leaves.

Two honest boundaries. First, it covers the confidentiality slice, not the rest of the MCP threat model: it is not an answer to prompt injection, missing auth, or server CVEs, and it does not pretend to be. Pair it with the controls those require. Second, it covers the points you instrument, the tool calls and hand-offs you wire it into, not a magic view of your whole system. Within that scope it is deterministic, auditable, and local.

What to do with this

If your agents run over data with any internal boundary, work the MCP threat model in layers, and do not let the confidentiality layer go unowned because it is quieter than injection. Treat prompt-level instructions as a mitigation, not a control, and put a deterministic check at the tool calls where content actually leaves. Signato for AI agents shows how it wires in; the 30-day local trial runs entirely on your machine, no data leaving, and installs in minutes.

This page is educational, not legal or security-audit advice. Your MCP deployment's full risk picture depends on your servers, tools, and data; for a complete assessment, involve your security team. What is settled here is narrower: for the confidentiality of what your tool calls move, the check has to be deterministic, local, and at the point of action, not a prompt instruction and not a cloud round-trip.

This is educational material and a starting point, not legal advice. Whether a particular tool is covered, and which obligations apply to your organisation, depend on the facts of that tool and on the rules in force where you operate. For your situation, consult a qualified lawyer. Signato is not a law firm and does not certify compliance.