How to Test Multi-Server MCP Agents for Cross-Boundary Data Leaks

The fastest way to find a cross-boundary data leak in a multi-server MCP agent is not to review each server’s permissions again. It is to plant a recognizable marker in one server’s outputs, run the agent through realistic multi-step tasks, and check whether the marker shows up in another server’s tool-call arguments. Permission review cannot catch this class of leak, because the leak is not a bad tool call. It is two good ones.

That is the core finding of MCPHunt, an evaluation framework for cross-boundary data propagation in multi-server MCP agents (self-reported preprint, retrieved 2026-10-26), and it reframes how to test an agent wired to, say, an internal wiki, a file store, and an external SaaS tool. The unit of risk is not the server. It is the boundary between co-resident servers, crossed through the agent’s shared context.

The leak no permission scope sees

The framework’s motivating example is deliberately mundane:

“Consider an enterprise deploying an MCP agent to migrate a project between directories. The agent reads configuration files containing API keys, copies them to the target location, and reports success. No adversarial prompt was involved. No jailbreak was attempted.” (arXiv:2604.27819, self-reported)

Every step is a faithful execution of a legitimate task. The problem is compositional, in the paper’s words: “each individual tool call is benign in isolation; the propagation emerges only from their combination through multi-step execution.” The framework draws a useful distinction here. Credentials landing in agent output is a deployment risk that infrastructure controls should handle. Credentials being carried into a destination the task never asked for, when the task requested only a summary, report, or script, is a safety failure. Your audit should hunt the second one.

Why per-server review fails structurally

Two control layers most teams already rely on are structurally blind to this. The paper states it plainly:

“tool-level permissions cannot prevent propagation because the agent needs both read and write access. Runtime guardrails (Rebedea et al., 2023; Invariant Labs, 2025) check individual tool calls but do not track data flow across calls—a read followed by a write is two benign operations that together constitute policy-violating propagation.” (arXiv:2604.27819)

You cannot fix this by tightening scopes, because the migration task genuinely needs read on server A and write on server B. And per-call guardrails see each call alone, with no memory of where the argument values originated.

The trust model makes this worse than it looks. Trivial Trojans (self-reported preprint) describes the structural issue: “Once a server is installed, however, it can interact with any other installed server through the AI agent as an intermediary. This creates implicit trust relationships between servers that users may not anticipate.” When you add a fourth server to an agent that already has three, you are not adding one trust relationship. You are adding a bidirectional boundary with every server already installed, mediated by a context window that does not label provenance.

Boundary-by-source: what to seed first

Not every source of content entering the shared context carries equal risk, and audit time is finite. The MCP Pitfall Lab (self-reported preprint) names three threat surfaces worth structuring a matrix around: tool metadata consumed during discovery and planning, untrusted tool outputs carrying indirect prompt injections, and multi-modal inputs whose extracted text steers downstream tool calls. Combined with the propagation framework’s read/write pairing analysis, a practical prioritization matrix looks like this:

The read/write pairing column of your own inventory matters more than any published ranking: a source only leaks across a boundary if some realistic task lets its content reach a write call elsewhere. Map those pairs first.

The seed-and-trace audit procedure

The mechanics already exist at bench scale. MCP-SandboxScan’s SandScope (self-reported preprint) “takes an untrusted third-party MCP tool or server, instantiates distinguishable audit sources, adapts the target to either a WASI-backed or native MCP execution path, records boundary-visible runtime evidence.” Adapted to a multi-server flow audit, the procedure is:

