An audit trail for AI agents: knowing who changed what

An audit trail for AI agents is a record, kept by the tool and not by the agent, of every change an agent made, under the agent’s own name. It needs three properties to be worth having: an agent’s changes must be distinguishable from a person’s, including the person it works for; the record must be written by the system that was changed; and it must remain after the agent’s access is revoked. On fenbs every change is recorded with who made it, and an assistant’s changes appear by name, so “who moved this to Completed?” always has an answer.

Why this is suddenly a real question

For years the answer to “who changed this?” was a colleague’s name, and if the tool did not record it you could ask around. AI assistants change that in two ways. They make far more changes, often while you are doing something else or asleep. And they usually work through somebody’s account, so a tool that only knows about accounts will tell you that you made a change at three in the morning that you have never seen before.

That is the core failure: an agent that borrows your identity leaves a trail that points at you. You cannot separate your work from its work, you cannot review what it did as a set, and when something goes wrong you cannot show which of you did it.

What a good trail records

• Who, precisely. Not just the account, but whether it was the person or an assistant acting for them, and which assistant.
• What changed. The task, and what was done to it: created, edited, moved from one lane to another, commented on.
• When.
• In words a person can read. A trail that needs a developer to interpret it will not be read by the person who most needs it.

And it has one property that is easy to overlook: the agent does not write it. An assistant’s own summary of what it did is useful, but it is a claim. The trail is the board’s account of what actually happened to the board.

How fenbs does it

Every assistant has a name

An assistant connects with a token that a person issues under Settings, in Connect an AI assistant. You name it for what it is: “Claude”, “Cursor”, “the nightly triage script”. One token per assistant means one name per assistant in the record.

Every change is signed

Every change on the board is recorded with who made it, and each task shows its own trail on its page. An assistant’s changes are recorded by name together with the person it acts for, in the form “Claude via” that person, so an assistant’s changes can be told apart from a person’s. The how it works page puts it in one line: nothing happens quietly.

The assistant also says what it did

Separately from the system’s record, an assistant working a task writes down, in a few plain lines on the card, how it actually implemented or fixed it. The two together are what you want: the board’s account of what changed, and the assistant’s account of why. Months later the thinking behind a decision is still there, for you and for whichever assistant picks the work up next.

You      wrote it down
Claude   fixed it
Priya    had a look

Revoking an agent without losing the record

Sooner or later you will take an assistant’s access away. You change tools, a laptop is lost, a contractor leaves, or an assistant did something you did not like. On fenbs, revoking a token takes one click. It stops working at once, and you stay signed in: same account, one fewer key.

Everything the assistant did stays in History under its name. Revoking access should not erase the record of what happened, and the day you revoke is usually the day you most want to read it.

There is a softer option as well. A token’s scopes are read, write and comment, and a token can never do more than the person who issued it. Narrow your own role on a board and every token you issued narrows with it. If you want an assistant to keep reading but stop changing things, issue it a read-only token and revoke the wider one.

Refusals are part of the trail too

Accountability is not only about what an agent did. It is also about what it tried to do and was stopped from doing, and whether it told you. On fenbs a refusal names the permission that was missing and the role the assistant holds, as a sentence the assistant can repeat to you.

Who needs this most

The person who runs the work but does not read the code

If you cannot read a diff, the record of what your assistants actually did is the only view you have. With History you can answer “what got completed this week?” without asking a single person.

The developer working with several assistants

When Claude and Cursor both work the same board, the trail tells you which one touched a task, so you know where to look when a fix does not hold.

The client

A client who can open the board and see who did what, and when, has less reason to ask for a status call. Give them a role that reads and comments, and the trail does the reporting.

A short routine

1. Issue one token per assistant and name each for what it is. Never share a token between two tools.
2. Give each the smallest scopes that do its job.
3. Once a week, read History. Look at what each assistant did, not only at what is in Completed.
4. When you stop using an assistant, revoke its token that day. Its record stays.
5. When an assistant reports a refusal, treat it as the system working. Widen the role if the request was reasonable, and leave it if not.

What fenbs does not claim

The trail covers the board: tasks, lanes, comments and the people and assistants who touched them. It does not record what an assistant did elsewhere, in your code or your other systems; those need their own records, such as your version control history. Quoting the task ref in a commit message ties the two together, and a fenbs ref is never reused, so the link stays true.

The whole trail of who changed what is part of the Teams plan, and AI assistants cost nothing extra on any plan; see pricing. To connect your first assistant, follow the connection guide.