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: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:Role assignments are enforced at both the API layer and the database layer (via RLS policies).

​
Tenant Isolation

Tenant isolation is enforced in two independent layers: every query the application issues is scoped to a single tenant, and PostgreSQL Row-Level Security (RLS) enforces that same boundary underneath it. The database layer is not a restatement of the application layer — it constrains queries the application gets wrong.
  • Every table (except the tenants table itself) includes a tenant_id column.
  • RLS policies are applied to all tenant-scoped tables with the rule: USING (tenant_id = NULLIF(current_setting('app.current_tenant_id', true), '')::uuid).
  • The backend middleware sets app.current_tenant_id on every database session before any queries execute.
  • The application connects as a database role that does not hold the BYPASSRLS attribute, so these policies are evaluated on every query rather than skipped.
  • Even if application code contained a bug that omitted a WHERE tenant_id = ... clause, the RLS policy would still prevent cross-tenant data access — such a query returns zero rows rather than another tenant’s data.
Not through any ordinary application path. Every request is bound to a single tenant, every query is scoped to it, and the database enforces that binding independently. A SQL injection that defeated application-layer scoping would still be constrained by the RLS policy to the current tenant’s data.There is a short, deliberate list of cross-tenant paths. Each is an explicit design decision rather than an incidental gap:
  • The federated directory, which uses a carefully controlled context-switching mechanism to enable cross-tenant discovery (bilateral agreement required between the tenants involved).
  • A small number of elevated database roles used by background processing and by pre-authentication lookups — for example, resolving which tenant a device or API key belongs to before a tenant is known. Each is restricted to specific tables and operations, and none is reachable from an authenticated end-user request.
We enumerate these rather than claiming cross-tenant access is outright impossible. The accurate statement is that it is enforced at the database layer, with a known and auditable set of authorised exceptions.

​
Infrastructure & Operations

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.