What to Log for AI Agents — and What Each Platform Actually Gives You

Where these events actually come from

This is the part that is usually missing, and it is why "we should log our agents" tends to die in a meeting. Below is what each major platform actually gives you, what it withholds, and what you have to switch on. Vendors are named here because this is where their consoles are - not because any of them is worse than the others.

Two things to notice before the table. Almost all of it is off by default. And what each platform omits is more informative than what it collects - the omissions tell you which of your six events are simply unavailable today.

What a normal week looks like

You cannot spot the abnormal without the ordinary. Before you write a single detection, spend two weeks just counting. For each agent you want to be able to state, from data rather than from belief:

• Which tools it calls, and roughly how often. Most agents use three or four tools over and over and touch the rest almost never.
• Which document collections it retrieves from, and what proportion of what it reads originates outside the organization.
• Where it connects to. This list is almost always shorter than anyone expects, which is exactly what makes it a good control.
• How much text it processes in a typical session, so that a session ten times larger is visible as a number rather than a feeling.
• Whether it writes to memory at all, and if so how often.

Two weeks of counting will also produce your first three findings for free, because at least one agent will turn out to be reaching something nobody knew about.

The correlation spine

Collecting the events is the easy half. If an investigator cannot join them into one sequence, you have a pile of activity logs and not an audit trail - and the difference only becomes apparent on the day it matters, which is the worst possible day to discover it.

Every event in every family should carry the same set of joining fields. Not all of them apply to every event; the rule is that where a field could be populated, it is.

One honest limit. Correlation across organizational boundaries is unsolved. When your agent delegates to a partner’s agent, no standard makes the two audit trails consistent or cross-referenceable, and published work on agent identity says so plainly. Inside your own estate this is achievable today. Across a boundary, write it down as accepted risk rather than assuming someone has handled it.

Sixteen event families

Now the correction to 5.1. Six events is where you start, not the whole of it.

A production agent estate is a distributed system, and the evidence is scattered across the agent framework, the identity provider, the model gateway, the retrieval layer, the memory store, the tool servers, the runtime, the network, the cloud platform, and the application the agent actually changed. Sixteen families, below. Treat them as families rather than as record types - one product may emit four events for one family, and your job is to normalize them into a shape an investigator can use.

Where the evidence actually lives

The families above do not map one-to-one onto systems. Thirteen planes hold the evidence, and most organizations onboard two of them and call it agent logging.

Nine sources inside those planes are routinely missed, and each of them hides a class of incident that model-provider logs alone will never show you:

• Tool catalog and schema changes. The description a tool presents to the agent is an instruction. Changing it changes behavior without changing a line of your code.
• Prompt cache scope and invalidation. A cache shared across the wrong boundary is a data leak that looks like a performance feature.
• Context compaction and truncation. When the window fills, something is dropped. If your safety instructions are what got dropped, you would like to know.
• Index, embedding model and chunking changes. Re-embedding a corpus silently changes what every future query returns.
• Document tombstones and permission propagation delay. A file deleted or re-permissioned is often still answerable from the index for some period. Nobody measures that period.
• Browser automation. Redirects, page access, screenshots, clipboard, uploads and downloads.
• Ephemeral sandboxes. Created, used and destroyed inside a single task, taking the evidence with them.
• Secret and capability leases. Issued, used, renewed, revoked - and the gap between “revoked” and “actually stopped working”.
• Telemetry configuration itself. Sampling, redaction, exporters, parsers, retention. See 5.11.

Three tiers of evidence

A tier model resolves it. This ladder is our own synthesis rather than an established standard - there is no published AI-specific evidence-tiering guidance to point you at, and the relevant work is still unfinished. The generic forensic principles underneath it are long settled.

On that last exclusion, because it gets argued about. Defenders do not need the model’s internal chain-of-thought, and asking for it confuses two different things. What you need is the structured decision record: which sources were used, which policy version applied, what action was proposed, what class of alternatives was considered, what risk tier it fell into, what reason code was given, who approved it, what actually executed, what the downstream system confirmed, and whether a rollback succeeded. That is reconstructable, auditable, and does not require reading the model’s mind.

One regulatory anchor worth knowing. Under the EU AI Act, providers of high-risk systems must design in automatic logging, and deployers must retain those logs for at least six months. If any of your agents fall in scope, your retention floor is set for you.

Binding approval to the action that actually ran

Chapter 7 recommends an authority ladder: low-impact actions pre-authorized, larger ones needing an approver. That is worth nothing if the thing executed is not the thing approved.

Six ways the gap opens, all of them mundane:

• The agent revises the target after approval - same action, different resource.
• Parameters widen between proposal and execution, expanding the blast radius.
• An approval is replayed after it should have expired.
• A low-risk proposal becomes a destructive one through a retry or a reformulation.
• Execution happens under a different identity or in a different environment.
• A compromised tool interprets the approved request differently from the interface that displayed it.

A tool returning success is not evidence that anything happened

This one sounds pedantic until the first time it costs you.

A tool call returns success. That means the tool believes it sent the request. It does not mean the target system accepted it, completed it, completed all of it, or kept it. The downstream system may have rejected it, partially applied it, retried it into a duplicate, or reversed it thirty seconds later by its own rules.

So the tool call is a claim, and the target system’s own audit record is the evidence. Join them - carry a downstream_audit_uid from the tool call to the authoritative record in the affected system: the cloud audit log, the identity log, the SaaS audit trail, the database transaction, the pipeline record, the mail audit.

Once the join exists, six failures become visible that are otherwise invisible:

The operational rule: a high-impact workflow does not proceed to its next step on the strength of a tool’s own success message. It proceeds on confirmation from the system that was supposed to change.

Attribution again. This is our recommendation. We could find no published guidance stating that tool success is insufficient and the target system’s audit record should be joined, and no established name for the pattern. It is ordinary corroboration practice from incident response - prefer the authoritative log over the intermediary’s self-report - applied to a place nobody has applied it yet.

When the telemetry itself is the target

An agent with the power to change your systems has, quite often, the power to change your logging. A compromised agent that suppresses the evidence is not a hypothetical, and unlike most of this guide it is not even novel - it is an old technique arriving in a new place.

Treat loss of observability as an event class, not an operational annoyance. The signals:

The control that makes this more than an alert: for a high-risk agent, loss of observability should automatically reduce its autonomy - suspend privileged tools, drop it to propose-only, or stop the workflow. An agent you cannot see should not be an agent that can act. That inverts the usual failure mode, where telemetry quietly degrades for weeks and nobody notices because nothing appears to be wrong.