SOC 2 for AI agents: what evidence an auditor can actually accept

At some point in the next twelve months, an auditor is going to ask what your AI agents did. Not what they were allowed to do — what they did. If you sell software to companies that care about SOC 2, the question arrives through your own audit; if you buy it, the question arrives through a vendor questionnaire. Either way, the answer "we have the chat logs" is about to stop being good enough, and it is worth understanding why before the fieldwork starts.

Where agents land in the criteria

SOC 2 does not have an AI section. A report is issued against the AICPA's 2017 Trust Services Criteria, with the points of focus revised in 2022, and nothing in that document mentions agents, models or prompts. That is not a loophole. The criteria are written around systems and system components, and an agent that reads a ticket, edits a repository and opens a pull request is a system component in every sense the criteria care about. It holds credentials, it changes production, and it does so without a human approving each step.

Three criteria do most of the work. CC6 covers logical access: what the agent can reach, with which credentials, and who granted them. CC8 covers change management: whether changes the agent makes to infrastructure, data or code go through the same authorisation, testing and approval controls as changes a person makes. And CC7 covers system operations. The wording of CC7.2 is the one to read twice:

The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.

To monitor the operation of a component for anomalies, you need a record of its operation that you can trust more than the component itself. For a database or a load balancer that is routine. For an agent, whose "operation" is a sequence of tool calls chosen at runtime by a model, it is the whole problem.

ISO/IEC 42001 says the same thing more directly

If you are also looking at ISO/IEC 42001:2023, the AI management system standard, the requirement is explicit rather than implied. Annex A control A.6.2.8, AI system recording of event logs, requires the organisation to determine at which phases of the AI system's life cycle event logs are recorded, and sets a floor: at minimum, while the system is in use. The standard's text is paywalled, so we will not quote further, but the shape is clear. Logging the agent while it is operating is not an optional hardening step under 42001; it is a control you either have or do not.

Both frameworks converge on one demand. You need a record of what the agent did, produced in a way that the auditor can rely on. Which raises the question of what "rely on" means.

Why a transcript is not evidence

Most teams' first answer is the conversation log: the prompts, the model's responses, the tool calls and their results, stored by whatever agent framework they run. It feels complete, and for debugging it often is. For an auditor it has three problems.

It is written by the thing being audited. The agent runtime produces the transcript, and the agent runtime is the component whose behaviour is in question. A model that has been hijacked by the content it read will still produce a tidy transcript; it will just be a transcript of the wrong actions. An auditor testing CC7.2 wants a monitoring record that would catch the anomaly, not one that the anomaly gets to write.

It describes intent, not effect. A tool-call record says the agent asked to run git push. It does not say the push succeeded, what commit went where, or whether the working tree it pushed matched the diff shown to the reviewer. The distinction between what an agent reported and what happened on disk is the entire premise of grading agents on ground truth, and it is also the distinction an auditor is trained to draw.

It can be edited after the fact by anyone with write access to the store. A Type 2 report covers a period, commonly six to twelve months, and the auditor samples from it. If the transcript store is a database your platform team administers, the auditor has to test the controls over that before the transcripts are worth anything. We covered why a hash chain alone does not close this gap in the receipts primer: a chain proves order and continuity, but whoever holds the chain can regenerate it.

What passes

Audit evidence has to be reperformable. The auditor picks a sample — twenty agent runs from March, say — and needs to establish, for each one, what ran, under what constraints, and with what result, in a way that does not depend on taking your word for it. That maps onto four properties a record of agent activity needs:

• Bound to the code that ran. A hash of the exact skill or tool code, so the auditor can confirm the sampled run used the approved version and not something patched in between. This is what makes the record useful under CC8 as well as CC7.
• Bound to the constraints it ran under. A hash of the sandbox profile or execution policy, so "the agent could not reach the network" is a checkable claim rather than an assertion. What a sandbox can and cannot prove on its own is in our sandbox write-up.
• Bound to inputs and outputs. Hashes rather than contents, so the auditor can confirm a specific input produced a specific output without the record itself leaking customer data. This matters for the confidentiality criteria: an evidence trail that stores raw prompts and outputs creates a second copy of every sensitive thing the agent touched.
• Signed by a key the agent cannot use. The attestation has to come from outside the agent's reach, otherwise you are back to the transcript problem. And the auditor has to be able to check the signature with a public tool, on their own machine, without asking you to run anything.

That is, deliberately, the structure of a Traceseal execution receipt. The specification is short enough to hand to an auditor: an execution block with the skill manifest hash, sandbox profile hash, input and output hashes, exit code and timing; a provenance block that names who signed the code and where it sits in the transparency log; and an attestation block with an ed25519 signature over both from an operator key that never enters the sandbox. The verifier is on PyPI, needs only the receipt file, and prints what the signature does and does not establish. The walkthrough is in How to verify what an AI agent actually did.

Two honest limits. A receipt proves the operator attested that this code ran under this policy and produced this output hash; it does not prove the output was correct or the policy was sensible. Those remain judgement calls, which is what the auditor is for. And a receipt only covers what was executed through the receipting boundary. If the agent can also act through a path that does not produce receipts, the auditor will find it, and should.

What to do before fieldwork

• Put agents on the system description. If an agent holds credentials or changes production, it belongs in the scoped system, named as a component, with its access documented under CC6. Auditors find undisclosed components far less forgivable than disclosed ones with gaps.
• Route every consequential action through one execution boundary that produces a signed record, and make it the only path. One receipted path and one unreceipted path is worse than either alone, because it invites the question of which one was used.
• Keep the records for the whole audit period, and then some. A Type 2 sample can reach back to the first day of the period. The EU AI Act's six-month log retention floor for high-risk systems, covered in our audit-trail piece, is a reasonable minimum even where the Act does not apply.
• Test your own evidence before the auditor does. Pick twenty runs at random, verify each receipt with the public tool, and confirm the manifest hash matches an approved release. If you cannot do that in an afternoon, the auditor cannot do it in a week.

SOC 2 has never asked whether your systems are clever. It asks whether you can show, to someone who has no reason to believe you, that they did what you say they did. Agents make that harder, because for the first time the component in question decides its own actions. The answer is not a better transcript. It is a record the agent did not write.