AI agent audit and compliance

AI agent audit and compliance is the problem of producing evidence about what AI agents did in production that survives someone else examining it. The frameworks that ask for this, and what each one asks, are covered in AI agent governance. This page is the other half: what an auditor actually does with the record, and what makes one hold up.

The gap between the two is wider than most teams expect. Nearly every organisation running agents has logs. Considerably fewer can produce evidence.

What evidence do I need to prove what my AI agents did in production?

You need one record per event, for every agent action and every runbook step. Each record names who acted, which policy decided, the verdict, and what changed. Log these events at minimum:

Event	Fields to record
Agent session start and end	Agent instance, role, session ID, and the person or alert that started it
Tool call	Tool name, target resource, and arguments with personal data minimised
Policy evaluation	Policy ID and version, and the verdict: approve, scope down, escalate or refuse
Human approval or rejection	Approver identity, time, and the action it covered
Grant or mode change	Credential issued or expired, scope widened, or a switch from read-only to write
Action result	Exit status and the resources that changed
Runbook run	Trigger (alert or incident ID), runbook version, each step with its target, and the final state
Runbook edit	Author, time, and a diff of the definition

Emit these events in OpenTelemetry format. Make each agent action or runbook step a span, and add the verdict and the approver as span attributes. Put the same trace context on the log records, so the audit record and the incident timeline share one trace ID. The OpenTelemetry GenAI semantic conventions define agent and tool-call spans, with attributes such as gen_ai.agent.id and gen_ai.tool.name. Their status is still Development, so pin the version you emit.

OpenTelemetry moves the event but does not sign it. Sign or hash-chain each record at the point it is written, and keep that copy in append-only storage.

For coding agents, how to audit and log AI agent actions covers Claude Code and Cursor hooks, mode changes, and a record written outside the agent.

Why most organisations cannot produce audit evidence

The raw events usually exist. These three problems stop them from becoming evidence.

The agent writes its own record. An agent transcript, or the run history of a runbook tool, is written by the agent you are auditing. The transcript also sits in the same context a prompt injection can reach. Write the authoritative record at the enforcement point outside the agent, and keep the transcript as the intent layer. The agent's own log shows what the agent reported. It cannot show what the agent ran.

One action is spread across several systems. The incident platform, the CI pipeline, the cloud provider's audit log and the agent session each hold part of it. Each uses its own identities and clock. Joining them by hand takes longer than an audit window allows. Put one trace ID on every record the action produces, so one query returns all of it.

Nobody owns the record end to end. Security runs the SIEM, the platform team runs the agents, and compliance owns the policy. Retention lapses and fields go missing between the three. Name one owner for the agent record, and have that owner run the retrieval test below on a fixed schedule.

What an auditor actually asks for

They do not ask whether you log agent actions. They assume you do, and then they sample.

The characteristic SOC 2 Type II move is to pick dates from inside the observation period and ask for everything in those windows. Type I assesses whether a control is designed correctly on a single date. Type II tests whether it operated across a period, typically three to twelve months, by pulling samples from within it. A control that was configured correctly and silently stopped running in month four fails Type II, and the failure is discovered by sampling month four rather than by anyone noticing at the time.

That shapes what the record has to support. Not "here is a log", but "here is every agent action between 02:00 and 04:00 on 14 March, and here is why you can believe that is all of them".

ISO/IEC 42001 certification and EU AI Act supervision work the same way. The question is never whether the control exists on paper. It is whether you can demonstrate it operating, over a window the examiner picks rather than one you prepared.

What makes a record defensible

Four properties, and most audit failures are one of them missing rather than the record being absent.

Completeness. You have to be able to show nothing was omitted. An appended text log cannot demonstrate this: entries can be dropped, and the file looks identical either way. Sequence numbers and a hash chain, where each record commits to the previous one, turn a gap into something detectable rather than invisible.

Integrity. The record has to be resistant to editing after the fact, including by people inside your organisation. Signing at the point of the decision, append-only storage, and keys held outside the system being audited are the usual mechanisms. A log an administrator could have edited proves less than it appears to.

Attribution. An action recorded against "the agent" or a shared service account is not attributable. The record needs a specific agent instance, role and session, which is why identity binding is a governance control rather than a logging one. This is the property that fails most often, and it usually fails at design time rather than in operation.

Decision, not just action. The record has to show which policy evaluated the action and what it decided. An entry saying an agent restarted a service proves the restart happened. It does not prove anything was governing the restart, which is the actual question being asked.

Refusals belong in the record too. An audit trail containing only permitted actions cannot distinguish a well-governed system from one where the policy never fired. The refusals are the evidence the control was live.

