SOC 2
How does Areev map to CC6 (Logical and Physical Access)?
Areev implements logical access controls through AES-256-GCM encryption at rest, Zanzibar-style authorization tuples, and HMAC-SHA256 blind index tokens. This context database restricts who can access AI memory data and how it is stored, mapping to CC6.1 (access controls) and CC6.3 (monitoring access).
For CC6.1, all endpoints require API key or JWT authentication, Zanzibar authorization tuples enforce subject-permission-resource checks, per-user encryption keys isolate each user’s DEK, and blind index tokens prevent plaintext exposure in indexes. For CC6.3, every access denial produces an AccessDenied audit event with the requesting principal, required permission, and target resource. The ComplianceMonitor detects anomalous access patterns in this autonomous memory system without requiring additional configuration.
import requests
# Check access control status
resp = requests.post("http://localhost:4009/api/memories/default/verify/run")
checks = resp.json()
# Includes soc2_logical_access and soc2_segregation_duties check results
POST /api/memories/default/verify/run HTTP/1.1
Host: localhost:4009
areev verify --filter soc2
How does Areev map to CC7 (System Operations)?
Areev’s hash-chained audit trail satisfies CC7.2 (monitoring) by recording every state-changing operation across 97 event types (37 base + 33 distributed + 11 auth + 4 import + 4 HTTP + 3 hooks + 3 chat + 1 CAL + 1 LLM-rerank). The ComplianceMonitor provides real-time violation detection for CC7.3 (incident detection) in this AI agent memory system.
For CC7.2, the hash chain prevents tampering or deletion of audit records, pseudonymized actor IDs maintain privacy, and time-range queries support investigation workflows. For CC7.3, the monitor detects excessive forget rates (possible data destruction attacks), policy violations, and deep supersession chain warnings, assigning severity levels (Info, Warning, Critical) to each detected issue. The audit chain is independently verifiable via verify_chain(), which recomputes every hash and checks chain links. Failed verification produces an AuditChainBroken error with the sequence number and expected vs actual hashes.
CC7.2 — Monitoring:
- 97 audit event types covering all operations
- Hash chain prevents tampering or deletion
- Pseudonymized actor IDs for privacy
- Time-range queries for investigation
CC7.3 — Incident detection:
- Excessive forget rate detection
- Policy violation alerts
- Deep supersession chain warnings
- Severity levels: Info, Warning, Critical
How does Areev map to CC8 (Change Management)?
Areev’s policy lifecycle system provides change management controls through sealed policies with upgrade/downgrade audit events, satisfying CC8.1. Every policy change in this context database is recorded with the actor, affected policies, and configuration hash.
PolicySealed records the initial policies at database creation. PolicyUpgraded records the addition of stricter policies (no reason required). PolicyDowngraded records the removal of policies and requires an explicit reason string, which persists in the audit trail for SOC 2 auditors. The configuration hash (SHA-256 of the policy state) enables point-in-time verification that the AI memory governance rules have not been silently altered.
# Upgrade: add policy (CC8.1 change event)
areev modify --add-policy hipaa
# Downgrade: remove policy (requires reason for CC8.1 audit)
areev modify --remove-policy hipaa --reason "Discontinued healthcare use case"
What SOC 2-specific compliance checks does Areev run?
Areev includes 6 SOC 2-specific compliance verification checks that map to Trust Service Criteria. These complement the core checks and are evaluated when the autonomous memory system runs areev verify.
Each check targets a specific TSC control area, covering change management, recovery, segregation of duties, logical access, availability, and incident response.
| Check ID | TSC | Description |
|---|---|---|
soc2_change_management | CC8.1 | CC8.1 change management via hash-chained audit trail |
soc2_recovery_testing | A1.2 | A1.2 recovery via content-addressed immutable storage |
soc2_segregation_duties | CC6.1 | CC6.1 segregation via per-user key isolation |
soc2_logical_access | CC6.2 | CC6.2 logical access via encryption and key management |
soc2_availability | A1.1 | A1.1 availability via embedded engine (no external dependencies) |
soc2_incident_response | CC7.3 | Incident response supported by audit trail and chain verification |
Related
- Audit Trail: Hash-chained audit log details
- Encryption: CC6 encryption controls
- Policy: CC8 policy lifecycle management
- Compliance: Full compliance verification overview