1. Inventory read/write pairs. For each server pair (A, B), list the realistic tasks in which the agent reads via A and writes via B. These are your candidate boundaries.
2. Seed each source with a distinguishable marker. Unique tokens per server: planted in tool-call arguments, mounted files, environment values, and fixtures. SandScope’s argument for runtime tracing over static review is that “obfuscated filesystem (FS) access or secrets derived from runtime file reads may be invisible to signature- or description-level scans yet surface during execution.”
3. Replay realistic multi-step tasks. Not attack prompts. The propagation framework’s whole point is that benign tasks leak, so replay your actual workload: migrations, summarizations, report generation, sync jobs.
4. Trace markers at the boundary. Log every tool call’s arguments at the host. Alert on any marker read via server A appearing in a call to server B. The propagation framework’s proposed mitigation is a runtime taint guard that redacts tainted values at exactly this point, the write call.
5. Classify findings. Marker in the final output to the user is a deployment risk. Marker in a write call the task never requested is a propagation failure.

For reproducibility, MCP-Injector (self-reported preprint) offers a drop-in, seeded fault-injection middleware that “injects such external faults at the interface between the agent and the MCP server, rather than within server internals.” Content faults at that interface are precisely where you would insert seeded outputs without modifying the servers under test.

Cheap triage before runtime testing

If you have many servers and little time, metadata triage is a defensible first pass. The no-box analysis of 20 widely deployed MCP servers (all figures self-reported) found that “registration-time metadata alone identified 143 candidate injection flows, 75.5% of which were confirmed reachable at runtime” (arXiv:2609.10854). On cost, the paper reports an average of “$1.65 per server” (arXiv:2609.10854, self-reported), requiring no credentials or source code and involving no risk to live services. A 75.5% runtime confirmation rate (arXiv:2609.10854, self-reported) makes this a sensible way to rank which servers get the full seed-and-trace treatment.

One caveat before you lean on tooling here: a reliability study of MCP security scanners (self-reported) concluded they “are not yet reliable enough for ecosystem-level security assessment,” and the largest prior dynamic study covered only 1,360 servers (arXiv:2607.11086). Scanner verdicts can prioritize; they cannot substitute for the flow audit.

Expect friction, too. In a random draw of 400 npm/stdio servers from a 24,135-server registry census (self-reported), “only 48.8% complete an initialize handshake,” and 37.5% never started at all (arXiv:2609.10962). Your harness must tolerate targets that simply fail to boot. That registry is growing at roughly 195 net new servers per day (self-reported, same census, measured 2026-07-14 to 2026-08-22), which is the growth pressure behind casually adding one more server to an agent.

Where to place the gate

The architectural answer is unusually clean. An HTN coordination study (self-reported) observes that “the Model Context Protocol (MCP) isolates servers by design: only the host can orchestrate cross-server workflows.” Servers never talk to each other; every cross-boundary flow passes through the host orchestration layer. That makes the host the only place a flow gate can see everything, and the natural home for taint tracking, marker tracing, and write-call redaction. The same study demonstrates a per-step audit trail over a Server-Sent Events stream, “start, complete, error, with millisecond durations—that a domain expert can inspect post hoc,” which is the logging substrate a flow audit needs.

Two complementary placements exist. A proxy aggregator pattern (self-reported) namespaces tool names by server and routes each call to the correct upstream, preserving per-server identity behind one endpoint; that identity is what makes provenance tagging feasible. And provenance is the deeper fix: the no-box study recommends that servers “preserve its provenance and separate it structurally from server-generated output so that hosts can distinguish data from instructions.” Sandboxed execution, per SandScope’s WASI-backed path, limits what a compromised tool can touch but does not by itself stop a value from riding the agent’s context to another server.

Two failures sit outside what any flow gate catches. Trivial Trojans demonstrated a deliberately malicious weather server exfiltrating real financial data from a banking server through Claude Desktop, using only free tools; a taint guard tuned for benign-task propagation is not a trojan defense. And cross-server tool-name ambiguity (self-reported) means that when tool names collide, “the system enters an ambiguity regime where the orchestrator is able to pick an unwanted provider under realistic resolution policies.” Namespacing at a proxy addresses the second; the first needs the scoped capabilities, isolation boundaries, and signed attestations the Trivial Trojans authors note are missing at the protocol level.

What the evidence cannot yet settle

