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 Double Ratchet with XChaCha20-Poly1305. Server never possesses decryption keys. | Encryption/decryption occurs exclusively in client-side packages/crypto/ library. |
| C1.3 — Disposal of confidential information | Forward secrecy via Double Ratchet key deletion. Old message keys are destroyed after decryption. | 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 Double Ratchet. Key deletion after decryption. 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. |
