An AI agent audit log should reconstruct who initiated a run, which agent and version acted, what context it received, which tools it called, what changed, who approved the action, and how the result can be reversed. Log decisions and side effects as linked events, protect sensitive fields, and preserve an immutable evidence path. A transcript alone is not an adequate audit trail.
Tech
An AI agent audit log should reconstruct who initiated a run, which agent and version acted, what context it received, which tools it called, what changed, who approved the action, and how the result can be reversed. Log decisions and side effects as linked events, protect sensitive fields, and preserve an immutable evidence path. A transcript alone is not an adequate audit trail.
Scope and Control Status
Reviewed on 30 July 2026, this is a technical template, not a universal legal schema. The fields below are recommended practice derived from risk-management, logging, and agent-security guidance.
The NIST AI RMF Core is voluntary and calls for documented accountability, testing, monitoring, and third-party risk controls. NIST’s 2026 work on evaluation probes for agentic AI specifically explores structured audit trails connecting agent claims to supporting evidence.
The OWASP Agentic Security Initiative identifies risks involving goal hijacking, tool misuse, identity abuse, memory poisoning, cascading failures, and rogue behaviour. Useful logs must expose those pathways.
Separate legal requirements can apply. For example, Article 26 of the EU AI Act requires applicable high-risk deployers to retain automatically generated logs under their control for an appropriate period of at least six months, unless other law provides otherwise. The 2026 Omnibus changed relevant high-risk application dates. Obtain legal advice for retention and content obligations.
Use an Event Model, Not One Large Record
An agent run can branch, retry, request approval, call several tools, and partially fail. Store append-only events linked by stable identifiers:
• trace_id: the complete user-to-outcome journey.
• run_id: one agent execution.
• span_id: one model, retrieval, policy, approval, or tool operation.
• parent_span_id: the event that caused this operation.
• event_id: a unique immutable record.
• occurred_at: when the event happened.
• recorded_at: when the logging system stored it.
The difference between occurrence and recording time helps detect delayed or missing telemetry.
Recommended event types include:
• run.started
• context.retrieved
• model.completed
• policy.checked
• approval.requested
• approval.decided
• tool.requested
• tool.executed
• state.changed
• message.sent
• exception.raised
• rollback.executed
• run.completed
Do not allow the agent to overwrite a prior event. Corrections should create a new linked event.
The Core Audit Schema
1. Identity and authority
Record:
• Human initiator ID and organisation.
• Authenticated session or service principal.
• Agent ID and agent instance ID.
• Delegation chain: who authorised the agent to act.
• Role and permission scope at execution time.
• Credential reference, never the raw secret.
• Policy decision and policy version.
NIST’s 2026 agent identity concept paper is not a final standard, but it highlights identity, delegated authority, auditing, non-repudiation, and binding agent actions to human authorisation as open control problems.
2. System and version
Record:
• Workflow ID and version.
• Agent configuration version.
• Model provider, model identifier, and pinned version where available.
• System-prompt hash or version.
• Tool-registry version.
• Knowledge-base snapshot or index version.
• Evaluation and release ID.
• Environment: test, staging, or production.
Avoid storing a secret system prompt in unrestricted logs. Store a protected reference and integrity hash.
3. Trigger and intent
Record:
• Trigger type and source.
• Original user request or protected reference.
• Structured task objective.
• Business workflow and declared purpose.
• Risk class.
• Expected output or allowed actions.
• Deadline or budget constraints.
This distinguishes what the user asked from what the agent inferred.
4. Context and evidence
Record:
• Retrieved document IDs and versions.
• CRM, ticket, invoice, or account record IDs.
• Retrieval scores where useful.
• Data classification.
• Consent or lawful-basis reference where required by the workflow.
• Evidence snippets only when necessary and permitted.
• Source timestamps and freshness.
Minimise personal data. A pointer to a controlled record can be safer than copying its full contents into telemetry.
5. Model and policy decisions
Record:
• Output reference or redacted output.
• Structured reason code.
• Confidence or uncertainty signal, with its definition.
• Policy rules evaluated.
• Guardrail result.
• Escalation decision.
• Human-review requirement.
• Rejected or blocked action and reason.
Do not present model confidence as calibrated probability unless it has actually been validated.
6. Tool calls and side effects
For each call, record:
• Tool and operation.
• Sanitised parameters or parameter hash.
• Target system and object ID.
• Permission scope used.
• Request and response status.
• Idempotency key.
• Before and after state for mutable fields.
• External message recipient or protected reference.
• Cost, duration, retry count, and error.
The side-effect record is critical. A successful API response does not prove the intended business result occurred.
7. Human approval
Record:
• Approval request ID.
• Proposed action summary.
• Reviewer ID and role.
• Decision: approve, reject, modify, or expire.
• Decision timestamp.
• Evidence shown to the reviewer.
• Changes made by the reviewer.
• Separation-of-duty result for sensitive actions.
Approval must precede the action it authorises. A retrospective checkbox is not an approval control.
8. Outcome and recovery
Record:
• Completion status.
• User-visible result.
• Business outcome reference.
• Exceptions and compensating actions.
• Rollback method and status.
• Reconciliation status.
• Incident ID if escalated.
• Feedback and final reviewer disposition.
Example Event
``json { “event_id”: “evt_01J…”, “trace_id”: “trc_01J…”, “run_id”: “run_01J…”, “span_id”: “spn_04”, “parent_span_id”: “spn_03”, “event_type”: “tool.executed”, “occurred_at”: “2026-07-30T10:42:16Z”, “actor”: { “agent_id”: “crm-follow-up-agent”, “human_principal_id”: “usr_1842”, “delegated_scope”: [“crm.task.create”] }, “system”: { “workflow_version”: “3.4.1”, “model”: “provider/model-version”, “policy_version”: “follow-up-policy-12” }, “tool”: { “name”: “crm”, “operation”: “task.create”, “target_ref”: “contact_9811”, “idempotency_key”: “idem_71…”, “status”: “success” }, “approval_ref”: null, “data_classification”: “internal”, “rollback_ref”: “rbk_01J…” } ``
This is a recommended shape, not an official NIST or OWASP schema.
Implementation Steps
1. Define critical workflows and side effects.
2. Establish trace, run, span, and event identifiers.
3. Create a versioned event dictionary.
4. Instrument policy, approval, tool, and rollback boundaries.
5. Redact or tokenise sensitive values before storage.
6. Separate security access to logs from workflow administration.
7. Protect integrity and monitor logging failures.
8. Test reconstruction with known incidents.
9. Set retention by legal, contractual, security, and operational need.
10. Export evidence in a readable format without exposing secrets.
The NCSC secure AI guidance recommends monitoring and logging inputs in line with privacy obligations, while its development guidance treats logs as sensitive assets requiring confidentiality, integrity, and availability controls.
Evidence and Artifacts
• Versioned schema and event dictionary.
• Data-classification and redaction rules.
• Access-control matrix for log systems.
• Retention and deletion schedule.
• Integrity and backup design.
• Logging health alerts.
• Sample trace reconstructions.
• Release test proving all critical events are emitted.
• Incident exports and chain-of-custody record.
• Vendor log-field and export commitments.
Common Failure Modes
Only prompts and outputs are stored. Tool side effects, policies, and approvals remain invisible.
Logs contain credentials. Telemetry becomes a new breach path.
All records share one service account. Human delegation and agent identity cannot be reconstructed.
Mutable logs are controlled by the workflow administrator. A privileged user can remove evidence of their own actions.
No before-and-after values exist. Rollback and impact analysis become manual.
Retries are hidden. One user request may create duplicate messages, tasks, or payments.
Retention is copied from web analytics. Audit, privacy, and contractual needs require a deliberate schedule.
SMB Audit Log Checklist
• [ ] Use trace, run, span, and event IDs.
• [ ] Bind agent actions to an authenticated human or service authority.
• [ ] Record workflow, prompt, policy, model, and tool versions.
• [ ] Reference the source context and its freshness.
• [ ] Log every policy result and blocked action.
• [ ] Capture sanitised tool inputs and outputs.
• [ ] Record before and after state for changes.
• [ ] Link approval before execution.
• [ ] Add idempotency keys and retry counts.
• [ ] Define rollback and reconciliation references.
• [ ] Redact secrets and minimise personal data.
• [ ] Restrict and monitor access to logs.
• [ ] Alert when critical events fail to record.
• [ ] Test whether a reviewer can reconstruct one run.
For permission levels and review ownership, see the AI agent governance guide.
FAQs
Is a conversation transcript an AI agent audit log?
No. It usually omits identity, permission scope, model and prompt versions, policy checks, tool calls, side effects, approvals, retries, and rollback.
Should prompts be stored in full?
Only when justified and protected. Prompts can contain personal data, confidential information, or attack payloads. Prefer redaction, structured fields, hashes, or controlled references where possible.
How long should AI agent logs be retained?
There is no universal period for every agent. Set retention from applicable law, contracts, incident needs, and data-minimisation principles. Applicable EU high-risk deployers have a separate minimum requirement for automatically generated logs under their control.
What makes an audit log tamper-resistant?
Use append-only storage, restricted administration, integrity validation, monitored exports, protected backups, and immutable correction events. The exact design should match risk and infrastructure.
What is the difference between audit logs and observability?
Audit logs reconstruct authority and actions. Observability measures current behaviour, quality, reliability, latency, and cost. A mature system uses both but does not confuse them.
Get a 20-Minute AI Workflow Audit
AI Operator can map a workflow’s identities, evidence, tool calls, approvals, and rollback needs into an implementation-ready event schema.