SOC 2 Type II for AI Agents: What Your Auditor Is About to Ask You

Auditors are starting to ask how you govern AI agent behaviour. Here is what SOC 2 Type II actually treats as evidence, and why a plain application log usually is not enough.

The SOC 2 AI agents question usually arrives mid-audit. Your SOC 2 Type II auditor, certified before autonomous agents reached production, asks how you govern agent behaviour. The old checklist assumes deterministic software, and “we log everything” no longer satisfies the availability or processing integrity criteria.

SOC 2 is defined by the American Institute of Certified Public Accountants (AICPA), and it tests whether your controls operated effectively over a period. The criteria are technology-neutral, so the framework never named AI agents and did not need to. Your agents are now part of the system under examination, so their actions need the same evidence trail as any other control.

What SOC 2 Type II Auditors Are Now Looking for in AI Systems

A SOC 2 Type II auditor looks for evidence that a control operated effectively across the whole review period, not that it exists on paper. For AI agents, that means dated, verifiable records showing each action was checked against policy and either permitted or stopped, for every session.

A Type I report inspects control design at a single point in time. A Type II report tests design and operating effectiveness across a defined period, sampling dated artifacts such as logs, tickets, and approvals rather than a single snapshot. The AICPA fixes no minimum length; in practice it runs from three months to a year. Controls must be shown to work, repeatedly, over time.

Traditional software makes this straightforward, because behaviour is deterministic. An agent is not: it plans, calls tools, and acts autonomously, and two runs of the same prompt can diverge. So the question is no longer whether you have a policy for your agents. It is: show me, for this action on this date, that the policy was enforced and what the outcome was. Answering that with artifacts is the job.

The Five Trust Services Criteria Mapped to AI Agent Behaviour

SOC 2 rests on five Trust Services Criteria defined by the AICPA: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory in every audit; the other four are added based on the commitments you make to customers. Each maps to a runtime control and a piece of evidence once AI agents are in scope.

The table below maps each criterion to an agent control and the evidence it produces, using OpenBox, an AI agent governance platform, as the reference implementation.

One caveat: this evidence supports the criteria but does not by itself make you SOC 2 compliant. A SOC 2 report is still an independent CPA firm’s opinion; the tooling only produces the artifacts.

Two criteria are where auditors push hardest on agents. Processing Integrity requires processing that is complete, valid, accurate, timely, and authorised; the Trust Score and the governance decision on each action show the agent acted within defined parameters, covering the “authorised” element. Availability concerns a runaway session degrading the service, and two of the four decisions exist for that: BLOCK denies a single non-compliant action while the session continues, HALT terminates it immediately. Behavioral Rules detect multi-step patterns and escalate to either. Every intervention is recorded, so the control is evidenced.

Why Logging Is Not Audit Evidence (And What Is)

An application log is a record your own system writes and your own team can edit. Audit evidence is a record an auditor can trust without trusting you: dated, complete for the period, and verifiable as unaltered. A log shows what your code chose to record; audit evidence shows what happened and proves it was not changed after the fact.

The gap matters under a Type II examination for three reasons. A log can be incomplete, recording what a developer chose to write, not every governed action. It is mutable, because anyone with write access can amend it. And it usually lacks decision context, telling you an action occurred but not that it was checked against policy and permitted, blocked, or escalated.

What counts is a governance record with two properties a plain log lacks. OpenBox records every governance decision with its verdict, reason, timestamp, and workflow identifiers, per docs.openbox.ai/administration/compliance-and-audit, and signs each session’s events so alteration is detectable. Separate the two records OpenBox keeps: the organisation audit log is a searchable, exportable history of administrative events, while the per-session governance events, hashed and signed, are the runtime evidence that a specific action was governed. Auditors want both, and weigh the signed evidence more heavily because it is tamper-evident.

How Cryptographic Attestation Satisfies SOC 2 Processing Integrity Requirements

Processing integrity asks whether system processing is complete, valid, accurate, timely, and authorised. Cryptographic attestation answers the “complete and unaltered” half directly: OpenBox hashes every governance event, combines them into a per-session Merkle tree, and signs the root, producing a Proof Certificate an auditor can verify independently.

