What is SOC 2 Compliance?
SOC 2 is a compliance framework developed by the AICPA for service organisations, focused on five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. AI agents handling customer data must operate within SOC 2 controls.
WHY IT MATTERS
SOC 2 is the de facto compliance standard for SaaS companies and service organisations. If your company stores, processes, or transmits customer data, your enterprise customers will ask for your SOC 2 report. It demonstrates that you have controls in place to protect their data — and that those controls actually work.
AI agents create new SOC 2 challenges across every trust service criterion. Security (CC6): agents need access controls that prevent unauthorised tool use. Availability (A1): agent operations must not compromise system uptime. Processing integrity (PI1): agents must produce accurate, complete outputs. Confidentiality (C1): agents must not expose confidential data through tool calls. Privacy (P1): agents processing personal information must respect privacy commitments.
The critical SOC 2 requirement for AI agents is logical access controls (CC6.1–CC6.3). Every agent must have defined access boundaries, and those boundaries must be enforced — not suggested. An auditor will ask: 'What prevents this agent from accessing data outside its scope?' The answer cannot be 'we told the LLM not to.' It must be a technical control with evidence of enforcement.
SOC 2 also requires monitoring and logging (CC7). Every agent action that touches customer data needs an audit trail — what was accessed, when, by which agent, and whether the action was permitted by policy. This is not optional for Type II reports, which evaluate controls over a period of time.
HOW POLICYLAYER USES THIS
Intercept directly addresses SOC 2 control requirements for AI agent operations. YAML policies enforce logical access controls (CC6) by restricting which tools each agent can call and what arguments are permitted. Every tool call decision is logged with full context — tool name, arguments, policy evaluation result, and timestamp — satisfying CC7 monitoring requirements. Because policies are version-controlled in git, changes to access controls are tracked and reviewable, supporting CC8 change management requirements.