I use Claude Code as my primary development tool. It reads files, writes files, runs commands. It's good at its job. But here's the thing: by default, there is zero record of what it actually did to your filesystem.

Git blame shows the final state. It doesn't show the sequence. It doesn't show which files were read before which were written. It doesn't show the three files that were modified and then reverted during the same session. It doesn't show the bash command that ran between edits.

I wanted to see the full picture. So I pointed Signal Provenance at my own working directory and let it run for three weeks.

What the chain recorded

2,365 witness entries across 21 sessions. Every file read, every file write, every tool call. Each entry hash-chained to the previous one with SHA-256. Median overhead per operation: 128 milliseconds.

The ledger is a SQLite database. Each row contains: timestamp, event type, file path, content hash, previous chain hash, and a JSON payload with the operation details. The chain is append-only. You can verify the entire history by rehashing from the first entry forward. If any row was modified or deleted, every subsequent hash breaks.

What I found

The interesting part wasn't the normal operations. It was the gaps.

Layer 0 (raw Claude Code, no hooks): No provenance at all. The agent says "I read the file before editing it." There is no way to verify that claim. Foundation Value III, provenance over assertion, is entirely absent.

Layer 1 (Foundation Gate hooks): I wrote a 532-line Python hook that fires on every tool call. It enforces read-before-write. It scans for PII before file writes. It blocks destructive bash patterns (rm -rf, DROP TABLE, git push --force). And it witnesses every operation to the hash chain.

Result: 23 PII warnings caught in 19 hours. 4 destructive commands blocked. Every operation traceable.

Layer 2 (hooks + MCP domain tools): The agent gets structured access to operational data through MCP tools instead of raw SQL queries. Every tool call is witnessed. The agent cannot bypass the provenance layer because it accesses data through the tools, not directly.

The compliance angle

The EU AI Act Article 12 requires automatic event logging for high-risk AI systems. Article 15 requires cybersecurity resilience. Article 73 requires forensic evidence preservation. None of them explicitly mandate cryptographic log integrity.

But if your logs can be silently modified after the fact, they are not evidence. They are assertions. The combination of Articles 12, 15, and 73 makes hash-chained, tamper-evident logs the economically rational implementation. Not because the regulation says "use SHA-256." Because the regulation says "prove it happened," and a mutable log cannot prove anything.

What this means for AI agents

Every company deploying AI agents will eventually need to answer the question: what did the agent do? Not what did the agent say it did. What actually happened to the files, the database, the API calls.

Git is insufficient. Application logs are mutable. The gap is a tamper-evident, append-only chain that witnesses every operation as it occurs.

That's what Signal Provenance does. 49 Rust tests. 7,012 entries in production. 128ms median overhead. Running on my own infrastructure, monitoring my own AI agent, generating the data for this post.

The full case study with Layer 0-4 progression and measured performance data is available for compliance teams evaluating this approach. Get in touch.