What to Log for AI Agent Activity: The Minimum Viable Audit Trail

The first time a security team needs an AI agent audit trail is usually 72 hours after the agent has already done something it shouldn’t have. Detection fires. Someone pulls every relevant log from the SIEM (Kubernetes audit, container runtime, cloud audit) and three hours in realizes the events that actually matter were never written. 

Which prompt triggered the tool call. Which parameters the agent passed. Which output left the cluster. Those three log classes are doing exactly what they were built to do for deterministic workloads. AI agents need a fourth.

This article names the missing class, the agent-action log, and gives the minimum viable field spec for it across six event types.

Four log classes run in your cluster — three you have, one most teams are missing

There are four log classes that matter for AI agent audit trails. Three are already flowing into your SIEM. The fourth is the one most teams haven’t named yet.

Log class	What it captures	Where it goes blind for AI agents
K8s audit log	API server requests	Tools the agent called inside the pod
Container runtime log	stdout / stderr	What a compromised agent chooses not to print
Cloud audit log	Control-plane API calls	The prompt that triggered the API call
Agent-action log	Agent-decision events	(the class most teams haven’t deployed)

The Kubernetes audit log records API server requests. It sees kubectl exec into the agent’s pod, RBAC checks, configmap reads. It does not see the tool the agent invoked inside that pod three seconds later, or the parameters the tool received, or the resource the tool accessed in turn.

The container runtime log captures stdout and stderr. Agent frameworks like LangChain and AutoGen log to this stream by default, which is useful for debugging — and useless under adversarial conditions. A compromised agent has no incentive to print its actions to stdout, and prompt injection often suppresses output by design. The runtime log captures what the application chose to print; it cannot capture what it chose to hide.

Developer observability tools like LangSmith and Arize sit beside the runtime log, not as a fourth class. They trace reasoning chains for debugging, not behavior for security; the agent process emits them voluntarily; and a compromised agent can stop or falsify the emission. We have previously walked through this distinction in our work on runtime observability for AI agents — the telemetry overlaps; the reading discipline does not.

The cloud audit log — CloudTrail, Azure Activity, Cloud Audit Logs — records control-plane API calls. It sees that the agent’s service account called bedrock:InvokeModel at 14:32:07. It does not see the prompt that produced that call, the upstream tool result that led the agent to construct the prompt, or the relationship between this invocation and the seventeen others in the same session. We have previously broken down how this gap surfaces in production AI-mediated exfiltration scenarios — the cloud audit log records authorized access without recording causality.

The shared architectural blind spot is the application layer. None of the three existing classes operates where AI agent decisions actually happen — which is also why generic container alerts miss AI-specific threats. The fourth class — the agent-action log — sits there. In production, an eBPF-based sensor running at the kernel watches the agent’s actual behavior — tool calls, model invocations, data reads — and emits structured events without modifying agent code. The mechanism is one path to the same outcome. The point is that without something writing the agent-action log, the audit trail your security team is going to need does not exist.

Three readers force three minimum field sets — only the union ships

Most logging guidance assumes one audit trail serves everyone. For deterministic workloads that approximation usually held. For AI agents it doesn’t, because the three readers of an agent audit trail have non-overlapping minimums.

The SOC analyst doing incident reconstruction at T+72 hours needs causal chains. They need to walk from a triggering input through every tool call, every data access, every model invocation, to the destination of any output. Granularity must be millisecond-level timestamps and stable identity attribution. The events have to be queryable as a graph, not as a flat log stream.

The behavioral baseline engine — covered in our work on intent drift detection — needs frequency, sequence, and payload-shape signal across time. Individual events are less useful than the distribution of events. It cares about retention measured in weeks at minimum, because that’s how long a behavioral baseline needs to converge.

The compliance auditor preparing evidence under NIST AI RMF or ISO 42001 — or under PCI-DSS, HIPAA, NYDFS, the EU AI Act — needs immutability, exportability, retention configured to the most stringent applicable framework, and field-level traceability between the agent’s identity and the resources it touched — the same identity-to-resource correlation a runtime-derived AI-BOM provides at the inventory layer.

Requirement	SOC analyst	Baseline engine	Compliance auditor
Granularity	ms-level, identity-bound	event-level, attribute distributions	event-level, identity- and resource-bound
Retention	hot 90+ days	hot 30+ days for convergence	1–7 years cold, framework-dependent
Immutability	append-only acceptable	append-only acceptable	tamper-evident required
Redaction policy	aggressive on content, preserve metadata	aggressive on content, preserve schema	aggressive on content, preserve hash chain
Indexing	by trace / correlation ID	by event type and time bucket	by workload identity and resource URI

