SOC 2 Evidence for AI Agents: An Engineering Checklist

AI agent records can support an organization's SOC 2 examination, but a policy template, passing scan, or exported report does not establish SOC 2 compliance. The system boundary, applicable criteria, evidence period, and sufficiency of controls belong to the organization's review with its auditor.

The AICPA Trust Services Criteria address security, availability, processing integrity, confidentiality, and privacy. This checklist organizes engineering evidence about an agent workflow; it does not determine which criteria apply to your organization or replace professional audit advice.

1. Record the system boundary and responsible owners

Describe the agent's purpose, users, data sources, connected models, tools, hosting environment, and operational owners. Include application services and external processing destinations that affect the workflow.

Distinguish the public API, the organization's workspace, and any private deployment. An architecture diagram should match the actual installation rather than a generic product overview.

2. Show who can change the workflow

Collect the relevant access configuration, review process, and change records for agent connections, policies, keys, and deployment settings. Explain the role boundary for each action and how access is reviewed or removed.

Do not put active API keys or identity-provider secrets into an evidence export. Record identifiers, scopes, and appropriate redactions instead. The API key guide explains the application's scope choices.

3. Explain what each policy controls

For a selected control, document its configured check, agent scope, warning or blocking mode, required detector availability, and application enforcement point.

A warning finding is different from a prevented operation. A completed evaluation is also different from independently measured detection accuracy. Attach test results that demonstrate the specific behavior you are describing, including the unavailable-check case.

Policy templates can help organize an implementation. They do not supply an independent assurance report.

4. Describe processing and retention honestly

Record where text is sent for evaluation, which model endpoints may process it, what telemetry is stored, and who can access retained evidence. Review the actual capture settings and deletion process rather than relying on a “metadata only” label.

Retention configuration and an executed cleanup are different facts. Identify how cleanup is scheduled and verify it in the installation. Start with data handling and settings and retention.

5. Preserve scoped test and incident evidence

For an assessment, include the target, date, model and policy configuration, selected probes, completed and incomplete counts, findings, and subsequent retests. Keep configuration changes and their approval context linked to the relevant result.

For an incident, retain the timeline, observed effect, investigation, corrective action, and follow-up verification within the organization's evidence policy. Do not describe ordinary application logs as immutable or complete unless the deployed storage and access controls substantiate that claim.

Reports and audit evidence describe the application's available records and export boundaries. A sample report illustrates the format rather than the effectiveness of your controls.

6. Review gaps with the audit owner

Before submitting records, identify missing instrumentation, unsupported operations, incomplete tests, and assumptions about external providers. Explain those gaps alongside the evidence, and agree the next action with the person responsible for the examination.

Nyraxis can contribute configured policy results, recorded traces, assessment findings, and regression evidence. The organization's broader access, change-management, infrastructure, and operational controls still need their own evidence.