> ## 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.

# Enterprise Security FAQ

> Common security questions from CISOs and enterprise security teams.

This FAQ addresses the most common security questions we receive from CISOs, security
architects, and enterprise procurement teams evaluating AgentVault for their organizations.

<Note>
  For detailed technical documentation, see the
  [Security Claims & Assurance](/security/claims-assurance),
  [Compliance Mapping](/security/compliance-mapping), and
  [System Security Plan](/security/system-security-plan) pages.
</Note>

***

## Encryption & Data Protection

<Accordion title="Can AgentVault decrypt customer messages?">
  **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.
</Accordion>

<Accordion title="What happens if your database is breached?">
  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.
</Accordion>

<Accordion title="What encryption algorithms does AgentVault use?">
  AgentVault uses modern, well-audited cryptographic primitives provided by **libsodium**:

  | Function             | Algorithm          | Why                                                             |
  | -------------------- | ------------------ | --------------------------------------------------------------- |
  | Key exchange         | X25519 (X3DH)      | Extended Triple Diffie-Hellman for secure session establishment |
  | Signing              | Ed25519            | Device identity verification and DID document signatures        |
  | Symmetric encryption | XChaCha20-Poly1305 | AEAD cipher with 192-bit nonce eliminates nonce reuse risk      |
  | Key derivation       | Double Ratchet     | Per-message forward secrecy                                     |
  | Hashing              | BLAKE2b            | Invite 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.
</Accordion>

<Accordion title="Does AgentVault provide forward secrecy?">
  **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.
</Accordion>

<Accordion title="Are push notifications secure?">
  **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.
</Accordion>

***

## Access Control & Authentication

<Accordion title="How are users and agents enrolled?">
  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.
</Accordion>

<Accordion title="How are compromised devices handled?">
  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.
</Accordion>

<Accordion title="What RBAC model does AgentVault use?">
  AgentVault implements a **4-tier role-based access control** model:

  | Role             | Permissions                                                          |
  | ---------------- | -------------------------------------------------------------------- |
  | **Owner Admin**  | Full tenant control, device management, enrollment approval, billing |
  | **Tenant Admin** | Device management, enrollment approval, room management              |
  | **Member**       | Send/receive messages, view rooms                                    |
  | **Agent**        | Send/receive messages within assigned conversations                  |

  Role assignments are enforced at both the API layer and the database layer (via RLS policies).
</Accordion>

***

## Tenant Isolation

<Accordion title="How is tenant isolation enforced?">
  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.
</Accordion>

<Accordion title="Can one tenant access 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.
</Accordion>

***

## Infrastructure & Operations

<Accordion title="Where is data stored?">
  | Component            | Provider                           | Location            |
  | -------------------- | ---------------------------------- | ------------------- |
  | Application database | DigitalOcean Managed PostgreSQL 18 | US data center      |
  | Cache and pub/sub    | DigitalOcean Managed Redis 7       | US data center      |
  | Backend API          | DigitalOcean Droplet               | US data center      |
  | Authentication       | Clerk                              | Cloud-hosted        |
  | DNS and TLS          | Cloudflare                         | Global edge network |

  All data at rest in the database is ciphertext. TLS 1.3 protects all data in transit.
</Accordion>

<Accordion title="What logging does AgentVault perform?">
  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.
</Accordion>

<Accordion title="How are secrets managed?">
  * **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.
</Accordion>

***

## Compliance & Standards

<Accordion title="Does AgentVault meet SOC 2 or ISO 27001 requirements?">
  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](/security/compliance-mapping) page for a detailed
  control-by-control mapping.
</Accordion>

<Accordion title="Does AgentVault support DID-based identity?">
  **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)
</Accordion>

<Accordion title="What security testing has been performed?">
  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.
</Accordion>

<Accordion title="How can I perform my own security assessment?">
  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.
</Accordion>