Honesty about limits matters before you budget for this. MCPHunt is a single self-reported preprint, and its numbers come from synthetic, researcher-designed tasks run in one harness across 8 servers (filesystem, git, memory/KG, SQLite, fetch, time, shell, browser); validation against real enterprise MCP traces remains future work. Within that scope the findings are specific: across five named models (GPT-5.4, GPT-5.2, DeepSeek-V4-Flash, Gemini-3.1-Pro, and MiniMax-M2.7), policy-violating propagation rates run 11.5–41.3%, per-mechanism rates for GPT-5.4 span 0.0% to 74.4%, and browser_to_local is high for every model (66.7–92.3%). Those numbers strengthen, not weaken, the case for flow-level auditing. One caveat travels to your own audit: detection is exact-match on canary strings, so encoded, hashed, or paraphrased propagation is not counted, and the reported rates under-count total sensitive-information exposure.

The runtime taint guard was measured, but narrowly. A live pilot on one model (DeepSeek-V4-Flash) and one mechanism (browser_to_local, 39 pairs over 15 tasks, prompt text identical across arms) found the actual-sink unsafe rate fell from 79.5% to 51.3%, with the guard blocking 49 write attempts (at least one block in 69.2% of guarded traces), while task success moved from 76.9% to 79.5% on a confidence interval that spans zero. The authors state the evidence “neither isolates a causal defense effect, establishes cross-model behavior, or supports a utility non-inferiority claim,” and the 51.3% residual makes this a partial guard. Treat write-call redaction as demonstrated in exactly one narrow setting, not as a proven control. Mitigation effectiveness for provenance tagging and proxy isolation remains unmeasured in the available sources.

The adversarial picture is worse. A survey of execution-security research for AI coding agents (self-reported) reports “failure rates from 69% to 98% of real denylists” (arXiv:2607.05743) in policy-enforcement studies, and notes no isolation paper re-evaluates its own defense under that adversarial setting. Any gate you deploy against these flows should be assumed partially porous under adaptive pressure, so monitoring must continue after the gate ships. And capability benchmarks do not certify safety: MCP-Atlas (self-reported; 36 production servers, 220 tools, 1,000 tasks, with the best model failing nearly one in five tasks) states it “should therefore be used as a diagnostic benchmark for reliability and failure analysis, not as a certification that an agent is safe for safety-critical, privacy-sensitive, or high-stakes deployment.”

Checklist before granting broad tool scopes

Before you widen an existing agent’s scopes or add another server:

• Map every read/write pair across servers that a realistic task could chain. These are the boundaries to gate.
• Run the metadata triage pass first; at $1.65 per server (arXiv:2609.10854, self-reported) it is cheap prioritization, not coverage.
• Seed markers per source (tool output, files, retrieval) and replay your actual workload, tracing markers into write-call arguments at the host.
• Gate or redact at the write call in the host orchestration layer, and keep a per-step audit trail.
• Namespace tool names through a proxy so every value’s originating server is identifiable.
• Assume residual leakage. Pair the flow audit with containment, and log for the flows the gate misses.

If a leaked marker would mean rebuilding a customer’s incident response rather than re-running a sync job, the audit cost is not the question; it is the cost of skipping it. The evidence says per-server review never had a chance of seeing this failure. Flow-level testing can, and it is runnable now.

Frequently Asked Questions

How much does the metadata triage pass cost per server?

On cost, the paper reports an average of “$1.65 per server” (arXiv:2609.10854, self-reported), requiring no credentials or source code and involving no risk to live services.

What is the recommended first step in the seed-and-trace audit procedure?

1. Inventory read/write pairs. For each server pair (A, B), list the realistic tasks in which the agent reads via A and writes via B. These are your candidate boundaries.

Where should the flow gate be placed in the architecture?

Servers never talk to each other; every cross-boundary flow passes through the host orchestration layer. That makes the host the only place a flow gate can see everything, and the natural home for taint tracking, marker tracing, and write-call redaction.