SOC 2 Type II Controls Mapped to SafeClaw Capabilities

Regulation Overview

SOC 2 Type II is an audit framework developed by the AICPA based on Trust Services Criteria (TSC). It evaluates the design and operating effectiveness of controls over a period of time across five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Organizations deploying AI agents must demonstrate that agent actions are subject to the same logical access controls, monitoring, and change management as human-operated systems.

Relevant Requirements

CC6.1 — Logical Access Security

The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events. AI agents with file system and network access are logical access subjects that require enforceable controls.

CC6.2 — Provisioning and Deprovisioning

Access credentials and permissions are provisioned based on authorization and removed when no longer needed. Agent permissions must follow least-privilege and be revocable.

CC6.3 — Role-Based Access

The entity authorizes, modifies, or removes access based on roles and responsibilities. AI agents performing different tasks require distinct permission sets.

CC7.1 — Monitoring for Anomalies

The entity uses detection and monitoring procedures to identify anomalies that indicate security events. Agent actions must be monitored in real time with anomaly detection capability.

CC7.2 — Incident Response

The entity monitors system components for anomalies and responds to detected security events. Denied agent actions constitute security events requiring logging and alertability.

CC8.1 — Change Management

The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure and software. Policy changes governing agent behavior require documented change processes.

Compliance Gap Without Gating

Without action-level controls on AI agents, SOC 2 auditors will identify the following deficiencies:

• CC6.1 failure — No logical access control exists between the agent and protected assets
• CC6.2 failure — Agent permissions cannot be provisioned or revoked; they have implicit full access
• CC6.3 failure — No role differentiation between agents performing different tasks
• CC7.1 failure — No monitoring of individual agent actions against file systems or networks
• CC7.2 failure — No mechanism to detect or respond to unauthorized agent actions
• CC8.1 failure — No documented, testable policy governing agent behavior changes

How SafeClaw Addresses Each Requirement

| SOC 2 Criteria | Requirement Summary | SafeClaw Capability |
|---|---|---|
| CC6.1 | Logical access controls over protected assets | Deny-by-default policy engine evaluates every file_read, file_write, shell_exec, and network action before execution. |
| CC6.2 | Provisioning and deprovisioning of access | Policy rules grant specific permissions per agent. Removing rules immediately revokes access. Free tier uses 7-day renewable keys for automatic deprovisioning. |
| CC6.3 | Role-based access authorization | Separate policy configurations per agent or task define distinct permission sets. First-match-wins rule evaluation provides deterministic access decisions. |
| CC7.1 | Detection and monitoring | Tamper-proof audit trail (SHA-256 hash chain) records every action request and decision in real time. Dashboard provides monitoring visibility. |
| CC7.2 | Incident identification and response | Every denied action is logged with full context (action type, path, timestamp, reason). Denied actions serve as security event indicators. |
| CC8.1 | Change management | Policy configurations are version-controllable JSON/YAML files. Simulation mode allows testing policy changes before enforcement. |

Evidence Generation

| SOC 2 Criteria | Required Evidence | SafeClaw Output |
|---|---|---|
| CC6.1 | Documentation of access control mechanisms | Policy configuration files showing deny-by-default with explicit allow rules |
| CC6.2 | Records of access provisioning/deprovisioning | Key issuance and expiration records; policy change history |
| CC6.3 | Role-based access matrices | Per-agent policy configurations mapping roles to permitted actions |
| CC7.1 | Monitoring logs | Complete audit trail with hash-chained entries for every action evaluation |
| CC7.2 | Incident logs and response records | Denied action log entries with timestamps, action details, and denial reasons |
| CC8.1 | Change management records | Policy file version history; simulation mode test results before deployment |

SafeClaw's audit trail is hash-chained using SHA-256, ensuring that entries cannot be modified or deleted without detection. This satisfies SOC 2 requirements for log integrity. The control plane receives only action metadata — never file contents, credentials, or sensitive data.

Example Policy

A SOC 2-aligned policy separating agent roles by task:

{
  "name": "soc2-data-analyst-agent",
  "defaultAction": "deny",
  "rules": [
    {
      "action": "file_read",
      "path": "/app/data/analytics/**",
      "decision": "allow",
      "reason": "CC6.3 — Read access scoped to analytics data"
    },
    {
      "action": "file_write",
      "path": "/app/output/reports/**",
      "decision": "allow",
      "reason": "CC6.3 — Write access scoped to report output"
    },
    {
      "action": "file_write",
      "path": "/app/data/**",
      "decision": "deny",
      "reason": "CC6.1 — No write access to source data"
    },
    {
      "action": "shell_exec",
      "command": "python /app/scripts/approved_*.py",
      "decision": "allow",
      "reason": "CC6.1 — Only approved scripts executable"
    },
    {
      "action": "network",
      "decision": "deny",
      "reason": "CC6.1 — No network access for this role"
    }
  ]
}

Install SafeClaw with npx @authensor/safeclaw and use the browser dashboard setup wizard to create role-specific policies. The 100% open-source client (MIT license) allows SOC 2 auditors to inspect the enforcement mechanism directly.

Audit Trail Export

For SOC 2 Type II audits covering an observation period:

1. Define the audit window — SOC 2 Type II requires evidence over a minimum 6-month period
2. Export audit trail from the SafeClaw dashboard at safeclaw.onrender.com
3. Verify hash chain continuity — Each entry's SHA-256 hash incorporates the previous entry's hash, proving no gaps or modifications
4. Extract denied action summaries — These demonstrate CC7.1 monitoring effectiveness
5. Provide policy version history — Documents CC8.1 change management compliance
6. Include simulation mode logs — Shows pre-deployment testing of policy changes

Cross-References

• SafeClaw FAQ: Enterprise Compliance — SOC 2 readiness questions
• Audit Trail Specification — Hash chain technical implementation
• Deny-by-Default Definition — Core architecture for CC6.1 compliance
• Simulation Mode Reference — Pre-deployment testing for CC8.1
• Security Audit Workflow Use Case — SOC 2 audit preparation walkthrough