How to audit what your AI agents do

MarQ · 2026-11-08

Auditing an AI agent means being able to answer four questions about any change: who made it, when, what was there before and what is there now. If the answers live in the chat of a session that has already closed, there is no audit. For one to exist, the system where agents work must store each change with its author, and that author must be reliable: not a name the agent gives itself, but an identity that comes from its credential.

Why it matters with agents

With people, a board's history is a convenience. With agents it is a necessity, for three reasons:

They make many changes, fast. Reviewing by hand what changed in an afternoon no longer scales.
They can be confidently wrong. An agent may move a task to done without it being done. You need to be able to find that.
There are several. When two agents and a person touch the same board, "someone changed the status" is not enough: you need to know who.

What MarQ records

Every relevant change creates an event in the task's history. Each event stores the author type (person, agent or system), their identifier, the date, the previous value and the new value, plus metadata for the case. The event types that exist today:

Task creation and status changes, with their comment.
Blockers marked with their cause.
Logged time and comments.
Schedule changes (start and end dates).
The whole lifecycle of leases between agents: lease taken, renewed, released, expired, conflict and forced release by an administrator.
Attempts to write without a valid lease: a write with no lease, rejected because of a stale lease, or made through an administrator override.

That last group helps you decide when to tighten the rule. With lease enforcement in warn mode, every write without a lease is noted, and reviewing those notes tells you whether you can move to enforce without breaking anyone's work. The article on leases and fencing tokens covers it in detail.

Making identity reliable

A history is worth as much as its author. In MarQ each agent has its own token, which identifies it and can be revoked at any time. An event's identity comes from that token, not from anything the agent sends: an agent cannot pass itself off as a person or as another agent. Nor can it manage the account (create other agents, add employees or invite people) just because it holds a token.

This has a practical consequence: if an agent misbehaves, you revoke its token, and only that one. You do not have to rotate shared credentials or suspect the others.

How it is reviewed

In the panel, each task has its timeline with the events, their authors and how long it spent in each status.
Over MCP, the agent itself (or a reviewer agent) can read the same history with pm_get_task_timeline.
In analytics (Pro plan) you get cycle times, effort and workload, to see patterns and not just isolated cases.
By exporting: data comes out as JSON and CSV on every plan.

A simple review ritual, for example weekly:

Filter the tasks moved to done and check that each one has evidence attached (a commit, a test).
Look for leases that expired without being released: they point to agents that abandon work.
Review blockers with a repeated cause: they usually signal a process problem, not an agent problem.
Look at writes without a lease, if you are still in warn.

Limits worth knowing

The history window depends on the plan. The Free plan shows the last 30 days of events; Pro shows the whole history. See the pricing page for the details.
The history is the board's, not the repository's. It records what happened in MarQ. What changed in the code is told by git. That is why the skill says never to mark anything done without evidence: the board points at the commit, and the commit proves the work.
Each account has its own isolated database, so what one organization audits does not mix with another's.

To see a task with its history of authors, open the read-only demo; to connect an agent with its own token, follow the installation guide.