SOC 2 CC6.1 compliance evidence
SOC 2 access control and audit evidence for AI interactions.
Summary
SOC 2 CC6.1 requires implementation of logical access controls to protect information assets. When AI agents act on behalf of users, each agent is effectively a non-human identity that requires the same access-control rigor as a human user. membrAIn provides the per-agent identity, scope, and audit framework required to satisfy CC6.1 for AI interactions.
Who this applies to
- SaaS vendors selling to enterprise customers requiring SOC 2 evidence
- Organizations seeking SOC 2 Type II attestation that includes AI systems
- Vendors whose customers ask 'how do you control AI agent access?'
Requirement-by-requirement mapping
Logical Access — Controls and Authentication
The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
Gateway-enforced authentication on every AI request via per-agent API keys with explicit scope. Unauthenticated requests are rejected at the edge before reaching any AI provider. Keys can be revoked or rotated without code changes in customer applications.
Evidence: /demo →Identification and Authentication of Users
The entity uses encryption or other equivalent security techniques to protect user authentication credentials and authentication information transmitted over open networks.
API keys transmitted via Authorization Bearer header over TLS 1.3. Keys are never logged in plaintext; audit records store the key ID hash, not the secret. Key material is stored in Cloudflare Workers Secrets, not in code or database.
Evidence: /security →Access Authorization
Access is authorized based on the principle of least privilege and segregation of duties.
Each agent key is scoped to specific AI providers, model lists, and rate limits. Trust policies enforce that an engineering agent cannot send prompts to a finance-restricted model, even if the API call is otherwise well-formed.
Evidence: /demo →Detection of Anomalies (companion criterion)
To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
Behavioral anomaly detection establishes a 7-day rolling baseline per agent. Deviations from baseline (call volume, model selection, prompt patterns, response sizes) trigger alerts. The system detects 'agent behaving differently than yesterday' patterns that signature-based controls miss.
Evidence: /test-suite.html#behavioral-anomaly →New Access Credentials and Authorization
Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users.
Agent enrollment is a controlled provisioning process. Each agent key is issued by an authenticated account owner via the portal or admin API. Every enrollment event is logged to the audit chain with the issuing account, timestamp, scope, and budget parameters. MSP administrators can provision client organizations in 30 seconds and control which agent keys exist within each org from the Command Center. Revocation is immediate and propagates to the gateway within one KV read cycle.
Evidence: /demo →Role-Based Access and Least Privilege
The entity removes access to protected information assets when appropriate and implements a role-based model for access authorization.
Five-level RBAC is enforced at the API layer: owner, msp_admin, admin, member, viewer. Each role has explicit permission boundaries enforced in every API route before any data access. Viewer-role users cannot create or modify agents, policies, or configuration — they can only read audit data. Agent keys carry scope fields that limit which operations they can perform. Budget caps provide an additional hard boundary on AI usage volume per agent.
Evidence: /demo →Logical Access Security Measures for External-Facing Components
The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
The gateway runs at Cloudflare's global edge — all external traffic is processed through Cloudflare's DDoS protection, WAF, and rate limiting before reaching the Worker. API key authentication is enforced on every request: SHA-256 hash of the agent key is validated against AGENT_KV before any processing begins. Scanner bypass endpoints are protected by a separate MEMBRAIN_ADMIN_SECRET that is never exposed to external users. Global rate limiting prevents abuse.
Evidence: /test-suite.html →Transmission Integrity and Confidentiality
The entity restricts the transmission and movement of information to authorized users and processes, and protects it during transmission.
All data in transit is protected by TLS 1.3 minimum. DLP-detected sensitive content is blocked at the gateway layer before transmission to any third-party LLM provider — sensitive data never reaches upstream services. Response DLP scans outbound model responses for credential leakage before returning to the client. Ed25519 signatures on every audit event provide cryptographic proof that transmitted event data was not modified between production and storage.
Evidence: /test-suite.html#audit-chain-verification →Prevention of Unauthorized or Malicious Software
The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.
The threat detection engine evaluates 294 adversarial signals across 10 attack categories on every AI request. Prompt injection, jailbreak, persona hijack, system prompt exfiltration, data poisoning, and indirect injection categories all represent classes of malicious instruction that could subvert AI behavior analogously to malicious software. Detection fires before the LLM processes the payload. Detected threats trigger agent quarantine in KV, blocking all subsequent requests from the compromised agent until an admin reviews and releases.
Evidence: /test-suite.html →Security Event Analysis and Response
The entity monitors system components and the operation of controls to detect security events, and evaluates security events to determine if they represent security incidents.
The SIEM webhook system delivers DLP violations, threat detections, and behavioral anomalies to customer SIEM platforms (Splunk, Datadog, Microsoft Sentinel) in real time. The Custom Alert Builder in the portal allows customers to define threshold-based alerts on any detection category. Behavioral anomaly detection establishes per-user baselines and fires on usage spikes or abnormal patterns. The Continuous Red Team add-on runs daily adversarial scans and alerts on any regression in detection coverage.
Evidence: /demo →What membrAIn does NOT cover
Honesty matters for procurement evaluation. These are explicit gaps where SOC 2 CC6.1 requirements fall outside our scope or require complementary controls.
- membrAIn provides controls and evidence; the SOC 2 attestation itself is performed by your independent auditor. We provide a control inventory mapping to CC6.1, CC7.1, and CC8.1 on request.
- Physical access controls (CC6.4) and personnel controls (CC1.4) are organizational requirements outside membrAIn's scope.