What agent actions should you log?

Why do we log activity? The obvious answer is “to understand what happened and how”. And within many systems, the “what” and the “how” are closely related. A database entry was deleted because someone clicked on the “delete” button. Then, we ask the human for the third piece of the puzzle, the “why”.

AI agents are fundamentally different. They log the human’s “why” as input, but have their own reasoning on whether to take specific actions, based on probabilistic LLM interpretation. They can also break down the relationship between the “what” and the “how”.

Even if you log everything an agent does, you might not be able to answer the only questions that matter during an incident: what did this agent do and on whose authority?

To avoid this, you need to think about what you’ll need to reconstruct, not what the platform emits. And unlike with permissions, where each check should have an artifact you point to, here each check should have a query that’s made possible by it.

Also, you should log the denials. An agent probing for scope it does not have leaves a trail that can help answer some of the questions.

Phase 1: Capture

Every tool and MCP call produces an event

• One record per invocation, including errors and refused calls
• Only the final output is logged, or only successful calls

The trigger instruction is recoverable

• From a logged action, you can get to a prompt, message, or ticket that set it off via an identity
• The action is logged without the instruction

Credential and token events are captured

• Token issuance, refresh, and scope grants for the agent's identity are logged
• You can see what the agent did but not which credential it used

Data reads include output volume

• The query or path plus how much came back: rows, records, and files
• "Read: CRM," with no way to tell one contact from the whole table

Writes are distinguishable from reads

• Writes, sends, deletes, payments, and config changes separable by field, not tool name string-matching
• Reads and writes are in one undifferentiated activity stream

Denials and blocks include a reason

• Policy denials, permission errors, and guardrail blocks persist, each with the blocking rule
• Only permitted actions are logged

Human approvals are events

• Who approved, what they were shown, and which actions the approval authorized
• The approval exists as a consent click that leaves no record

Agent-to-agent delegation is captured

• The handoff and the downstream actions are both logged
• A sub-agent's actions appear as though the sub-agent originated them

Changes to the agent itself are logged

• Edits to the system prompt, tool list, model, or scopes, recorded with who made them and when
• Behavior changed and the log shows only the new behavior

Phase 2: Prove

Every event names the agent

• An agent identifier resolving to exactly one agent, distinct from its owner and from the host application
• The human owner's identity stamped on an autonomous action

Every event names for whom it was acting

• Agent, on-behalf-of principal, and tool all present on the same record
• "Agent did X" with no answer to the question of on whose behalf

One trace ID spans the whole task

• A single identifier links the trigger, the model call, every tool call, and the write, across systems
• You can’t easily assemble a chain that has 5 MCPs

Time is unambiguous and ordered

• UTC, with enough precision to order two calls inside the same second
• Per-component local time zones

Content is minimized without gutting the event

• Action class, parameter digest, and policy decision ID stand in for the payload, with pre-minimization digest
• Raw PII sitting in the log, or an overly-strict redaction

Logs are queryable by agent, system, and window

• "Everything agent X touched last Tuesday" is a possible query
• The answer requires a vendor support ticket or a grep across exports

There's a volume baseline per agent

• Expected calls and records per day are written down, so a spike can be measured
• "Anomalous" is decided arbitrarily, based on human observation

Phase 3: Retain

Agent logs are at the same place as human logs

• Same pipeline, same detections, same analysts
• Activity spread across consoles no one watches

The log outlives the agent

• Decommissioning the agent, rotating its credential, or cancelling the vendor leaves the history intact
• Retention tied to the subscription

Retention is set by your investigation window

• A stated period with a reason behind it, such as typical discovery lag or the audit cycle
• The platform's default accepted without questioning it

The log is tamper-evident

• Append-only or hash-chained storage, so alteration shows
• The agent's own credential can write to the store that records it

A missing log would be noticed

• A gap or heartbeat check that fires when an expected stream goes quiet
• Silence read as normal inactivity

Someone has reconstructed an action end to end

• A dated exercise that took one real agent action back to its trigger and its approval, with the time it took
• The capability is assumed