SOC 2 Compliance for AI Agents
Your SOC 2 auditor is going to ask how you control AI agent access. Here's the answer: trust service criteria mapped to runtime authorization, with audit evidence your auditor will understand.
Last updated: April 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, every tool call those agents make falls within the scope of your SOC 2 audit. Without runtime authorization, you have a gap your auditor will find.
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: non-deterministic, autonomous, and potentially operating 24/7 without human supervision. Your existing access controls may cover who can log in, but they don't cover what an AI agent decides to do once it has access.
Auditors are starting to ask specific questions: How do you control what AI agents can do? How do you log AI agent actions? Who approves agent access to sensitive data? If you don't have answers backed by evidence, you have a finding.
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. Cross-tenant access is architecturally prevented.
- Environment isolation: Dev, staging, and production environments have separate policy sets. An agent authorized in dev is not automatically authorized in production.
Audit evidence
Export the policy YAML file showing allowed tools per agent. Export the decision log 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 audit trail: Every policy change is version-controlled in git. The commit history shows who changed what, when, and why.
Audit evidence
Git log showing policy change history with author, date, and diff. Policy files showing role-based separation. Dashboard 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
- Real-time decision logging: Every tool call is logged with outcome (allow/deny/approval). Denied actions are flagged for review.
- Anomaly visibility: Dashboard shows 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.
Audit evidence
Decision log export showing denied actions with timestamps and context. Alert configuration showing notification rules. Dashboard 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
- Immediate policy enforcement: When an incident is detected, policies can be updated in real-time to restrict or halt agent behavior without redeploying application code.
- Forensic audit trail: Decision logs provide complete 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.
Audit evidence
Incident timeline reconstructed from decision logs. 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.
Audit evidence
Pull request history showing policy reviews and approvals. CI pipeline logs showing policy validation. Environment configuration showing dev/staging/prod separation.
Preparing for your SOC 2 audit
When your auditor asks about AI agent controls, here's 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 logs
Export decision logs for any time period. Shows every 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
Dashboard 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's the difference between SOC 2 Type I and Type II for AI agents?
Can I export audit evidence directly from Veto?
How does Veto handle data residency for SOC 2?
What if my auditor hasn't encountered AI agent controls before?
Related compliance resources
Your auditor is going to ask about AI agents. Have the answer ready.