Your AI Agent's Audit Log Is Worthless: Why Detection Fails and What Actually Works
August 2026
In the span of three weeks, the AI agent ecosystem got hit by four separate incidents that should have every security team rethinking how they approach agent observability:
filesystem-pro-plus supply chain attack (Aug 6): A malicious MCP server was downloaded 14,300 times before anyone noticed. It exfiltrated OAuth tokens, keystrokes, and clipboard data from 47 confirmed organizations — including three YC companies and a foundation model lab's internal deployment. It was discovered via a pastebin dump, not a security tool.
RufRoot / CVE-2026-59726 (Jul 29, CVSS 10.0): Ruflo, an open-source agent platform with 67,000 GitHub stars and 10 million downloads, exposed 233 tools over HTTP with zero authentication. One unauthenticated POST gave full command execution inside the container.
Microsoft UFO / GHSA-24fq-m9rr-g3mm (Aug 10, CVSS 9.4): The Mobile MCP servers exposed ADB-backed Android functionality — screenshots, UI injection, app launches — without any authentication. No API key, no token, no header check.
Paperclip supply chain attack (Jul): Typosquatted packages and weaponized AI skills accumulated over 300,000 installations. Automated scanners caught the Python packages within hours; the malicious skills evaded detection entirely.
These are not edge cases. They are the new normal.
The Pattern Nobody Wants to Admit
Every one of these incidents shares a structural flaw: the security record is produced by the same system that executed the action.
When your MCP server, agent runtime, or gateway writes a log entry saying "tool X was called with arguments Y," that log is:
- Written by the system being monitored
- Stored in infrastructure that system controls
- Mutable by anyone with administrative access
- Vulnerable to the same compromise that enabled the attack
This is the self-attestation gap, and it is structural, not a feature deficit. No amount of logging, guardrails, or "AI-powered threat detection" closes it from inside the runtime — because if the runtime is compromised, the log is compromised too.
Detection-based security answers the question: "Does this look suspicious?" It relies on pattern matching, anomaly detection, and ML models that produce F1 scores and false positives. It misses GhostSplice attacks (where split-instruction fragments individually look benign but combine maliciously) and catches things after the fact.
What's needed is a different question entirely: "Can a third party prove what this agent actually did, without trusting the system that produced the record?"
Cryptographic Receipts: Moving from Detection to Verification
A cryptographic receipt for an agent tool call works like a receipt at a store: it's a signed artifact you can hand to someone else — an auditor, a regulator, a customer — and they can verify it independently, without trusting the store's internal systems.
Here's what a minimal receipt looks like:
{
"version": "1.0",
"action": "send_email",
"args_digest": "sha256:abc123...",
"verdict": "allow",
"timestamp": "2026-08-26T10:00:00Z",
"issuer": "payments-agent-01",
"signing_algorithm": "Ed25519",
"public_key": "base64...",
"signature": "base64...",
"prev_receipt_digest": "sha256:def456...",
"attempt_id": "urn:uuid:..."
}
The design principles:
The algorithm is inside the signed payload. An attacker can't downgrade Ed25519 to "none" because the algorithm field is part of what's signed. This prevents algorithm substitution attacks.
The public key is embedded in the receipt. An attacker can't sign with their own key and present it as the legitimate issuer — the embedded key would mismatch. This prevents key substitution.
Arguments are hashed, not stored. The args_digest is a SHA-256 hash of the canonical JSON arguments. If anyone modifies a single argument after signing, the digest changes and verification fails. This prevents parameter tampering without exposing potentially sensitive argument values.
Receipts are hash-chained. Each receipt includes prev_receipt_digest, creating a tamper-evident chain. You can't delete or reorder a receipt without breaking the chain.
Canonical JSON makes field order irrelevant. Using RFC 8785 JSON Canonicalization Scheme (JCS), the same logical object produces the same bytes regardless of key ordering. A reordered JSON object still verifies — which is correct, because reordering keys doesn't change the action.
Verification requires no network calls and no trusted third party. Given a receipt and the signer's public key, anyone can verify it using only standard Ed25519 and SHA-256 — both of which are available in every programming language's standard crypto library.
How This Would Have Helped in the August Incidents
filesystem-pro-plus: If the agent runtime signed every tool call with a key the MCP server couldn't access, the malicious server's unauthorized file reads and OAuth token exfiltration would produce receipts signed by the legitimate agent key — but with args_digest values that don't match any authorized workflow. An external verifier would flag the anomaly immediately. The attacker couldn't suppress or forge receipts because they don't hold the signing key.
RufRoot: With cryptographic receipts, even an unauthenticated attacker reaching the MCP bridge couldn't produce valid receipts for their arbitrary commands. Each tool call requires a signature from the agent's key, which the attacker doesn't possess. The command executes but produces no valid receipt — which is itself a detectable event.
UFO: Same principle. Unauthenticated access to the MCP servers doesn't grant the ability to sign receipts. Screenshot retrieval and UI injection without a valid signed receipt becomes immediately visible as unsigned activity.
Paperclip: Weaponized skills can execute, but every action they take produces a signed receipt tied to the legitimate agent identity. The receipts create an immutable chain of exactly what the malicious skill did — data exfiltration, credential access, lateral movement — which is exactly what forensics teams need but currently lack.
The Honest Limits
This approach is not a silver bullet, and it's important to be precise about what it does and doesn't do:
It's pre-admission evidence, not execution boundary enforcement. It proves what was decided at the decision boundary, not what happened after the decision was made. If the system is compromised after admission, the receipt is still valid but the execution may have diverged.
It's not dishonest-runtime defense. If the orchestrator itself is compromised and feeds fabricated events to the signer — for example, a fake "human approved" event — you get a valid receipt for fiction. The signer has no independent way to know the human didn't actually approve it. That's a confused deputy problem, and it requires an external witness with an independent source of truth (e.g., the human's actual approval service signing separately).
It doesn't prevent attacks. It makes them provably detectable after the fact, and it creates evidence that can be handed to auditors, regulators, or incident responders without trusting the compromised system. Prevention still requires sandboxing, least privilege, network controls, and all the usual security hygiene.
But what it does do is close the self-attestation gap: it produces a record that the thing being monitored cannot unilaterally alter.
What You Can Do Today
If you're running agents in production and want to start producing verifiable evidence:
-
Install the linter (zero config, runs in CI):
npx ccs-lint -
Try the verifier:
pip install ccs-verifier - Check the conformance vectors (MIT licensed, no dependency on reference implementation): github.com/DSHCorrectover/ccs-conformance-vectors — includes a ~15-line independent verifier using only standard crypto libraries
- MCP server integration: github.com/DSHCorrectover/ccs-mcp-server
The conformance vectors include ten test cases: valid allow/deny receipts, tampered verdicts/actions/arguments, missing signatures, algorithm substitution, key substitution, field reordering, and chain-linked receipts. You can use them to validate any implementation — yours or a vendor's.
The Bottom Line
Detection-based security is a losing game against a compromised runtime, because the runtime is the thing writing the detection log. The question isn't "how do we detect more attacks" — it's "how do we produce evidence that survives compromise."
Cryptographic receipts don't prevent the next filesystem-pro-plus. But they ensure that when it happens, you have a chain of evidence the attacker can't touch — and that's the difference between "we think this happened" and "we can prove it."
Built by Correctover. CCS (Correctover Conformance Shape) is an open receipt format for agent tool calls based on RFC 8785 (JCS) and RFC 8032 (Ed25519). Reference implementation and MCP server are linked above. Commercial proxy and audit services at correctover.com.
Top comments (0)