VIVUU

Guide · agent governance

AI agent audit trails: every action attributable

When agents act on production systems, 'what happened?' must have an exact answer. The audit trail is where autonomy earns trust — human, agent, or policy: who did what, to what, with what result.

Three kinds of actor, one record

An agent system has three sources of consequential action: the human (approved, denied, delegated), the agent (executed, verified, rolled back), and the policy engine (blocked, held for approval). A trail that only logs the agent misses the half of the story that assigns responsibility. Every entry names its actor:

00:27 · you ··················· Approved: Capture 3 stuck renewals ($5,520)
00:27 · finance (co-approver) · Co-signed: Capture 3 stuck renewals
00:28 · FounderAgent ·········· Executed + verified approved action · ok
05:06 · policy ················ Held outbound email batch for approval
04:06 · you ··················· Denied: discount >20% without finance · denied

Read top to bottom, that log answers the questions a postmortem or a controller actually asks — without opening a single transcript.

Evidence belongs in the record

"The tests passed" is a claim; a checksummed test-run artifact is a record. Consequential entries should point at the evidence that justified them — the diff, the test output, the staging log, the metric trend — and that evidence should become immutable once the approval consumes it. Otherwise the proof can quietly change after the yes.

Results, including the ugly ones

Four result states cover reality: ok, denied, failed, and rolled back. The last two are where trails earn their keep. "Rolled back canary after failed verify" is a sentence that should exist in your log — it proves the execute-then-verify loop is real, and it timestamps the moment automation protected you from itself.

How VIVUU models it

The terminal's History screen is exactly this record: reverse chronological, actor-attributed, result-toned, append-only, with approvals and denials (reasons included) interleaved with agent execution and policy holds. It fills itself — approving a deploy or delegating a goal writes entries as a side effect, because a trail maintained by hand is a trail with gaps.

FAQ

What should an AI agent audit log contain?
Five fields per entry, minimum: who acted (a specific human, a specific agent, or the policy engine itself), what they did in plain words, on what target (repo, environment, account, record), the result (ok, denied, failed, rolled back), and a timestamp. Consequential entries should also reference the evidence that justified the action — ideally by checksum, so the proof can't drift after the fact.
Why does an agent audit trail need to be append-only?
Because the trail is only worth anything when something went wrong — and that is exactly when there is pressure to tidy it. Append-only (no edits, no deletes, corrections as new entries) keeps the record credible for postmortems, compliance reviews, and the plain question of what did the agent actually do last night.
Should policy denials appear in the audit trail?
Yes — denials are some of the most valuable entries. 'Policy denied secret rotation attempt' tells you the guardrails engaged, which attempted actions cluster where, and whether an agent keeps walking into the same wall. A trail that only records successes is a highlight reel, not an audit.
How do human approvals show up in a good audit trail?
As their own attributable entries, separate from the execution. A dual-approval money movement should read as three acts: the first human approved (timestamped), the co-signer approved, then the agent executed and verified. If the approval and the execution are one blurred entry, you can't answer who authorized what.

see the whole flow, live

Everything on this page — the queue, the evidence, the hold-to-approve, the audit trail — is working in the VIVUU terminal as an interactive preview on realistic mock data. No sign-up.