The pipeline, per docs.openbox.ai/administration/attestation-and-cryptographic-proof, runs when a session completes. Each governance event is hashed with SHA-256, the hashes are combined into a Merkle tree using sorted-pair hashing so the tree is built consistently regardless of order, and the session root is signed. The result is a Proof Certificate carrying the Merkle root, the signature, and the event count, one per session.

Signing uses AWS Key Management Service by default, with a dedicated key per agent and the ECDSA NIST P-256 algorithm. Organisations that need to sign inside their own infrastructure, such as a Trusted Execution Environment, can use an external attestation endpoint instead. Either way, the auditor receives a signature they can check against the recorded events.

What makes this audit-grade is the event count and the decoupling of signing from the verdict. A BLOCK or HALT is still recorded and signed, so the certificate captures more than the allowed actions: it proves the session record is complete. Paired with the governance decision, which shows the action was authorised, the Proof Certificate turns “we log everything” into signed proof, verifiable without trusting you, that each action was governed.

The 8 Questions to Prepare Before Your AI Agent SOC 2 Review

Prepare answers to eight questions your auditor is likely to raise once AI agents are in scope. Each maps to a Trust Services Criterion and to a specific artifact you should be able to produce for any date in the period.

1. Which agents are in scope, and can you produce an inventory? Show each agent with its risk profile and current Trust Score. (Security)

2. For a given action, can you show the governance decision applied and why? The verdict, reason, and timestamp for any action. (Security, Processing Integrity)

3. How do you stop an agent behaving outside policy, and where is that recorded? Evidence of BLOCK and HALT interventions and their signed records. (Availability)

4. Can you prove your agent decision records were not altered after the fact? The per-session Proof Certificate, with Merkle root, signature, and event count. (Processing Integrity)

5. How is agent access to confidential data restricted and approved? The policy or guardrail that gates it, and any REQUIRE_APPROVAL record with the approver. (Confidentiality)

6. How is personal data handled by agents, and where is that recorded? Dated governance events and audit log entries for personal-data operations. (Privacy)

7. Can you export a complete, dated evidence set for the whole period? On-demand audit log export plus the signed session records. (all criteria)

8. Who approved high-risk agent operations, when, and is it logged? Approval metadata: who approved or denied, when, and any expiry. (Security, Confidentiality)

FAQ

Do SOC 2 auditors require evidence of AI agent governance, or is it optional?

If AI agents sit within your system boundary, their controls are in scope, so evidence of how you govern them is not optional. SOC 2 is technology-neutral, and the AICPA criteria apply to any component under examination. Which criteria apply depends on your commitments to customers.

Is a standard application log sufficient evidence for SOC 2 processing integrity for AI agents?

Usually not on its own. A log is written and editable by the audited party, so it shows what your system chose to record, not verifiable proof it was unaltered. Auditors increasingly want dated, complete, tamper-evident evidence that a governance control operated on each agent action.

What is the difference between an audit log and cryptographic attestation, and which does SOC 2 require?

An audit log is a searchable history of administrative and operational events, useful but editable. Cryptographic attestation signs the governance record so alteration is detectable. SOC 2 names neither by product; it requires evidence that controls operated effectively, and signed attestation makes that evidence verifiable to an auditor.

How long does it take to set up SOC 2-ready AI agent governance with OpenBox?

Setup time depends on your framework and scope, so a fixed figure would mislead. OpenBox installs as a single SDK that wraps an existing agent with no architectural changes, and begins recording signed governance events from the first session. Evidence then accumulates across your observation period.

The bottom line on SOC 2 AI agents

The SOC 2 AI agents problem is not about logging more. When agents land in scope, the question is whether you can hand an auditor dated, complete, tamper-evident proof that each action was governed. OpenBox, an AI agent governance platform, produces that evidence automatically: every governance decision is signed into a Proof Certificate an auditor can verify. It installs as a single SDK, available to every organisation, so evidence accrues from your first governed session.