Help Net Security covered a new open-source tool this week that writes tamper-evident audit logs for AI agents. It stores recorded agent activity i...
For further actions, you may consider blocking this person and/or reporting abuse
The two questions are the right frame, and I'd push on the "who holds the key" one a bit further: a single external witness (or a single operator-held key, like Pipelock's) still concentrates trust in one party — it just moves the trust from "the agent didn't lie" to "the witness didn't collude or get compromised." The stronger version is witness quorum: multiple independent parties checkpointing, with the guarantee only holding when enough of them agree, so no single compromised or colluding party can retroactively rewrite history. Even that isn't the finish line — quorum alone doesn't stop two isolated verifiers from each being shown a different but internally-consistent fork, unless the witnesses actually cross-check against each other's views (gossip / consistency proofs), not just against their own last-seen state. "Tamper-evident" keeps eating "unforgeable" the same way "detected" keeps eating "prevented" — appreciate you naming the gap plainly instead of selling past it.
Yeah. A single witness just moves the trust instead of removing it, and quorum only helps if the witnesses cross-check each other. Same wall certificate transparency hit with SCT gossip, still not solved there.
I haven't shipped even the single witness yet, so I won't pretend the quorum version is real. It's the direction. The levels problem you're describing is why I wrote up Agent Evidence Levels, a spec that names what each tier of evidence proves, since tamper-evident keeps getting sold as unforgeable.
Respect for the honesty about where the single witness actually is. On the SCT gossip parallel: does Agent Evidence Levels put any bound on time-to-detection at each tier, or is it currently in the same place as CT — assumed eventually caught, without a hard SLA on how eventually? Feels like that's the natural next axis once the tiers themselves are named: not just what a tier proves, but how long a forged entry can survive undetected at that tier before someone's obligated to notice.
No bound today. AEL grades what a tier proves, not how fast a forgery at that tier has to get caught, so right now it's in the same spot as CT: assumed eventually, no clock on eventually. You're right that it's the natural next axis.
A real bound needs two things the spec doesn't name yet: checkpoint cadence and someone actually obligated to check. Signed checkpoints give you the first half cheap. The second half is the hard part, same as it was for CT gossip. I'm adding it as an open question on the spec, and if you want to file the issue yourself I'd rather have your wording than mine.
github.com/luckyPipewrench/agent-e...
CT's actual fix for "someone obligated to check" was never really social — it's structural: browsers require an SCT to come from a log that's independently monitored, and require multiple logs, so redundancy substitutes for anyone being obligated. A consumer that only checks one witness gets zero benefit from the others existing. Might be worth building AEL the same way: instead of naming a responsible checking party, require that a tier claim gets independently cross-checked against N witness endpoints before it's trusted, so the incentive is structural rather than depending on someone volunteering to gossip. Doesn't solve the bound-on-cadence question, but it means the answer doesn't rest on finding a volunteer.
Better read of CT than mine, and it changes what I file.
One split though. Multiple logs kill the case where one log is the only witness and can lie. They don't catch a split view, where a log shows one tree to you and another to everyone else. That still needs someone comparing signed tree heads, which is why SCT auditing took years to land in Chrome.
The consumer-side version of your point does hold, and it's writable: a claim is worth the number of independent logs the relying party checked inclusion in itself, and one anchor is worth one anchor no matter how many exist. AEL-3 names a single log today, so that's a real change.
What CT had was Chrome. Nobody's in that seat here, so I can make the weak claim illegal and let relying parties set N, and that's it. If you see how to get the incentive without a browser-sized enforcer, I want it.
Filing it either way. Yours if you want your wording, otherwise I'll write it and mention you.
The recorder-inside-the-process problem is the one that keeps coming back in agent work. I run agents with persistent filesystem access between sessions, and the first thing I learned is that an agent that can write its own logs can also not write them. My workaround has been crude but functional: every agent writes to a directory it can append to but not delete from, and a separate process checksums the directory on a fixed interval that the agent does not control. Not tamper-proof by any real standard, but it catches the gap between "the agent reported this" and "something outside the agent saw this."
Your point about unsigned chains being a notebook with numbered pages landed well. The numbered-pages metaphor gets at why people over-trust these systems. A notebook is useful, but nobody enters a notebook into evidence without asking who wrote in it. The same question should apply to agent logs, and it usually does not.
Your workaround is more right than you're giving it credit for. An append-only directory the agent can't delete from, checksummed on an interval by a process the agent doesn't control, is a witness. That's the same shape the fancy tools are selling, you just built it out of directory permissions. The interval is your exposure window: anything written and rewritten between two checksum passes looks clean, and the checksummer still can't see what the agent never wrote down. But you've already crossed the line most setups never cross, which is getting the observer outside the thing being observed.
And yeah, that's exactly why I keep coming back to the notebook framing. The question "who wrote in it" has a boring, well-understood answer in every other evidence context. Agent logs just haven't been asked it yet.
The key distinction here is integrity vs completeness. A signed, tamper-evident receipt can strongly prove that a recorded event wasn’t altered, but it says nothing about events that never reached the recorder. For agent systems, I’d treat those as separate guarantees in the architecture: capture completeness enforced at the execution boundary, then cryptographic integrity on the captured stream. Otherwise it’s very easy to build an audit system that produces excellent evidence for an incomplete history.
Agreed, and that's the split I built around. Capture completeness is the containment boundary's job: the agent runs behind a kernel-enforced egress boundary it doesn't operate, so traffic can't route around the recorder. Integrity is the chain's job. The verifier reports them separately on purpose, containment attested or UNKNOWN printed right next to the chain verdict, so a valid chain never gets to imply complete capture.
Your last sentence is the whole failure mode. Great evidence for an incomplete history is worse than no evidence, because it launders the gaps.