case studies

Exporting One AI Agent Session for a Reviewer to Check

A reviewer wants to see what one agent did during a session. They shouldn’t get the whole database, which holds every agent’s history and the encrypted credentials. They also shouldn’t have to take a hand-made summary on trust. What they need is that agent’s slice of the log, in a file they can check on their own laptop.

This run used the same session as the publish replay case study, recorded on Tokening 0.1.4 with a stand-in CMS on the same machine. The agent in question is editor-bot. It had a two-use grant to fix a typo in the title of post 3, and a second grant for post 4 that the operator revoked before it was used. All commands and output are in the case study folder, including the exported file itself.

The export

$ tokening flight export --db tokening.db --agent editor-bot --since 2026-10-31T10:40:11Z --until 2026-10-31T10:40:14Z --output editor-bot.jsonl
Exported 10 entries.

Ten lines of JSON, entries 9 to 18 of a 20-entry log. The other ten belong to other agents, or to a call with a token Tokening never issued, which is recorded with no agent at all.

What the reviewer runs

A plain check fails, and it should:

$ tokening flight verify --file editor-bot.jsonl
Broken at entry 9: the log starts at entry 9: entries 1 to 8 are missing.
No entry before it verifies.

The file was filtered, so entries are missing on purpose. --partial accepts that, checks every entry’s own hash, and checks links wherever the numbers are consecutive:

$ tokening flight verify --file editor-bot.jsonl --partial
Intact as a partial export: 10 entries from 9 to 18, every hash checked, links checked where entries are consecutive.
Head: 18:ae190c667b099e61f6f21a2746ae9347332ebb3c70c87a35b09ab745005e2f66

Then the readable version:

$ tokening flight replay --file editor-bot.jsonl
#9  2026-10-31T10:40:12.698Z  grant     g_bc3cbaec237464d10e22cbe6b3615f88 issued to editor-bot by ops-maria: cms.edit-post-text on update_post, 2 uses, expires 2026-10-31T10:55:12.698Z, bound id, reason "fix typo in post 3 title"
#10  2026-10-31T10:40:12.705Z  request   g_bc3cbaec237464d10e22cbe6b3615f88 editor-bot asked for update_post on cms with arguments id, title (digest 87053af89cbe)
#11  2026-10-31T10:40:12.705Z  decision  g_bc3cbaec237464d10e22cbe6b3615f88 allowed: Call fits this grant. One use was consumed before forwarding. 1 use left.
#12  2026-10-31T10:40:12.716Z  result    g_bc3cbaec237464d10e22cbe6b3615f88 upstream answered HTTP 200 in 7 ms
#13  2026-10-31T10:40:12.719Z  request   g_bc3cbaec237464d10e22cbe6b3615f88 editor-bot asked for update_post on cms with arguments id, status, title (digest ee3b7a6acd18)
#14  2026-10-31T10:40:12.719Z  decision  g_bc3cbaec237464d10e22cbe6b3615f88 refused (arg_not_allowed): Grant does not allow argument status. Allowed: content, id, title. 1 use left.
#15  2026-10-31T10:40:12.732Z  grant     g_029a10b612b38b01be751fa94adccd27 issued to editor-bot by ops-maria: cms.edit-post-text on update_post, 1 use, expires 2026-10-31T10:55:12.732Z, bound id, reason "update pricing title"
#16  2026-10-31T10:40:12.741Z  grant     g_029a10b612b38b01be751fa94adccd27 revoked by ops-maria
#17  2026-10-31T10:40:12.747Z  request   g_029a10b612b38b01be751fa94adccd27 editor-bot asked for update_post on cms with arguments id, title (digest f7c35956a70d)
#18  2026-10-31T10:40:12.747Z  decision  g_029a10b612b38b01be751fa94adccd27 refused (grant_revoked): Grant g_029a10b612b38b01be751fa94adccd27 was revoked at 2026-10-31T10:40:12.741Z. 1 use left.
Every entry here checks out, but 8 of entries 1 to 18 are missing from this file: it is a filtered export, or entries were removed. Verify the whole log with tokening flight verify --db.

The story reads straight off it. The title fix went through. Then the agent tried to set status in the same kind of call, which would have published the post, and was refused because the grant only covers title and content. It still had a use left and didn’t get to spend it on that. The post 4 grant was revoked 22 milliseconds after it was issued, and when the agent tried it anyway, the refusal says when.

The last line is honest about its limits. From a file alone, replay can’t tell a filter from a removal, so it counts what’s missing and points at the full check. If the reviewer needs that, the operator runs tokening flight verify --db and hands over the head along with the file.

If the file is changed on the way

We edited one line of the export before checking it again: entry 14’s refused turned into allowed.

$ tokening flight verify --file editor-bot-edited.jsonl --partial
Broken at entry 14: entry 14 does not match its own hash: its contents were changed after it was written.
Entries 9 to 13 verify. Last good head: 13:088136e77439b509938667a6f5c2254f90ee9212901b0c7d6bf1b0edadf5bc3f

Every entry carries its own hash, so a partial export can’t be edited quietly either.

What the file doesn’t contain

The full export from this session was searched for the grant secrets, the made-up token, the upstream key held in the vault, and the values the agents sent, such as the new title “Release notes” and the status value “published”. None of them were in it. Request entries list argument names only: id, id, title and id, status, title.

That makes the file safe to hand to someone who may know which posts the agent touched. It isn’t anonymous, though. The digests are plain SHA-256, so a short value like a post id can be found by trying candidates. Share an export with the same care as the audit log itself.

The recipes post has the export and check as copyable commands, and the flight recorder post covers the format.