SOC 2 Evidence Mapping for AI Agents
A SOC 2 review may ask how you control AI agent access. Here is the answer: trust service criteria mapped to runtime authorization, with exportable operating evidence your auditor will understand.
Last updated: May 20, 2026
SOC 2 and AI agents
SOC 2 (Service Organization Controls 2) is an auditing framework developed by the AICPA that evaluates how organizations manage data based on five trust service criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. When your organization deploys AI agents that access, process, or modify customer data, governed tool calls that affect your commitments can become SOC 2 evidence. Without a control point on the tool path, the auditor has to rely on policy intent rather than operating evidence.
The AI agent gap in SOC 2
Traditional SOC 2 controls were designed for human operators and deterministic software. AI agents introduce a new category of accessor: a non-human actor that can make repeated tool calls outside a human UI. Existing access controls may show who provisioned the credential, but not what the agent did with it.
Auditors are starting to ask specific questions: How do you control what AI agents can do? How do you record governed agent actions? Who approves access to sensitive data? If you do not have answers backed by evidence, the review gets harder.
Trust service criteria mapping
Each trust service criterion (TSC) maps to specific Veto capabilities. This mapping gives your auditor a clear control-to-evidence path for AI agent activity.
Logical and physical access controls
The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.
Veto controls
- Per-agent tool-level access control: Each agent has a defined set of permitted tools. Access is denied by default: agents can only call explicitly allowed tools with explicitly allowed arguments.
- API key scoping: Agent API keys are scoped to specific projects and organizations. Project and organization scoping limits cross-tenant access risk.
- Environment isolation: Dev, staging, and production environments have separate policy sets. An agent authorized in dev is not automatically authorized in production.
Operating evidence
Export the policy YAML file showing allowed tools per agent. Export the decision record filtered by agent ID showing denied access attempts. Provide the API key configuration showing project/org scoping.
Role-based access and least privilege
The entity authorizes, modifies, or removes access to data, software, functions, and other protected IT resources based on roles and responsibilities.
Veto controls
- Policy-as-code with least privilege: Policies define the minimum set of tools and arguments each agent needs. Adding new permissions requires a code change with review.
- Role-based policies: Different agent roles (finance, support, research) have different policy sets. A support agent cannot access financial tools.
- Access modification history: Every policy change is version-controlled in git. The commit history shows who changed what, when, and why.
Operating evidence
Git log showing policy change history with author, date, and diff. Policy files showing role-based separation. Review-queue screenshots showing per-role tool access configuration.
Detection of unauthorized or anomalous activity
To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations, infrastructure, and operations that could indicate security events.
Veto controls
- Decision records: Each governed tool call is recorded with outcome (allow, deny, or approval). Denied actions are flagged for review.
- Anomaly visibility: Decision views show patterns: spike in denied actions, unusual tool call sequences, high-frequency access to sensitive tools.
- Policy violation alerting: Configurable alerts when agents attempt unauthorized actions, enabling rapid investigation and response.
Operating evidence
Decision record export showing denied actions with timestamps and context. Alert configuration showing notification rules. Review-queue screenshots showing monitoring views.
Incident response and recovery
The entity monitors system components and the operation of those components for anomalies indicative of malicious acts, natural disasters, and errors, and takes action when anomalies are identified.
Veto controls
- Policy response: When an incident is detected, teams can apply a policy change that restricts or halts governed agent behavior without redeploying application code.
- Forensic decision record: Decision records provide forensic evidence: exactly what the agent did, what policy matched, and what outcome was applied.
- Policy rollback: Git-based policy history enables rollback to any previous policy version if a policy change causes issues.
Operating evidence
Incident timeline reconstructed from decision records. Policy change history showing response actions. Git log showing policy rollback capability.
Change management
The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.
Veto controls
- Policy-as-code in version control: Every policy change goes through the same code review process as application code: pull requests, approvals, CI/CD.
- Environment promotion: Policies are tested in dev, validated in staging, and promoted to production through the standard deployment pipeline.
- Documentation by construction: YAML policies are self-documenting. The policy file is the documentation of what the agent is authorized to do.
Operating evidence
Pull request history showing policy reviews and approvals. CI pipeline logs showing policy validation. Environment configuration showing dev, staging, and prod separation.
Preparing for your SOC 2 audit
When your auditor asks about AI agent controls, here is the evidence package you can prepare from Veto:
Policy documentation
Export YAML policy files showing what each agent is authorized to do. Version-controlled with full change history.
Decision records
Export decision records for any time period. Shows each governed tool call, the policy that matched, and the outcome. Filterable by agent, tool, outcome, or date range.
Approval records
Export human approval history showing who approved what, when, and why. Demonstrates human oversight for sensitive operations.
Access control matrix
Decision view showing per-agent, per-tool access configuration. Screenshots showing role-based policy separation and environment scoping.
Frequently asked questions
Does SOC 2 specifically mention AI agents?
What is the difference between SOC 2 Type I and Type II for AI agents?
Can I export SOC 2 evidence directly from Veto?
How does Veto handle data residency for SOC 2?
What if my auditor has not encountered AI agent controls before?
Related evidence resources
When SOC 2 asks about agents, show the control and the evidence.