SOC 2 has no control that says “AI agent”. It has the Trust Services Criteria, and an auditor who has been briefed that your product now includes something that approves refunds, drafts contracts, or moves money on its own. What changes is not the criteria; it is the questions. Below are the five we have seen auditors ask in 2026, in their own phrasing, with why the answer most teams give fails and what an answer that passes looks like.
The pattern across all five: the auditor is not asking whether you can explain what the agent did. They are asking whether you can prove it, to them, without them having to trust you.
1. “Show me the complete record of actions this system took in the period.”
The answer that fails:“We have logs.” The follow-up is always the same — where, for how long, and who can edit them. Application logs in an observability vendor default to 30–90 days; the audit period is twelve months. HCP Terraform keeps audit trails for 14 days, while GitHub keeps Git-category audit events for 7 days. The moment the auditor asks for March and you are in November, “we have logs” becomes “we had logs”.
The answer that passes:one append-only record, retention set to the longest obligation you carry (not the vendor’s default), in storage you control, with a count the auditor can reconcile: “4,102 actions across three agents in the period, here is the export.” CC7.2 and CC7.3 are the criteria they will cite.
2. “How do you know this record hasn’t been altered?”
Fails:“Only admins have write access.” That is an access control, not integrity evidence — it says who could have edited, not that nobody did. An auditor who has done one incident review knows the difference.
Passes:each entry carries a hash of the one before it, so an edit anywhere breaks every link after it; the chain head is signed on a schedule; and the signature is countersigned by an independent RFC 3161 timestamp authority, which turns “signed by us” into “existed before this moment, per a third party”. Then hand them the verifier and let them run it. CC6.1 and CC7.1.
3. “Who authorised this action?”
Fails: the log says svc-agent-prod. A service account is not a person, and SOC 2’s logical-access criteria (CC6.1–CC6.3) want a person. “The agent decided” is the answer the auditor is specifically checking you cannot give for anything material.
Passes: a policy that names the threshold in plain English — above $10,000, a person signs first — enforced beforethe action executes, with the approver’s identity taken from the authenticated session on the server, not from a field the agent filled in. The refusal is recorded beside the approval. Both are entries on the same chain.
4. “Walk me through an incident. Reconstruct it.”
Fails: screenshots from three dashboards, a Slack thread, and a spreadsheet somebody made the week after. It is not that the story is wrong; it is that it was assembled afterwards by the people being audited.
Passes: the sequence, from the record, in order — what the agent saw (as a fingerprint, so the payload itself need not leave your systems), what it called, what policy said, who approved, what happened. If the record is the one thing everybody agrees on, the incident review is an afternoon. CC7.4.
5. “Can I verify this without your help?”
Fails:“We can pull whatever you need.” That is the auditor trusting you to run the query. The criteria are about independence for a reason.
Passes: one file, the public keys, and a verifier they run on their own laptop with no account with you or with the vendor. Every other question on this list is downstream of this one — if the auditor can check the record themselves, questions 1–4 stop being conversations and become an export.
The five, side by side
| The question | What most stacks have | What passes |
|---|---|---|
| Complete record for the period | Vendor logs, 30–90 day retention | Append-only record, retention set to the obligation, in your storage |
| Not altered | Admin-only write access | Hash chain, signed head, independent timestamp countersignature |
| Who authorised | A service account | A named person, pre-execution, from the authenticated session |
| Reconstruct an incident | Screenshots and a spreadsheet | The sequence, from the record, in order |
| Verify independently | "We can pull it for you" | One file, public keys, offline verifier |
What to do this quarter
- 01Write down every plane that currently logs agent activity and its retention. The gap between the shortest one and your longest obligation is your exposure, in days.
- 02Pick the material actions — money, data, decisions about people — and write the threshold for each in one English sentence. That sentence is the policy.
- 03Route those actions through something that stops them before execution and records the approver’s identity from the session. If nothing does that today, that is the finding.
- 04Get the record out of the vendor’s retention window and into storage you control, hash-chained, with an independent timestamp on the head.
- 05Run an export and a verification yourself, before the auditor does. If you cannot, they cannot.
None of this requires a particular product; it requires those properties. We built one because the stacks we looked at had none of them and the deadlines — EU AI Act Article 19, Colorado’s three-year retention — were already dated. The category page says where we sit and where we do not.
- Related: the audit-trail spec, field by field
- Related: Auditant beside Vanta — the questionnaire, or the evidence
See it on a real chain
The evidence path described above is running on our own account. Every ad-account change made by the agents behind Admiral, our paid-ads product, is recorded on the chain admiral/prod — actions on the chain, seals countersigned, and the sealed-through sequence are read live at /trust, not written into the page.