The right minimum is the union of these three columns, not the intersection. A spec that serves the SOC analyst but skips immutability fails the compliance auditor during the regulator’s evidence request. A spec that serves compliance but lacks queryable trace IDs leaves the analyst manually reconstructing chains under regulator-driven timelines.

Visibility has become a commodity — sensors see everything. The hard part is explaining why, and the explanation runs on the structure of the audit trail. The minimum viable trail is whatever structure makes the explanation possible later.

The agent-action log, event by event: what to capture for tool calls, model calls, data access, and policy decisions

Six event types together cover the agent-action log: tool invocation, model invocation, data access, policy decision, identity assertion, and error. Four require deliberate spec work; two inherit from existing patterns. Walk the four below; the table covers all six.

Event	Minimum fields
Tool invocation	event_id, trace_id, ts, workload_id, agent_session_id, tool_name, tool_version, param_schema, param_sensitivity, target_resource_type, return_status, return_size, return_hash, duration_ms
Model invocation	event_id, trace_id, ts, workload_id, agent_session_id, model_id, prompt_class, prompt_token_count, input_sensitivity, output_token_count, output_sensitivity, output_hash, tools_requested, policy_interventions
Data access	event_id, trace_id, ts, workload_id, resource_uri, access_mode, row_count, byte_count, sensitivity_tags_resolved, triggering_event_id
Policy decision	event_id, trace_id, ts, workload_id, policy_id, decision, evaluated_event_id, rule_fired
Identity assertion	event_id, trace_id, ts, workload_id, service_account, federated_identity, asserted_scope, granted_scope
Error	event_id, trace_id, ts, workload_id, error_class, originating_event_id, recovery_action

Tool invocation

The non-obvious field is param_schema. The trail must record that the agent called read_file with a path parameter of type string, classified as filesystem-sensitive — but it must not record the value of path itself. Storing parameter shapes preserves the ability to baseline (“this agent has never read from /etc/secrets before”) and to detect tool misuse and API abuse when those shapes drift, without retaining the values, which is often where PII enters. Pair param_schema with param_sensitivity resolved at invocation time. The combination tells you what the call was without telling you what it accessed.

Model invocation

Two constraints drive the spec: prompts and outputs cannot persist as plaintext, and downstream attribution depends on hashes. prompt_class is a coarse semantic category — “investigation summarization,” “code generation,” “report drafting” — assigned by classifier at invocation time. output_hash is a SHA-256 over the model’s raw output. Together they let an analyst confirm later, given a suspected exfiltrated document, that this specific model invocation produced it — without the audit trail ever storing the document. tools_requested records which tools the model asked to call, regardless of whether the agent runtime actually allowed the call; that distinction is where prompt injection often first becomes visible.

Data access

The byte count is the field that matters. An agent reading a sensitive table is normal; the same agent reading the table once in the morning and dumping it in the afternoon shows up as orders of magnitude of difference in byte_count between the two events. Sensitivity tags must be resolved at access time, not from declared catalogs — declared catalogs lag, and an agent reading a column reclassified yesterday must reflect the new tag immediately. The triggering_event_id ties the data read back to the tool or model invocation that caused it; without that pointer, the chain breaks.

Policy decision

A short spec because it inherits from established admission-controller logging. The minimum is the decision outcome (allow / deny / flag), the event being evaluated, and the rule that fired. This is how the audit trail proves a control was enforced — or, more interestingly, that the control fired and was overridden, which is the bug-or-attack signal an analyst will need at T+72h.

Identity assertion and error event types remain as table-only entries. Identity assertion inherits its fields from existing Kubernetes service account and workload identity logging; the agent-action log carries the link without re-instrumenting the underlying assertion. Error events follow standard error-logging patterns, with one addition: originating_event_id so error events sit in the same chain as the events that produced them.

Redact the prompt, preserve the proof — the only redaction pattern that survives an investigation

A logging spec that stores prompt content and model output as plaintext is a PII spill waiting to happen. A spec that omits both entirely makes regulatory investigation impossible. The pattern that survives both pressures lives between them.

What gets redacted, at the source: prompt content, model output, user content, secrets. Redaction happens at the sensor or application boundary, never at the SIEM — by the time content reaches the SIEM, every intermediate system has a copy. What persists instead is data shape (token counts, byte counts, structural schema), sensitivity classifications resolved at the moment of access (PII:email, PCI:pan, PHI:diagnosis, secret:api_key), semantic tags (“contained secret-like pattern,” “matched investigation document classifier”), and content hashes computed before the redaction step.

