GuardClaw and SOC 2: A Control Mapping
If you are working on running AI agents in production and guardclaw, this is for you.
Table of contents
Key takeaway
GuardClaw's receipt chain maps directly to SOC 2's audit logging controls. Tamper-evident by design, not by policy.
Key takeaway
Deny-by-default policies satisfy logical access controls. The evidence isn't a document saying you have policies, it's thousands of enforced decisions.
Key takeaway
Most SOC 2 auditors haven't seen AI agent controls yet. Show them the receipt chain. It's the strongest evidence you can produce.
Your auditor asks: “How do you control what your AI agents access?”
You have two options. You can show them a policy document that says “we only give agents minimum required access.” Or you can show them a cryptographically verified log of every action every agent took, every access decision that was made. Proof that nobody altered the record.
One is a promise. The other is evidence.
GuardClaw’s security controls map directly to several SOC 2 Trust Services Criteria. This post shows which controls align, what evidence to present, and how to prepare for the conversation with your auditor.
Quick primer: what SOC 2 requires
SOC 2 is organized around five Trust Services Criteria. The ones most relevant to AI agent security are:
- CC6, Logical and Physical Access Controls: How you control who (and what) can access your systems
- CC7, System Operations: How you monitor, detect, and respond to security events
- CC8, Change Management: How you manage changes to your infrastructure and software
Each criterion has specific controls. GuardClaw doesn’t cover all of SOC 2 (it’s a security tool, not a compliance platform). It directly addresses the controls that apply to automated agents acting on your systems.
The mapping
CC6.1, Logical Access Security
What the auditor asks: “How do you restrict access to information assets?”
What GuardClaw provides: Deny-by-default policy enforcement. Every agent action passes through the security gate. File system boundaries prevent access outside the project directory. Network boundaries restrict which domains the agent can reach. Shell command patterns block dangerous operations.
Evidence to show: Your guardclaw.yaml policy file (what’s allowed) plus the receipt chain filtered to denials (what was actually blocked). The denials prove the policy is enforced, not just written.
CC6.3, Access Based on Authorization
What the auditor asks: “How do you ensure only authorized actions are performed?”
What GuardClaw provides: Capability tokens. Even when a policy allows an action, the agent needs a cryptographic token to execute it. Tokens are single-use, time-bound, and scope-limited. A token for reading files can’t be used to run shell commands.
Evidence to show: Receipt chain entries showing capability token validation for each action. Failed token validations (expired, wrong scope) are logged as denials.
CC7.2, Monitoring of System Components
What the auditor asks: “How do you monitor your systems for anomalies?”
What GuardClaw provides: Real-time behavioral monitoring during supervised execution. Anomaly detection for rate spikes, unusual action sequences, and resource abuse. Every monitored event is logged in the receipt chain.
Evidence to show: Dashboard threat stats showing monitoring coverage. Receipt chain entries with anomaly scores. Alert history (if configured).
CC7.3, Evaluation of Security Events
What the auditor asks: “How do you evaluate whether detected events represent actual security incidents?”
What GuardClaw provides: OWASP ASI category classification for every detected threat. Each denial includes the specific attack category, severity score, and the detection tier that caught it. The audit trail distinguishes between true threats and false positives through policy adjustments over time.
Evidence to show: Dashboard audit trail filtered by severity. Attack simulation reports showing detection coverage by OWASP category.
CC7.4, Incident Response
What the auditor asks: “How do you respond to identified security incidents?”
What GuardClaw provides: Automatic blocking of detected threats (the deny action). Fatal receipt handling that can terminate an agent session when critical threats are detected. Human-in-the-loop approval for high-risk actions (configurable).
Evidence to show: Receipt chain entries showing deny decisions with enforcement actions. Fatal termination events for critical threats.
CC8.1, Change Management
What the auditor asks: “How do you manage changes to security controls?”
What GuardClaw provides: Policy files are YAML, versionable with git. Policy changes create a new version in your repository with full commit history. The receipt chain shows when policy changes took effect (new enforcement patterns appear at specific timestamps).
Evidence to show: Git history of your guardclaw.yaml file. Receipt chain timestamps showing before/after enforcement changes.
The conversation with your auditor
Most SOC 2 auditors haven’t evaluated AI agent security controls before. This is new territory for everyone. Here’s how to frame the conversation:
Start with the problem: “We use AI agents that interact with our systems, reading code, running commands, calling APIs. These agents need the same access controls and monitoring that human operators get.”
Show the controls: Walk through the mapping above. For each control, show the policy (what you configured) and the evidence (what actually happened).
Lead with the receipt chain: This is your strongest evidence. The receipt chain is a cryptographically linked chain where any tampering is mathematically detectable, unlike a log that someone could have edited. Most audit log controls require “integrity of logs.” The receipt chain exceeds that requirement.
Be honest about scope: GuardClaw covers agent access controls, monitoring, and audit logging. It doesn’t cover your network security, physical access, HR policies, or vendor management. It’s one control in a broader framework.
What to prepare
Before your SOC 2 audit, gather these artifacts from GuardClaw:
- Policy file (
guardclaw.yaml), your current security configuration - Attack simulation report (
guardclaw test --audit --attack), your detection coverage - Receipt chain export, your audit trail for the review period
- Dashboard screenshots, threat stats and compliance mapping
- Git history — version history of policy changes
The dashboard’s compliance tab pre-maps some of this for you, but having the raw artifacts ready makes the conversation faster.
Next post: the same mapping exercise for GDPR — what applies when your agents process data covered by European privacy regulations.
30-second skim
GuardClaw and SOC 2: A Control Mapping
Map GuardClaw security controls to SOC 2 criteria, including what evidence to show your auditor.
- GuardClaw's receipt chain maps directly to SOC 2's audit logging controls. Tamper-evident by design, not by policy.
- Deny-by-default policies satisfy logical access controls. The evidence isn't a document saying you have policies, it's thousands of enforced decisions.
- Most SOC 2 auditors haven't seen AI agent controls yet. Show them the receipt chain. It's the strongest evidence you can produce.
Two-minute summary
Section headings with the first sentence from each. Built from the full post.
- Building summary...
Cite this post
Take Interest Inc. (2026). GuardClaw and SOC 2: A Control Mapping. TAKE INTEREST. https://takeinterest.ai/blog/guardclaw-and-soc2
Take it with you
Save the link to come back to it, or pass it along.
Related interests
Your Security Dashboard
The GuardClaw dashboard shows threat stats, audit trails, and compliance alignment in one place. Here's how to read it and what the numbers mean.
GuardClaw and GDPR: What Maps Where
When your AI agent processes personal data, GDPR applies. Here's how GuardClaw's controls map to the requirements that matter most.
GuardClaw and the EU AI Act
What the EU AI Act's August 2026 enforcement date means for AI agent deployments and GuardClaw controls.