MCP Detect

The problem

MCP tool calls need inspectable evidence.

MCP connects agents to filesystems, ticketing, memory stores, and internal services. A configuration review can list declared permissions, but it cannot show which tools were actually advertised, what arguments moved through them, whether metadata changed mid-session, or whether an undeclared server appeared in live traffic.

So the project asks a narrower question: what evidence can be extracted from MCP traffic, which abuse techniques are detectable from that evidence, and which classes need controls outside telemetry?

Architecture

Capture once, analyze through bounded paths.

1. Observe Transparent proxy Forwards MCP JSON-RPC bytes untouched and emits one JSONL event per message.
2. Structure Telemetry schema Normalizes sessions, server commands, tools, arguments, and direction.
3. Detect Rules and baseline Wazuh handles structural patterns. Python tracks stateful metadata drift.
4. Measure Framework gates Runs fixtures, joins alerts to sessions, measures coverage, and records gaps.
5. Reproduce Frozen evidence Checksums, rule hashes, golden matches, and source-level retests keep each claim inspectable.

Implemented coverage

Five techniques, each with a named evasion.

Measurement discipline

Gates tied to real historical bugs.

Each detection declares its backends, rules, session join, fixtures, status, and known gaps in a detection.yaml. The framework compiler checks schema, rule references, fixture references, session-key correctness, and false positives against a frozen benign corpus. Its tests reconstruct earlier failures so a new detection cannot silently reintroduce the same class of mistake.

The five techniques are behaviors the rules implement. The 12 evasion classes are separate ways those detections can be bypassed: nine leave a signal this sensor can test, while three are structurally invisible at this layer.

Trust boundaries

An AI Bill of Materials from observed traffic.

The framework inventories observed MCP servers, tool names, version hashes, session counts, filesystem access, and network egress, then compares a declared known-good inventory against observations to surface shadow-server candidates. An unrecognized server is reported as unknown and routed to manual review, not assigned a guessed trust level.

Known limits

The blind spots are part of the result.

• Coverage breadth. Five of roughly 85 SAF-MCP techniques are implemented.
• No semantic backend. Prompt manipulation and meaning-preserving obfuscation are out of scope for the current detections.
• Behavior-only compromise. A tool can return manipulated results without changing any visible metadata.
• Encoded content. Base64 and similar transforms bypass plaintext secret matching.
• Self-authored data. Independent or held-out traffic is the highest-value next validation step.
• Offline analysis. The proxy captures traffic, but the workflow is not positioned as inline production enforcement.

Technical series

Inside MCP Detect, from baseline to denied retest.

I documented the project in three first-person articles. The series starts with model-selected benign traffic, pressure-tests the five detections, and ends at the authorization decision that telemetry could not prove.

1. Part 1 Start by watching the agent behave 541 sessions, 1,011 model-selected calls, and the accepted zero-call git_show gap.
2. Part 2 Build the detections, then break them Canonical results, benign regression, ten successful evasions, and the compiler gates those failures created.
3. Part 3 Follow identity into the handler A synthetic cross-tenant defect, exact source fix, and denied authorization retest.

Source

Inspect it yourself.

The proxy, schema, complete synthetic corpora, rules, drift detector, compiler gates, coverage reports, and authorization reference are public under MIT.