Skip to main content
This FAQ addresses the most common security questions we receive from CISOs, security architects, and enterprise procurement teams evaluating AgentVault for their organizations.
For detailed technical documentation, see the Security Claims & Assurance, Compliance Mapping, and System Security Plan pages.

​
Encryption & Data Protection

No. AgentVault is a zero-knowledge platform. All messages are encrypted client-side using the Double Ratchet protocol with XChaCha20-Poly1305 before they reach the server. The backend stores and relays ciphertext only. Decryption keys are generated and stored exclusively on client devices — they never leave the device and are never transmitted to the server.This is an architectural guarantee, not a policy decision. The server literally does not possess the keys needed to decrypt any message.
An attacker who gains full access to the database would obtain:
  • Encrypted message blobs (BYTEA ciphertext) that cannot be decrypted without client-side keys
  • BLAKE2b hashes of invite tokens (not the raw tokens)
  • Public keys of enrolled devices (which are, by definition, public)
  • Metadata such as tenant names, device fingerprints, and timestamps
They would not obtain:
  • Any plaintext message content
  • Any private keys or decryption keys
  • Any raw invite tokens
The encryption keys required to decrypt messages exist only on the owner’s and agent’s devices. A database breach does not compromise message confidentiality.
AgentVault uses modern, well-audited cryptographic primitives provided by libsodium:
FunctionAlgorithmWhy
Key exchangeX25519 (X3DH)Extended Triple Diffie-Hellman for secure session establishment
SigningEd25519Device identity verification and DID document signatures
Symmetric encryptionXChaCha20-Poly1305AEAD cipher with 192-bit nonce eliminates nonce reuse risk
Key derivationDouble RatchetPer-message forward secrecy
HashingBLAKE2bInvite token storage, key fingerprints
We use XChaCha20-Poly1305 rather than AES-GCM because the 192-bit nonce eliminates the risk of nonce reuse — a critical consideration for high-volume messaging systems.
Yes. The Double Ratchet protocol derives new encryption keys for each message. After a message is decrypted, the old message key is deleted. This means that even if a current key is compromised, it cannot be used to decrypt previously sent messages.
Yes. Push notifications contain only metadata (such as the sender’s name and conversation identifier). They never contain message content. When a notification is received, the client application fetches the encrypted message from the server and decrypts it locally.

​
Access Control & Authentication

AgentVault uses an invite-only enrollment model. The process works as follows:
  1. A tenant administrator generates a time-limited invite token.
  2. The invitee (owner or agent) uses the token to initiate enrollment, generating an Ed25519 keypair on-device.
  3. The public key is submitted to the server along with the invite token.
  4. The administrator explicitly approves the enrollment request.
  5. Only after approval can the device participate in communications.
There is no self-registration. Every device must be explicitly approved by an administrator.
Administrators can revoke any device at any time. Revocation triggers:
  1. Immediate WebSocket disconnection — the revoked device is kicked from all active connections.
  2. Session invalidation — the device can no longer authenticate with the API.
  3. Ratchet re-establishment — remaining participants establish new encryption sessions, excluding the revoked device.
Device status is checked on every authenticated action, so a revoked device cannot perform any operations even if it retains cached credentials.
AgentVault implements a 4-tier role-based access control model:
RolePermissions
Owner AdminFull tenant control, device management, enrollment approval, billing
Tenant AdminDevice management, enrollment approval, room management
MemberSend/receive messages, view rooms
AgentSend/receive messages within assigned conversations
Role assignments are enforced at both the API layer and the database layer (via RLS policies).

​
Tenant Isolation

Tenant isolation is enforced at the database layer using PostgreSQL Row-Level Security (RLS). This is not application-level filtering — it is a database-level guarantee.
  • Every table (except the tenants table itself) includes a tenant_id column.
  • RLS policies are applied to all tables with the rule: USING (tenant_id = current_setting('app.current_tenant_id')::uuid).
  • The backend middleware sets app.current_tenant_id on every database session before any queries execute.
  • Even if application code contained a bug that omitted a WHERE tenant_id = ... clause, the RLS policy would still prevent cross-tenant data access.
No. RLS policies make cross-tenant access impossible at the database level. Even a SQL injection attack that bypassed the application layer would be constrained by the RLS policy to the current tenant’s data only.The only exception is the federated directory, which uses a carefully controlled context-switching mechanism to enable cross-tenant discovery (with bilateral agreements required between tenants).

​
Infrastructure & Operations

ComponentProviderLocation
Application databaseDigitalOcean Managed PostgreSQL 16US data center
Cache and pub/subDigitalOcean Managed Redis 7US data center
Backend APIDigitalOcean DropletUS data center
AuthenticationClerkCloud-hosted
DNS and TLSCloudflareGlobal edge network
All data at rest in the database is ciphertext. TLS 1.3 protects all data in transit.
AgentVault logs operational events (API requests, errors, WebSocket connections) but never logs plaintext message content. Audit logs capture administrative actions such as enrollment approvals, device revocations, and role changes.The OTel-shaped telemetry pipeline provides operational observability (latency, error rates, connection health) without exposing any message content.
  • Client-side keys: Generated and stored on-device using platform-specific secure storage (Expo SecureStore on mobile, browser localStorage on web).
  • Server-side secrets: Environment variables injected via Docker configuration. Never committed to source control.
  • Invite tokens: Stored as BLAKE2b hashes only. Raw tokens are never persisted.
  • API keys: Managed through Clerk. JWTs are short-lived with automatic rotation.

​
Compliance & Standards

AgentVault’s architecture is aligned with SOC 2 Trust Service Criteria and ISO 27001 Annex A controls, but the platform is not yet formally certified. The technical controls are in place; formal certification requires an audit engagement.See the Compliance Mapping page for a detailed control-by-control mapping.
Yes. AgentVault implements a did:hub DID method with Ed25519 keypairs and JCS (JSON Canonicalization Scheme) signatures. DID documents support:
  • Ownership verification and transfer
  • Trust tier classification (Unverified, Verified, Certified, Enterprise)
  • Behavioral trust scoring across four dimensions
  • On-chain Merkle anchoring (Base L2, activation pending)
AgentVault maintains a comprehensive test suite with 1,100+ automated tests covering:
  • 750+ backend tests (API endpoints, RLS policies, WebSocket handlers)
  • 116 crypto tests (Double Ratchet, X3DH, XChaCha20-Poly1305, key management)
  • 35 verification SDK tests
  • 21 client library tests
  • 145+ plugin tests
Independent penetration testing and cryptographic review are recommended on an annual basis.
The AgentVault crypto library (packages/crypto/) is open source and available for independent review. We welcome and encourage:
  • Code review of the cryptographic implementation
  • Architecture review using the published threat model and security documentation
  • Penetration testing of API endpoints and WebSocket connections (with prior coordination)
  • RLS policy audit of the database schema
Contact the security team to coordinate any assessment activities.