Claude Code Fixed 6 Security Bugs in August. Your Agent's Audit Log Still Can't Prove a Thing.

August 2026 was a busy month for Anthropic's security team. In the span of three weeks, Claude Code shipped:

• v2.1.236: Closed a sandbox rename bypass where **/.env deny rules could be evaded by renaming the denied file inside an allowed read region.
• v2.1.238: Isolated headersHelper in .mcp.json so MCP helper scripts no longer run with your credentials, and fixed unbounded memory growth.
• v2.1.243: Fixed missing sandbox network violation details — a blocked curl that exited 0 would report success while a proxy 403 page was silently swallowed.
• v2.1.246: Fixed a credential scoping bug where API keys configured for third-party gateways (ANTHROPIC_BASE_URL) were being sent to Anthropic on every telemetry and metrics call. Also added warnings for Bash allow rules with wildcards before the subcommand.

These are real, serious fixes. The credential scoping bug alone meant teams routing Claude Code through a company LLM gateway were leaking that gateway's key to a second host on every telemetry request.

But look at the pattern. Every one of these fixes is a patch for a specific vulnerability. None of them address the structural problem underneath:

When an AI agent takes an action, the only record of that action is produced by the agent itself.

The self-attestation gap

Here is what a typical agent audit log looks like in 2026:

{
  "timestamp": "2026-08-25T14:32:01Z",
  "action": "bash",
  "command": "git push origin main",
  "user_approved": true,
  "exit_code": 0
}

This log entry is generated by the agent runtime. It is stored by the agent runtime. It is signed by nobody. If the runtime is compromised — by a malicious MCP server, a sandbox escape, a prompt injection that manipulates the agent's own logging logic, or a credential scoping bug like the one fixed in v2.1.246 — the log can say anything.

This is not theoretical. In August alone:

• A malicious npm package (filesystem-pro-plus) compromised 47 organizations including 3 YC companies and a foundation model lab, by distributing a weaponized MCP server through typosquatting.
• RufRoot (CVE-2026-59726, CVSS 10.0) affected a 67,000-star MCP framework with 10 million downloads, exposing 233 tools with zero authentication to remote code execution.
• Microsoft UFO (GHSA-24fq-m9rr-g3mm, CVSS 9.4) allowed zero-authentication remote control of Android devices through MCP.
• The GhostSplice attack showed that splitting a single malicious instruction across multiple prompts drops model refusal rates from 58% to 18%.

After patching each of these, how do you prove that a specific agent action at a specific time was authorized and untampered? You can't — not from the agent's own logs.

Detection vs. verification

The industry's default response has been detection: scan MCP servers for vulnerabilities, flag suspicious behaviors, apply policy engines to tool calls. These are necessary but insufficient.

Detection operates on heuristics. It produces false positives. It can be bypassed — Trail of Bits demonstrated in June 2026 that every AI agent skill scanner they tested could be evaded. A detector that can be bypassed is a speed bump, not a guarantee.

Verification is different. Verification uses cryptography to produce evidence that cannot be forged by the agent itself.

What a signed receipt looks like

Instead of a self-attested log entry, imagine each tool call produces a receipt like this:

{
  "receipt_version": "1.0",
  "action_id": "act_8f3a2c1d",
  "action_type": "bash",
  "caller_identity": "agent:claude-code-v2.1.246",
  "input_hash": "sha256:b94d27b9...",
  "output_hash": "sha256:a3f5c8e1...",
  "timestamp": "2026-08-25T14:32:01.234Z",
  "prev_receipt_hash": "sha256:7c2e1f9a...",
  "policy_digest": "sha256:d4a7b2c0...",
  "signature": "Ed25519:f8a3c2..."
}

Key properties:

• Ed25519 signature (RFC 8032) over RFC 8785 canonical JSON — the signing key is held outside the agent process, in a sidecar or hardware module, so a compromised agent cannot forge signatures.
• Input/output hashes bind the receipt to exactly what was executed and what came back — you can't alter the command or the result after the fact.
• Previous receipt hash creates a hash chain — deleting or reordering a receipt breaks the chain and is immediately detectable.
• Policy digest binds the action to the exact policy version that authorized it — when Anthropic ships v2.1.247 with new permission rules, you know which policy each action was evaluated against.
• Zero false positives — a receipt either verifies against the known public key and chain, or it doesn't. There's no "anomaly score" or heuristic threshold.

The verifier that checks these receipts is pure Python, zero dependencies, 157 tests, and verifies a receipt end-to-end at P50 ~27 microseconds. It runs on every tool call without meaningful latency.

Why this matters after the patch

When you update to Claude Code v2.1.246 and the credential scoping bug is fixed, you still don't have an answer to:

1. Did every tool call between discovering the bug and patching it use credentials correctly? The agent's log says yes. Who signs that log?
2. After patching, how do you prove to an auditor that no unauthorized action occurred? You produce self-attested logs from the same runtime that had the bug.
3. When the next CVE drops (and it will — there have been 6+ in August alone), how do you establish a non-repudiable record of what happened before, during, and after?

Signed receipts don't prevent vulnerabilities. They provide something the current architecture fundamentally lacks: evidence independent of the system being audited.

Try it

The conformance test suite is MIT-licensed and includes 10 test vectors with a ~15-line independent verifier, so you can validate the receipt format without trusting any implementation:

→ github.com/DSHCorrectover/ccs-conformance-vectors

The Python verifier is on PyPI:

pip install ccs-verifier

The Node.js runtime:

npm install correctover

The policy-enforcing proxy that holds the signing key outside the agent process is a separate commercial offering. The receipt format, the verifier, and the conformance vectors are open and will remain open — because an evidence format you can't independently verify isn't evidence.

---

Correctover builds runtime verification for agent systems. The open-source CCS verifier produces Ed25519-signed receipts over JCS canonical JSON for every agent tool call, creating tamper-evident audit chains that don't rely on agent self-attestation.