> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentvault.chat/llms.txt
> Use this file to discover all available pages before exploring further.
# Compliance Mapping
> How AgentVault maps to SOC 2 and ISO 27001 compliance frameworks.
AgentVault's architecture is designed with compliance in mind from day one. This document
maps AgentVault's security controls to **SOC 2 Trust Service Criteria** and
**ISO 27001 Annex A** controls, providing a reference for auditors and enterprise
security teams.
AgentVault is not yet SOC 2 or ISO 27001 certified. This mapping documents how
the platform's architecture and controls align with these frameworks and identifies
the path to formal certification.
***
## SOC 2 Trust Service Criteria Mapping
### CC1 -- Security (Common Criteria)
The security principle addresses protection of system resources against unauthorized access.
| Criteria | AgentVault Control | Evidence |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| CC6.1 -- Logical access security | Row-Level Security (RLS) enforces tenant isolation at the database layer. Every query is scoped to `tenant_id`. | RLS policy on every tenant-scoped table: `USING (tenant_id = NULLIF(current_setting('app.current_tenant_id', true), '')::uuid)` |
| CC6.2 -- Access authentication | Clerk JWT authentication on all API endpoints. WebSocket connections require JWT in query parameter. | FastAPI middleware validates JWT on every request. |
| CC6.3 -- Access authorization | 4-tier RBAC model (Owner Admin, Tenant Admin, Member, Agent). Enrollment requires explicit admin approval. | Role checks enforced at API layer. Admin-only enrollment approval workflow. |
| CC6.6 -- System boundary protection | API rate limiting: enrollment 5/IP/10min, polling 1/5sec, messaging 60/min. | FastAPI rate limiting middleware with Redis-backed counters. |
| CC6.7 -- Restriction of information | Generic error messages on auth/enrollment failures prevent information leakage. | No stack traces or internal details exposed in API responses. |
| CC6.8 -- Prevention of unauthorized changes | Device revocation triggers immediate WebSocket disconnection. Revoked devices cannot send or receive messages. | Device status checked on every authenticated action. |
### CC2 -- Confidentiality
The confidentiality principle addresses protection of information designated as confidential.
| Criteria | AgentVault Control | Evidence |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| C1.1 -- Identification of confidential information | All message content classified as confidential. Stored as `BYTEA` ciphertext only. | No plaintext columns in the `messages` table. |
| C1.2 -- Protection of confidential information | End-to-end encryption using MLS (RFC 9420) as primary protocol with Double Ratchet fallback. XChaCha20-Poly1305 AEAD. Server never possesses decryption keys. | Encryption/decryption occurs exclusively in client-side `packages/crypto/` library. |
| C1.3 -- Disposal of confidential information | Forward secrecy via MLS epoch advancement and Double Ratchet key deletion. Old epoch secrets and message keys are destroyed after use. | MLS epoch advances on Commit. Ratchet state advances per message. Key material deleted post-decrypt. |
### CC3 -- Availability
The availability principle addresses whether the system is available for operation and use.
| Criteria | AgentVault Control | Evidence |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| A1.1 -- System availability commitments | Real-time message delivery via WebSocket with HTTP polling fallback. | Wake detector + 15-second pending-message poll ensures delivery. |
| A1.2 -- System recovery | Managed PostgreSQL and Redis with built-in redundancy. Stateless backend enables horizontal scaling. | DigitalOcean managed database services with automatic failover. |
### CC4 -- Processing Integrity
The processing integrity principle addresses whether system processing is complete, valid, and authorized.
| Criteria | AgentVault Control | Evidence |
| ----------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| PI1.1 -- Complete and accurate processing | Cryptographic authentication (Poly1305 MAC) on all messages. Tampered messages are rejected. | AEAD construction ensures both confidentiality and integrity. |
| PI1.2 -- Validation of inputs | Pydantic v2 schema validation on all API inputs. Type-safe request/response models. | FastAPI + Pydantic enforce strict input validation. |
***
## ISO 27001 Annex A Mapping
### A.5 -- Information Security Policies
| Control | AgentVault Implementation |
| ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| A.5.1 -- Management direction for information security | Security architecture documented in threat model and system security plan. Zero-knowledge design principle enforced across all features. |
### A.6 -- Organization of Information Security
| Control | AgentVault Implementation |
| ------------------------------ | --------------------------------------------------------------------------------------------------- |
| A.6.1 -- Internal organization | Defined security roles: Security Officer, Engineering Lead, DevSecOps Lead, Incident Response Lead. |
### A.8 -- Asset Management
| Control | AgentVault Implementation |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| A.8.1 -- Responsibility for assets | High-value assets identified in threat model: message plaintext, device private keys, group secrets, membership graph, invite tokens. |
| A.8.2 -- Information classification | All message content classified as confidential. Cryptographic material classified as restricted. |
### A.9 -- Access Control
| Control | AgentVault Implementation |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| A.9.1 -- Business requirements of access control | Invite-only enrollment. No self-registration. Admin approval required for all new devices. |
| A.9.2 -- User access management | 4-tier RBAC: Owner Admin, Tenant Admin, Member, Agent. Role-based permission enforcement at API layer. |
| A.9.4 -- System and application access control | RLS at database layer. JWT authentication at API layer. Device-bound Ed25519 identity keys. |
### A.10 -- Cryptography
| Control | AgentVault Implementation |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A.10.1 -- Cryptographic controls | Modern cryptographic primitives: X25519 (key exchange), Ed25519 (signatures), XChaCha20-Poly1305 (AEAD), BLAKE2b (hashing). All provided by libsodium. |
| A.10.2 -- Key management | Device-bound key generation. Forward secrecy via MLS epoch advancement and Double Ratchet (fallback). Key deletion after use. BLAKE2b hashing for invite tokens. |
### A.12 -- Operations Security
| Control | AgentVault Implementation |
| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| A.12.1 -- Operational procedures | Docker-based deployment with reproducible builds. Alembic migrations for database changes. |
| A.12.4 -- Logging and monitoring | Audit logs for admin actions. No plaintext in any log output. OTel-shaped telemetry pipeline for operational observability. |
| A.12.6 -- Technical vulnerability management | Rate limiting on enrollment endpoints (5/IP/10min). No debug logging in production. Dependency scanning. |
### A.13 -- Communications Security
| Control | AgentVault Implementation |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| A.13.1 -- Network security management | TLS 1.3 for all API and WebSocket connections via Cloudflare. Backend accessible only through reverse proxy. |
| A.13.2 -- Information transfer | End-to-end encryption for all message content. Push notifications contain no message content. |
### A.16 -- Information Security Incident Management
| Control | AgentVault Implementation |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| A.16.1 -- Management of incidents | Device revocation workflow with immediate WebSocket disconnection. Rekey procedures for compromised sessions. |
The ISO 27001 mapping above covers architectural controls. Organizational controls
(policies, training, HR security) require additional documentation beyond the scope
of this technical mapping.
***
## Compliance Readiness Summary
| Framework | Status | Notes |
| -------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------- |
| **SOC 2 Type I** | Architecture aligned | Technical controls in place. Requires formal audit engagement. |
| **SOC 2 Type II** | Roadmap | Requires 6-12 month observation period after Type I. |
| **ISO 27001** | Architecture aligned | Annex A controls mapped. ISMS documentation required for certification. |
| **NIST Cybersecurity Framework** | Partial alignment | Identify, Protect, Detect functions addressed. Respond and Recover require further documentation. |
***
## Gap Analysis
The following items are identified as gaps requiring attention before formal certification:
| Gap | Framework | Remediation |
| --------------------------- | ----------------------------- | --------------------------------------------------------------------------- |
| Formal ISMS documentation | ISO 27001 | Draft and approve information security management system documentation. |
| Business continuity plan | SOC 2 (A1), ISO 27001 (A.17) | Document disaster recovery and business continuity procedures. |
| Security awareness training | ISO 27001 (A.7) | Implement security training program for all team members. |
| Formal change management | SOC 2 (CC8), ISO 27001 (A.12) | Document change management procedures beyond git-based workflow. |
| Third-party risk management | SOC 2 (CC9), ISO 27001 (A.15) | Formal assessment of Clerk, DigitalOcean, and Cloudflare security postures. |