The hash is the load-bearing part. A SHA-256 of the model’s output recorded in the audit trail proves, later, that this specific invocation produced a specific piece of content — provided that content can be recovered from the destination side (a recipient’s mailbox, a leaked file, a customer’s account). The regulator does not need the audit trail to store the disclosed content; they need the trail to prove the disclosure occurred. Hash-anchoring delivers that proof without the storage liability.

This pattern beats both ends of the spectrum. Full plaintext storage is a PII liability that scales with retention. Category-only logging (“output contained PII”) proves nothing — an analyst or auditor confronted with “your trail says the agent leaked something PII-class on Tuesday” has no way to identify what, to whom, or whether the leaked content matches a specific external artifact. The combination — redacted content, preserved shape, sensitivity tags, and hash — is what lets the audit trail serve a regulator without serving as a secondary breach.

The 90-day test: five questions your audit trail must answer about any agent incident from last quarter

The test is a self-audit, not a vendor evaluation. Pick any AI agent incident or anomaly from the last ninety days and run the trail against five questions.

1. Can you identify which input or upstream event triggered the agent’s decision? Tests trace and correlation ID coverage. If the trail starts at the tool call without a pointer to the prompt that produced it, the chain is broken at its origin.

2. Can you list every tool the agent called, in order, with parameter shapes? Tests tool invocation event coverage. If you have the names but not the parameter schemas, you can describe activity without being able to assess intent.

3. Can you identify every data resource the agent accessed, and how much was read from each? Tests data access event coverage with byte counts. If byte_count is missing, you cannot distinguish a routine read from an exfiltration even when the events themselves are present.

4. Can you prove or rule out that a specific output left the cluster? Tests model invocation hashing and egress correlation — the same signals agent escape detection consumes. If output hashes are absent, this question is unanswerable in either direction — and “we cannot rule it out” is the most expensive sentence to write in a regulatory response.

5. Can you reconstruct the identity chain — which service account asserted which permissions under which workload identity? Tests identity assertion event coverage. Identity gaps are where compliance evidence fails first, because every regulator asks this question.

Each failed answer maps to a specific event type or field missing from the current pipeline. The test surfaces the gap, not just the verdict.

From class gap to instrumentation plan

The minimum viable audit trail is not a question of log volume. It is a question of log class. The fourth class — the agent-action log — either exists in your pipeline or it doesn’t, and the difference is roughly the difference between an investigation that closes in days and one that drags into the quarter the regulator’s letter arrives.

The operational next step is the 90-day test against an incident your team already investigated, not a hypothetical one. Note where the five questions surface field-level gaps. Tool invocation and data access usually surface first; instrument those before chasing the long tail. ARMO’s CADR engine consumes the agent-action log to produce the attack story analysts need at T+72h, and the cloud-native security platform for AI workloads makes the log a first-class part of the trail. The test runs against any pipeline. The point is to run it.

FAQ

Can you build an AI agent audit trail from OpenTelemetry traces alone?

OpenTelemetry carries the schema and propagates trace context reliably; it does not carry kernel-level ground truth. For workloads where the threat model includes a compromised agent or a poisoned dependency, instrumentation that depends on the agent process to emit its own telemetry is structurally weak — the compromised process has no incentive to report its activity accurately. OTel is necessary substrate for trace correlation; it is not sufficient as the trail itself.

How long should AI agent audit trail events be retained?

Tier by event type. Tool invocation and data access events justify hot retention of ninety days or more because they are the primary substrate for forensic reconstruction. Model invocation metadata can move to cold retention sooner if hashes are preserved. Vertical regulators set the floor: PCI-DSS at one year with three months immediately available, NYDFS at five years for documentation, HIPAA at six years.

Do you need to log raw prompts to support a regulatory investigation?

No. The hash-anchor pattern, paired with sensitivity classifications and byte counts, delivers stronger evidentiary support than plaintext storage in most investigations — and avoids the secondary PII liability plaintext storage creates. Regulatory guidance has moved toward data minimization — the EU AI Act’s framing and recent GDPR enforcement both push against audit trails that themselves store sensitive content unnecessarily.

Does the agent-action log replace the Kubernetes audit log?

No. The two log classes sit at different layers and answer different questions. The agent-action log records what the agent decided to do at the application layer; the Kubernetes audit log records what the control plane was asked to do at the API server. A complete audit trail feeds both into the SIEM and correlates across them at investigation time.

What is the minimum retention period needed to support the 90-day forensic reconstruction test?

Ninety days of hot retention for the agent-action log specifically. Cold retention extends from there to whatever your most stringent compliance framework requires. Inside the ninety-day window, prioritize storage for tool invocation, data access, and model invocation; identity assertion and error events can move to compressed cold storage sooner.