Incident platforms keep their own audit logs, and these help with attribution. Each log covers activity inside its platform. Check separately where each tool records the commands its automation ran against production, and whether that record names the policy that allowed them.

Tool	What its audit log records	Where you read it
PagerDuty	Most configuration changes to account objects, such as teams, schedules and escalation policies, attributed to the actor	Audit Trail Reporting, and the Audit Records API
Rootly	Data-changing actions in Rootly. Its docs say Rootly AI actions are included and attributed to the user who triggered them	The standard Rootly audit trail
FireHydrant	Logins, and the creation, update and deletion of incidents, runbooks, on-call schedules and other resources, with a before-and-after diff	Settings, and the audit view on each incident, runbook and schedule
NOFire AI	Every command, file and call an agent makes, with time, actor, action, gate and verdict, each line signed outside the agent	Exported to your SIEM

The vendor rows come from each vendor's public documentation, checked on 24 September 2026.

How long to keep it, and the tension

EU AI Act Article 26(6) requires deployers of high-risk systems to retain the automatically generated logs for at least six months. That is a floor, not a target, and the Act itself defers to other Union and national law where that demands longer.

A SOC 2 Type II observation period often exceeds it. Sector rules in financial services and gambling routinely do. Deployers that are financial institutions under EU financial services law keep the logs as part of the documentation that law already requires. So the practical retention figure is the longest applicable obligation rather than the six months most summaries quote.

Pulling the other way is GDPR storage limitation, which says personal data should not be kept longer than necessary for its purpose. Where an agent audit record contains personal data, and many do because the action payload includes it, these two obligations are in genuine tension. Article 26(6) anticipates this by explicitly deferring to data protection law.

The usual resolution is to separate the decision record from the payload. Retain the verdict, the policy, the identity, the timestamp and the signature for the full compliance period, and minimise or redact the personal data inside the action arguments. That keeps the property an auditor is testing, which is that the control operated, without keeping data you have no lawful basis to hold.

Article 12 sets what the logs have to support. A high-risk AI system has to support automatic recording of events over its lifetime. The logs must help identify risks and substantial modifications, support post-market monitoring, and let the deployer monitor operation. Article 26 is the deployer's side: use the system as instructed, assign human oversight, monitor it, and keep the logs under your control. Whether your agents count as high-risk systems under the Act is a question for your compliance team. The Article 12 purposes still make a sound design target for any agent log.

SOC 2 sets no retention figure of its own. It tests whether controls operated. CC7 covers system operations: detecting, evaluating and responding to security events and incidents. CC8 covers change management: changes to infrastructure and software are authorised, tested and approved before they go live.

The table maps each requirement to the record NOFire AI produces today. Meeting each obligation still depends on your own scope and controls.

Requirement	What the record has to show	What NOFire AI records
EU AI Act Article 12	Events recorded automatically, enough to trace risks, changes and operation	Every command, file and call an agent makes, written and signed outside the agent
EU AI Act Article 26(6)	Logs under the deployer's control, kept for at least six months	The record is exported to your SIEM, so your retention policy sets how long it stays
SOC 2 CC7	Security events detected, evaluated and acted on	Time, actor, action, gate and verdict on every row, refusals included
SOC 2 CC8	Changes approved before they run	Writes wait for a person, and the gate and verdict are on the row

Producing it on demand

The last requirement is retrieval. You have to be able to produce the record on demand, and this is where most teams fail.

Evidence you can only assemble by exporting from three systems and joining them by hand is evidence you will not produce inside an audit window. The queries that have to be cheap are narrow: every action in a time range, every action by one agent identity, every refusal, and every action that touched one service.

Test this before an auditor does. Pick a random two-hour window from four months ago and try to produce the complete, signed set for it. Whatever breaks in that exercise is what would have broken under examination. The usual causes are retention that expired without anyone noticing and attribution that was never captured. How to audit and log AI agent actions walks through building a record that passes it, including for Claude Code and Cursor.

NOFire AI is a production ops platform for engineers and AI agents. It produces this record as a byproduct of enforcement rather than as a separate logging pipeline, and signs each verdict at the point the action is permitted or refused. That design has one audit consequence. The control itself generates the evidence, so a missing record and a missing enforcement are the same event. They cannot drift apart.

Common failures

Logging the action and not the decision. The most common gap. It proves what happened and nothing about whether it was governed.

Only recording permitted actions. Without refusals there is no evidence the policy was live rather than passive.

Shared service accounts. Attribution fails at design time, and no amount of retention fixes it afterwards.

Retention set to the six-month floor. It is the minimum in one framework, not the answer across all of them.

Treating an audit as a document exercise. A written policy with no demonstrable operation is precisely what SOC 2 Type II is built to catch.