What to log in an AI agent audit trail

When an AI agent does something surprising, the first question is never philosophical. It is operational: what exactly happened, and who caused it? If your logs cannot answer that in under a minute, you do not have an audit trail — you have a vibe.

The fields that actually matter

A useful agent audit record ties together six things on every call:

• Worker and role — the identity that made the call, not a shared key.
• Tool and action — the specific operation, e.g. google_ads.mutate, not just "Google Ads."
• Connection — which account, repo, property, or workspace the call routed to.
• Request — the parameters the agent actually sent.
• Result — success, failure, or blocked, with the response or error.
• Decision — whether a policy allowed it outright, gated it for approval, or denied it.

Log the blocked calls too

The instinct is to log what happened. Log what almost happened as well. A denied call or a rejected approval is often the most informative line in the file — it tells you the agent tried to step outside its role, which is exactly the signal you want before it succeeds.

An audit trail you only read after an incident is insurance. One you read weekly is a control.

Make it queryable, not just present

Logs that exist but cannot be filtered by worker, tool, or account are evidence you cannot use. Structure each record so you can answer "show every mutation this worker attempted on client A last week" without grep gymnastics. Grantry records this shape for every call — allowed, gated, and blocked — so the answer is a filter, not an investigation.