A service starts returning errors at twenty past two in the morning. By the time somebody is awake and looking, the picture is this: a configuration value in production is not what the repository says it should be, and the change was made by a service account that four different automations share.

Somebody asks the obvious question. Was that one of the agents?

Two hours later the team still cannot answer it. Not because the systems are badly run. They have git history, CI logs, cloud audit trails and a paging system that woke the right person. They have all the usual evidence and none of it covers the part they need.

The three questions

Every reconstruction of an agent incident comes down to the same three, in this order:

  1. What was it asked to do? The instruction that started the work, and where that instruction came from.
  2. What did it decide to do? The specific action it proposed, before anything ran.
  3. Who let it? Whether a person approved that action, which person, and what they were shown at the time.

Notice that none of these are answered by knowing what changed. The cloud audit trail tells you a value was written and which credential wrote it. That is the outcome. The three questions are about the decision, and almost nobody is recording the decision.

Why the transcript is not an audit trail

The instinctive answer is that the conversation is right there in the tool. Scroll back and read it. In practice that fails for four separate reasons, and they compound.

  • It is not retained. Most agent tooling keeps conversations on the developer's machine or in a vendor account with a rolling window. The session you need is often the one that has aged out.
  • It is not tamper evident. A transcript that can be edited, truncated or regenerated is a document, not evidence. An auditor will treat it accordingly, and so should you.
  • It is not linked to the action. The transcript says the agent intended to update a value. The audit log says a value was updated. Nothing joins those two records, so you are inferring causation from timestamps.
  • It is not complete. Agents summarise. What you read is the narrated version, not the list of commands issued. The gap between the two is exactly where incidents live.

What an auditor actually asks for

This is where the compliance framing stops being abstract. Whichever regime you are held to, the underlying request is the same and it is very old: show me who did what, when, and on whose authority. Access control frameworks have asked that for decades. Nothing about it changes because the actor is an agent.

What does change is that the actor is fast, tireless and numerous. A team of six people might make forty consequential changes a week. Six people with agents might make four hundred. Evidence that was adequate at forty is not adequate at four hundred, and the failure is silent until the morning you need it.

You do not discover that your logging was insufficient during normal operation. You discover it at two in the morning, once, expensively.

What to record

The useful record sits at the point where an intention becomes an action. Not in the model, not in the cloud provider, but between them. Four fields, per action:

2026-07-28T02:14:07Z
  actor      agent:build-assistant  (on behalf of  r.mcallister)
  proposed   UPDATE config SET value='off' WHERE key='rate_limit'
  verdict    allowed  (policy: config-write, auto-approved)
  outcome    1 row affected

That is four lines and it answers all three questions at once. The instruction is attributed to a named human, the proposed action is recorded **{crimson|before** }it ran rather than inferred afterwards, the decision to permit it is explicit, and the result is attached.

The critical field is verdict. A log of what happened tells you the past. A log of what was permitted tells you whether your policy is working, including the actions that were proposed and refused. Those refusals are the most valuable rows in the table and they are the ones no outcome-based log will ever contain.

What the cloud trail does give you

It is worth being fair to the tooling you already pay for, because the gap is specific rather than total. A cloud audit trail is genuinely good at three things: it is complete for the API surface it covers, it is written by the platform rather than by the actor, and it is hard to tamper with after the fact. Those are exactly the properties a transcript lacks.

What it cannot do is tell you why. It records that a credential wrote a value. It has no concept of an instruction, a proposal, or an approval, because at the point it is written those have all collapsed into a single API call. You are not looking for a better audit trail. You are looking for a record from one layer higher up, and then a way to join the two.

The join is the part people skip, and it is cheap to get right if you do it at the start. A correlation identifier carried from the instruction through to the API call turns two disconnected logs into one story. Retrofitting it after an incident is considerably less fun.

How long to keep it

Retention is where good intentions quietly expire. The default on most logging platforms is somewhere between seven and thirty days, chosen by whoever set it up on the basis of cost, and never revisited.

Thirty days is not enough. The median time to discover an intrusion is measured in months, not days, and the questions that matter most are asked about the period before anybody suspected anything. A retention window shorter than your detection time means the evidence for every incident you have not noticed yet is already being deleted on a schedule.

The attribution problem underneath

One detail in the opening scenario does most of the damage: a service account that four automations share. The moment two things use one identity, attribution is gone and no amount of logging recovers it.

Agents make this worse because they are easy to stand up. A shared account gets reused because creating a new one requires a ticket, and the ticket takes a week. That is an organisational problem wearing a technical costume, and it is worth fixing first, because every control downstream of identity depends on it.

A drill you can run this week

Pick a day last month at random. Not a day you remember, a day you do not. Then try to answer these, with evidence you could show somebody else:

  1. Which agents took an action that changed something that day?
  2. For one of those actions, what instruction started it, and which person is accountable for that instruction?
  3. Was anything proposed that day and refused? What, and by which rule?
  4. How long will the records you just used still exist?

Teams who run this honestly usually stall on the second question and are surprised by the fourth. If you can answer all four in under an hour, your evidence is in better shape than most, and the exercise cost you an hour to find that out.

See where your evidence stands