SOC 2 auditors don't care that your agent uses GPT-4. They care about access controls, audit trails, and change management. When your AI agent handles financial transactions, these requirements don't disappear—they intensify.
This guide explains how to maintain SOC 2 compliance while deploying autonomous AI agents, with specific technical implementations.
SOC 2 and AI Agents: The Core Tension
SOC 2 Trust Service Criteria were designed for human-operated systems. The five criteria—Security, Availability, Processing Integrity, Confidentiality, and Privacy—assume a human is making decisions.
AI agents break this assumption. An autonomous agent:
- Makes decisions without human approval
- Operates at machine speed (thousands of transactions/hour)
- Can execute actions the developer didn't explicitly anticipate
- Generates audit events faster than humans can review
The question isn't whether SOC 2 applies to AI agents. It does. The question is how to satisfy the controls when the "user" is a machine.
The Five Trust Criteria Applied to AI Agents
1. Security (CC Series)
SOC 2 Requirement: Logical and physical access controls protect against unauthorised access.
For AI Agents:
| Control | Human Systems | AI Agent Systems |
|---|---|---|
| Authentication | Username/password, MFA | API keys, service accounts |
| Authorisation | Role-based access | Policy-based limits |
| Access reviews | Quarterly user reviews | Continuous policy monitoring |
| Privileged access | Admin accounts | Agent wallet permissions |
PolicyLayer Implementation:
// Each agent has scoped credentials
const agent = new PolicyWallet(adapter, {
apiKey: process.env.AGENT_API_KEY, // Scoped to this agent
metadata: {
orgId: 'production',
agentId: 'refund-processor', // Unique identifier
environment: 'production'
}
});
// Policy enforces least-privilege access
const policy = {
perTransactionLimit: '1000000000', // $1,000 max per transaction
dailyLimit: '50000000000', // $50,000 daily cap
recipientWhitelist: ['0x...customer-refund-addresses'],
allowedAssets: ['usdc'] // Only USDC, no ETH
};
Audit evidence: API key rotation logs, policy version history, agent-to-policy mapping.
2. Availability (A Series)
SOC 2 Requirement: Systems are available for operation as committed.
For AI Agents:
The agent's availability depends on:
- Your infrastructure (agent runtime)
- Policy enforcement service (PolicyLayer API)
- Blockchain network (execution)
Availability architecture:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Agent │────▶│ PolicyLayer │────▶│ Blockchain │
│ (Your SLA) │ │ (99.9%) │ │ (varies) │
└─────────────┘ └─────────────┘ └─────────────┘
PolicyLayer provides:
- 99.9% API availability SLA
- Health check endpoints for monitoring
- Graceful degradation (fail-closed)
For auditors: Document the availability chain and SLAs for each component.
3. Processing Integrity (PI Series)
SOC 2 Requirement: System processing is complete, valid, accurate, timely, and authorised.
This is where AI agents face the most scrutiny. An LLM can hallucinate. How do you prove processing integrity when the processor is non-deterministic?
The answer: Separate intent from execution.
┌─────────────────────────────────────────────────────────────────┐
│ NON-DETERMINISTIC │
│ LLM decides: "Send $50 to Alice for refund #1234" │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ DETERMINISTIC │
│ PolicyLayer validates: Is $50 within limits? Is Alice on │
│ whitelist? Is this agent authorised for USDC? │
│ │
│ Fingerprint: sha256({to: Alice, amount: 50, asset: usdc}) │
│ Decision: ALLOW | DENY with reason code │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ TAMPER-EVIDENT │
│ Gate 2 verifies fingerprint matches approved intent │
│ Any modification detected → Transaction rejected │
└─────────────────────────────────────────────────────────────────┘
For auditors: The LLM's decision is irrelevant to processing integrity. What matters is that the executed transaction matches the validated intent.
4. Confidentiality (C Series)
SOC 2 Requirement: Information designated as confidential is protected.
For AI Agents:
| Confidential Data | Protection Method |
|---|---|
| Private keys | Never transmitted; PolicyLayer never sees keys |
| API keys | Encrypted at rest, rotated quarterly |
| Transaction data | Encrypted in transit (TLS 1.3) |
| Audit logs | Encrypted, access-controlled |
PolicyLayer's non-custodial architecture is a confidentiality control:
// Private key NEVER leaves your infrastructure
const privateKey = process.env.WALLET_PRIVATE_KEY;
const adapter = await createEthersAdapter(privateKey, rpcUrl);
// PolicyLayer only sees intent metadata, not keys
const wallet = new PolicyWallet(adapter, {
apiKey: process.env.POLICYLAYER_API_KEY,
metadata: { orgId: 'prod', agentId: 'agent-1' }
});
// Transaction signing happens locally
await wallet.send({ to, amount, asset });
// ↳ Signs with local key after policy approval
5. Privacy (P Series)
SOC 2 Requirement: Personal information is collected, used, retained, and disclosed in accordance with commitments.
For AI Agents handling payments:
- Transaction recipients may be PII
- Payment amounts may reveal personal information
- Audit logs must balance compliance with privacy
Implementation:
// Pseudonymise where possible
const auditEntry = {
timestamp: new Date().toISOString(),
agentId: 'refund-processor',
decision: 'ALLOW',
amount: '50.00',
asset: 'USDC',
recipientHash: sha256(recipientAddress), // Not raw address
policyVersion: 'v2.3.1'
};
Building the Audit Trail
SOC 2 auditors need evidence. For AI agents, this means comprehensive logging of every decision.
PolicyLayer audit events include:
{
"eventId": "evt_abc123",
"timestamp": "2025-12-10T14:32:01.234Z",
"eventType": "policy_decision",
"orgId": "org_xyz",
"agentId": "refund-processor",
"decision": "ALLOW",
"intent": {
"chain": "ethereum",
"asset": "usdc",
"to": "0x...",
"amount": "50000000",
"fingerprint": "sha256:abc..."
},
"policy": {
"id": "pol_123",
"version": "v2.3.1",
"limits": {
"perTransaction": "1000000000",
"daily": "50000000000"
}
},
"counters": {
"spentToday": "450000000",
"remainingDaily": "49550000000"
},
"metadata": {
"requestId": "req_xyz",
"sourceIp": "10.0.0.1"
}
}
For each transaction, you can prove:
- What was requested (intent)
- What policy was applied (version-controlled)
- What limits existed at decision time
- What the decision was and why
- Cryptographic proof of intent integrity
Control Mapping
Here's how PolicyLayer maps to specific SOC 2 controls:
| SOC 2 Control | PolicyLayer Feature |
|---|---|
| CC6.1 (Logical access) | API key authentication, policy-based authorisation |
| CC6.2 (Access provisioning) | Agent onboarding with scoped policies |
| CC6.3 (Access removal) | API key revocation, kill switch |
| CC7.2 (Security monitoring) | Real-time audit stream, anomaly detection |
| CC8.1 (Change management) | Policy versioning, deployment audit trail |
| PI1.1 (Processing integrity) | Two-gate enforcement, intent fingerprinting |
| PI1.4 (Error handling) | Fail-closed design, rejection reason codes |
Implementation Checklist
Before your SOC 2 audit, ensure:
Access Controls:
- [ ] Each agent has unique API credentials
- [ ] Credentials are rotated on schedule (quarterly minimum)
- [ ] Policies follow least-privilege principle
- [ ] Kill switch tested and documented
Audit Trail:
- [ ] All policy decisions logged with full context
- [ ] Logs are immutable and retained per policy
- [ ] Log access is controlled and audited
- [ ] Cryptographic integrity of audit records
Change Management:
- [ ] Policy changes are version-controlled
- [ ] Changes require approval workflow
- [ ] Deployment history is maintained
- [ ] Rollback procedures are documented
Monitoring:
- [ ] Real-time alerts for policy violations
- [ ] Dashboard for spending patterns
- [ ] Anomaly detection configured
- [ ] Incident response procedures documented
Sample Auditor Questions
Q: How do you ensure AI agents don't exceed authorised access?
A: Agents authenticate with scoped API keys. Each key is bound to a policy that enforces transaction limits, recipient whitelists, and asset restrictions. Limits are enforced deterministically—the agent cannot bypass them.
Q: How do you maintain audit trails for autonomous decisions?
A: Every policy decision is logged with the intent, applied policy version, counters at decision time, and cryptographic fingerprint. Logs are append-only and retained for [X years].
Q: What happens if an agent is compromised?
A: The kill switch instantly disables all transactions for that agent. Maximum exposure is bounded by the policy limits—even a compromised agent cannot exceed daily caps.
Q: How do you ensure processing integrity when using AI?
A: The AI generates intent; PolicyLayer validates and executes. Intent fingerprinting ensures the executed transaction matches exactly what was approved. Any tampering between approval and execution is detected and rejected.
Related Reading
- Two-Gate Enforcement Explained — The architecture behind processing integrity
- The Kill Switch — Incident response for AI agents
- Audit Logging Deep Dive — Complete logging documentation
Ready to deploy compliant AI agents?
- Quick Start Guide — Production-ready in 5 minutes
- Enterprise Contact — Discuss compliance requirements
- GitHub — Open source SDK
Top comments (0)