Post cover image

July 17, 2026

Your AI Agent Did 400 Things Last Night. Can You Prove Any of Them?

Editable logs are anecdotes, not evidence. Here’s what a receipt for agent actions looks like — and how to verify one without trusting…

By sandeep kumar

3 min read

Editable logs are anecdotes, not evidence. Here's what a receipt for agent actions looks like — and how to verify one without trusting anyone. Including me.

The promise of agentic AI is that it works while you don't. An agent with shell access, file access, and a stack of MCP tools will happily do hundreds of things in a single session: run commands, edit files, call APIs, install dependencies, talk to your internal services.

The morning after, you have a question that sounds simple and isn't: what exactly happened here?

For most setups today, the honest answer is "whatever the log file says." That should worry you more than it does.

A log you can edit is an anecdote

Ordinary agent logs are text files, or rows in a database owned by the same process that writes them. Anyone with access to the machine can rewrite them after the fact. Increasingly, so can the agent — because the agent holds the same shell that writes the log.

There are three quiet failure modes, and standard logging makes all three invisible:

  • Modify a record — change what an action looked like after it ran.
  • Delete a record — remove an action from history entirely.
  • Truncate the tail — drop the most recent, usually most interesting, events.

Logging is not the same thing as evidence. Evidence has to survive one question: how do I know nobody changed this?

What a receipt looks like

kriya's answer is: don't log agent actions — receipt them. Every governed action produces one record containing:

  • What was done, with the arguments.
  • The actor — which agent, acting for which human operator. That's the accountability link.
  • Outcome and timestamp — and blocked attempts are receipts too. A policy denial is part of the story, not something that vanishes.
  • A hash chain — each receipt commits to the previous one, so deleting or reordering records breaks the chain visibly.
  • An Ed25519 signature over all of the above, made by a host-held key the agent process cannot read.

The last two are the point. The signature means a record can't be altered after signing without failing verification. The chain means the log can't be quietly thinned. And the key separation means the author is not the actor: the agent does the acting; the host does the attesting.

None

Don't trust me — verify

Here's the uncomfortable question for any audit product: why should anyone believe the vendor? The only good answer is: you don't have to.

kriya ships a free standalone verifier, and the sample receipts are public. This takes about sixty seconds:

curl -fsSLO https://github.com/sandeepshekhar26/kriya/releases/download/audit-v0.1.0/kriya-audit-0.1.0-macos-universal.zip
unzip -o kriya-audit-0.1.0-macos-universal.zip
curl -fsSLO https://github.com/sandeepshekhar26/kriya/releases/download/audit-v0.1.0/sample-receipts.jsonl
./kriya-audit sample-receipts.jsonl
# … 20 signature(s) verified — OK

Now open the file, flip one byte, and run the verifier again. It fails, and tells you which record broke.

The Console makes a game of it — an "attack it" panel with three buttons: forge a field, flip a byte, hide the newest record. The offline re-verification catches all three, every time, with no network involved.

None

Tamper-evidence, not tamper-proofing

Let me be precise about the guarantee, because precision is the product.

What this gives you is tamper-evidence: any alteration or deletion of retained records is detectable by an independent verifier, offline. It is not tamper-proofing: nothing stops a sufficiently privileged attacker from acting in the first place, the guarantee starts at the host's signing key, and a fully compromised host is out of scope. Our docs say this in plain language, on purpose.

A tool whose whole pitch is "you can check" should come with limits you can check too. Security products earn trust at their boundaries, not their headlines.

The other half: governance before the act

Receipts record what happened. Half the value is in what doesn't happen.

Policy rules — allow, require-approval, deny — are evaluated before an action executes. Risky actions pause and land in a human approval queue; the approval, who allowed it and why, becomes part of the signed record. Budgets and rate caps bound what an agent can spend or do.

If you use Claude Code, wiring this up is one paste into settings.json: a hooks adapter that governs and receipts every native tool call — Bash, Edit, Write — and every MCP call, before it runs.

Try it

The runtime is open source (MIT). The macOS Console is free. The verifier is free. Nothing leaves your machine — no account, no cloud, no telemetry.

It's built for anyone running agents where "trust me" isn't an acceptable answer: regulated environments, air-gapped machines, or just engineers who think evidence should be checkable.

Start here: kriyanative.com/docs/claude-code

And if you can forge a receipt that passes the verifier — I genuinely want to hear from you.

I'm Sandy, building kriya solo. The longer version of this argument lives at kriyanative.com/blog/agents-act-logs-lie.