MCPVenom: Separate Tool Compliance from Verified Canary Exfiltration

Sources checked: 10 November 2026. FailSafe Research.

An agent can describe an unsafe action, dispatch a tool call or cause data to reach a destination. Those are different outcomes. MCP assessment evidence should establish which one occurred and whether the application enforced its own authority boundary.

Read the study's denominator

The November 2 MCPVenom paper defines 9,720 planned framework/model/scenario combinations. Its table records 2,113 vulnerable, 7,102 resistant, 237 error and 268 skipped cells. The reported 22.9% is 2,113 divided by 9,215 valid vulnerable-or-resistant outcomes. Error and skipped cases are excluded, rather than counted as secure.

Among vulnerable outcomes, the paper separates 1,371 dispatched-call cases, 487 confirmed network contacts and 255 verified synthetic-secret exfiltrations. These are evidence tiers, not three counts to label as stolen production secrets. The authors' code audit found no intentional tool-description defense in the tested configurations; that statement does not establish the condition of every current deployment.

Turn evidence tiers into acceptance criteria

For a fictional document agent, first record the requested operation and the identity that makes it. Then collect the tool server's decision. If an approved synthetic marker is involved, record whether it reaches the agreed canary receiver. A final answer that refuses to display data cannot prove the data never reached a tool or external processor earlier in the sequence.

FailSafe's MCP assessments scope tool descriptions, tool responses, connected identities and the effects a runtime permits. Our assessment workflow records expected and observed boundaries and repeats relevant cases after correction. Canary-based execution evidence belongs in the agreed test plan where the owner permits it; a benchmark result cannot substitute for that application's measurement.

Include ordinary implementation boundaries

A separate November 2 AWS bulletin describes CVE-2026-116635 in the AWS Serverless MCP Server. Versions before 0.2.1 could, under stated conditions, allow JSON-file access outside the intended directory; enabled writes expanded the possible effect. AWS identifies 0.2.1 as the fixing version. The advisory concerns a particular server component, not the whole MCP protocol.

For defenders, this means the assessment must examine the server's filesystem and permission boundary as well as the model's interpretation of tool metadata. Confirm which deployed package and derivative code are present, apply the vendor fix and retest approved boundary cases. An updated dependency entry does not establish what a running worker loaded.

Use research without inventing deployment coverage

FailSafe's AttackBench work with NEAR separately examines model-runtime combinations. The two studies use different tasks and outcome definitions, so their scores are not directly comparable. Their practical connection is the need to record the model, runtime, permissions and observed action together.

Start with the MCP scope worksheet and retain a legitimate control case alongside each adversarial case. Agree the synthetic marker, receiver, action budget and stop conditions before execution. A framework change or a new tool description should prompt a review of which previous results still apply.