Case studies
Worked examples built on real, documented 2025 MCP incidents, not invented scenarios. For each one: what would Herkos actually have done? The answer is consistent, and it is the reason for the product's direction.
Herkos is weak at prevention and strong at provable audit. The headline MCP attacks defeat tool-name allowlisting: they ride tools the user already approved, or leak server-side where an in-path broker cannot see. What Herkos uniquely gives you is a signed, offline-verifiable record of what the agent did and what code touched the model. The anchor is the receipt, not the broker.
Three in depth
Each of these has its own page: the verified incident, the step-by-step mechanism, where Herkos helps and where it honestly does not, and a real run of this repo's binary on that scenario.
GitHub MCP toxic flow →
A public-repo issue injects an agent into leaking private repos through an approved create_pull_request. A tool-name allowlist passes every step. Herkos's win: the signed audit log - the forensic record of what ran. Invariant Labs, May 2025. No CVE (architectural).
postmark-mcp backdoor →
A malicious npm email server BCC'd every message to an attacker, server-side, where a client broker can't see it. The boundary case - but herkos scan flags the unpinned, unbrokered setup that let it land. Koi Security, Sep 2025.
MCPoison rug-pull →
A Cursor MCP config approved once was trusted forever, so a post-approval swap ran silently. Herkos does not catch the command swap; scan --baseline catches the description-poisoning cousin. Check Point, CVE-2025-54136, Jul 2025.
Two more, in brief
Supabase SQL leak / the lethal trifecta
A Cursor agent with a service_role key reads injected SQL in a support ticket and leaks integration_tokens - all three trifecta legs (private data, untrusted content, an exfil path) in one session. Broker: does NOT prevent (the query tool is allowed); the signed log is the post-incident record. General Analysis / Simon Willison, Jun 16 2025.
Compliance audit - provable provenance
"Prove which source files were sent to the model this session." Without a receipt there is no answer; Herkos's signed Merkle receipt verifies offline with only the public key. SOC 2 / EU AI Act Art. 12.
What the set proves
| Incident | Broker prevents? | Receipt / audit value |
|---|---|---|
| GitHub toxic flow | No (allowed tool) | Strong |
| postmark-mcp | No (server-side) | Weak |
| MCPoison rug-pull | Partial (baseline diff) | Supporting |
| Supabase / trifecta | No (injection) | Strong |
| Compliance audit | n/a | Strong - the wedge |
Four of five say the same thing: the broker rarely prevents the real attacks; the honest value is harm-reduction plus a forensic record, not prevention. The signed receipt is the strongest of those legs: a tamper-evident, offline-verifiable record of every brokered tool call - the tool, a hash of the request, and the allow/deny decision, in order - checkable by a third party with only the public key.
The problem is real, but every pillar here is commodity (native host controls, Pipelock, Snyk/Invariant), and even the smart future version of the one novel idea is already in the literature (NeuroTaint, OCELOT, CaMeL, MCP-DPT). Incident details are from the cited 2025 sources; the receipt output is a real run of this repo's binary. The value of this page is the honest map.