CONTROLLED AGENCY | Issue 17: Can You Prove Your Log Wasn’t Edited?
Everyone’s arguing about detection. Almost nobody’s arguing about evidence.
A founder said something to me recently that stuck. We were talking about his platform’s guardrails, the usual pitch, and partway through he stopped and said his own documentation overstates what the product actually guarantees. Then he told me he’d gone and checked the database schema himself before saying so, he wanted to be sure before he admitted it. Nobody made him say that. He volunteered a gap in his own product to someone who writes about this stuff publicly.
That’s rarer than good architecture. And once I noticed it, I started checking for the same gap everywhere else, and I kept finding it.
What I actually checked
Over the past few weeks, I looked closely at how several AI-agent platforms handle logging, not detection: logging- the record of what an agent actually did. Every one of them can tell you an agent ran. None of them, when I pushed on it, could tell me how I’d know if that record had been quietly edited after the fact. Not “would anyone want to edit it.” Whether the system makes editing it detectable.
This isn’t a knock on any one of them specifically. It’s the gap an entire category has converged on leaving open, independently, without ever coordinating on it. And it turns out there’s a real, precise reason the industry keeps landing here.
The distinction nobody’s making
Most systems that call themselves “audit trails” are logs. A log is a record something happened. An audit trail, in the sense regulators and security researchers actually mean it, is a record that something happened and that the record itself can’t have been altered without that alteration being detectable. Those are different properties, and conflating them is the specific mistake most of the industry is making right now.
A recent technical breakdown put it plainly: a log stored in a writable database isn’t tamper-evident, no matter who has access to it, because tamper-evidence requires an architectural mechanism- cryptographic chaining, write-once storage, or something equivalent- that makes modification detectable. Without that mechanism, “we have logs” and “we have a trustworthy record” are not the same claim, whatever the marketing copy says. DeepInspect
The industry standard patterns for closing this gap, write-once storage and cryptographic signing for tamper detection- come directly out of OWASP’s own research into AI agent risk. This isn’t a fringe concern invented by security researchers looking for something to write about. A properly tamper-evident log uses cryptographic signatures that seal each entry at the instant it’s created, so any later modification, by an administrator, an infrastructure operator, or the agent itself, becomes detectable. The technique isn’t exotic. It’s decades old in computer science; researchers were formalizing efficient data structures for tamper-evident logging back in 2009. What’s new is that AI agents have made the gap urgent, because now the thing the log describes can act on its own, and the log is often the only record of what it actually did. arxivAcipta
Why this is a regulatory problem, not just a technical one
I’d assumed, going in, that this was mostly an engineering nicety. It isn’t. Multiple regulatory frameworks are converging on exactly this requirement, from different directions, for different reasons. The EU AI Act’s logging obligations, GDPR’s accountability requirements under Article 32, and the human-oversight provisions under Article 14 all effectively demand that organizations be able to prove, not just assert, what an AI system did. In financial services, Fannie Mae’s 2026 guidance explicitly requires audit trails that permit reconstruction of AI-assisted decisions, and states that lender-controlled logs the lender can modify don’t satisfy that expectation. HIPAA’s audit-control requirements, DORA’s incident-reconstruction rules, and NIST’s AI Risk Management Framework are all converging on the same underlying property from completely different regulatory traditions, records an outside party can actually rely on, not records the operator merely says are accurate. arxiv
That convergence matters more than any single rule. When banking regulators, healthcare regulators, EU AI regulators, and financial-stability regulators all independently arrive at “the operator’s word isn’t enough,” that’s not bureaucratic overreach. That’s several different institutions noticing the same structural problem from several different angles.
The part that’s actually hard, and why this is being solved independently, in the same shape, by more than one person who’s never talked to the other
Here’s the honest complication, because I don’t want to make this sound easier than it is. The audit entry has to be created at the moment of access, not reconstructed afterward. If it doesn’t exist at the time the action happened, there’s no forensic technique that recovers it later. That’s a real architectural constraint, not a policy choice you can retrofit. It means tamper-evidence has to be designed in from the start of an agent’s action pipeline, which is exactly why so many platforms, built fast and iterated on faster, end up with rich telemetry and no real evidentiary integrity. The two look similar from a dashboard. They are not the same thing. DeepInspect
There’s already at least one open-source project, halo-record, that’s built almost exactly this: hash-chained records plus an external witness checkpoint specifically to catch a full rewrite, not just an in-place edit. I’ve built the same two-part shape independently, in Vestigia. Neither of us copied the other. That’s either a coincidence, or it means the architecture isn’t exotic, it’s just genuinely hard to get to unless you’ve been forced to think carefully about what “tamper-evident” actually has to mean.
There’s a growing, if still small, recognition of this. One open-source project I came across recently frames the whole problem in a single sentence I keep coming back to: the goal is an audit trail the vendor runs but cannot edit. That’s the correct bar. Not “the vendor promises not to edit it.” Cannot, structurally, edit it without the tampering being visible to anyone holding a checkpoint of the record. A handful of frameworks are starting to name this explicitly as a control category in their own right, rather than folding it into generic “logging” requirements, which is a sign the field is starting to take the distinction seriously, even if adoption is still early. Vouched
Where I’ve spent my own time on this
I’ll be direct about my own stake here, since I think pretending otherwise would be dishonest given everything else in this piece. The tamper-evident, hash-chained audit layer in Vestigia, part of the open tooling I’ve built and published, exists specifically to close this gap: an append-only record where any alteration after the fact is cryptographically detectable, not merely policy-forbidden. I’m not going to pretend I arrived at this problem from nowhere, or that I don’t have a stake in the answer. I raise it because it’s the honest thing to disclose, not because this piece is trying to sell it to you.
The reframe I think this deserves
There’s a sentence I heard in a different conversation this month that I think belongs right next to this problem: “my AI agent is autonomous, but I can pull the plug anytime.” That’s a claim about capability. It is a completely different sentence from “a human happened to be paying close enough attention to notice in time to pull it.” Most of the industry is still quietly treating those two sentences as interchangeable, and the gap between them is exactly the gap tamper-evident evidence is supposed to close. A kill switch you can reach is a mechanism. A kill switch someone remembered to reach for is luck wearing a mechanism’s clothes.
The same substitution is happening with logs. “We have an audit trail” and “we have a record that survives someone wanting it to say something different” are two different claims, and right now, across a whole category of products, the industry is quietly treating them as one.
Where I might be wrong
I don’t think tamper-evidence alone solves the deeper trust problem, and I want to be honest about that rather than oversell it. A cryptographically sealed record proves the log wasn’t altered after creation. It doesn’t prove the agent’s reasoning inside that log was honest, or that the action logged was actually the right action to take. Tamper-evidence answers “can I trust this record of what happened,” not “should I have trusted what happened.” Those are both real problems. I’ve only been writing about the first one here, and I’d be overstating my case to imply it’s the whole picture.
Where this leaves us
Everyone’s still arguing about detection, whether guardrails catch the bad prompt, whether monitoring is stateful, whether the agent gets flagged in time. Those are real arguments and I’ve made a version of most of them myself. But underneath all of them sits a quieter, more basic question almost nobody’s answering yet: when something does go wrong, and you go looking for the record of what happened, can you actually prove it’s telling you the truth?
Right now, for most of the industry, the honest answer is no. Not because anyone’s lying. Because almost nobody built the record to survive being asked.
I’d like to know where this breaks in practice. If you’ve tried to build or evaluate tamper-evident logging for an AI system, what turned out to be harder than the architecture diagrams make it look? And separately: is there a category of harm here that tamper-evidence genuinely can’t touch, no matter how well it’s implemented?
Miracle Owolabi is an AI security researcher and offensive security engineer researching how AI agents fail, and increasingly, whether the record of that failure can be trusted at all. He publishes Controlled Agency.
Sources referenced in this piece:
Crosby, S. A., & Wallach, D. S. (2009). Efficient Data Structures for Tamper-evident Logging. USENIX Security Symposium.
“Tamper-Evident Audit Trails for AI Agents: What SIEM Integration Actually Requires,” Kiteworks (2026).
“Tamper-Evident Audit Logs for AI: What Cryptographic Integrity Brings to Compliance Records,” DeepInspect (2026).
“Audit Trails for AI Agents: Complete, Tamper-Proof Logging,” Blck Alpaca (2026).
“Building a Secure AI Agent Audit Trail,” Vouched/Identiclaw (2026).
halo-record (open-source project), GitHub.