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.
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 all tables: USING (tenant_id = current_setting('app.current_tenant_id')::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
| 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. |
| 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. |
| 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. |
