Use this file to discover all available pages before exploring further.
This document defines AgentVault’s security goals, enumerates threat actors, identifies high-value assets, and maps each threat scenario to specific mitigations. Honest limitations are documented alongside protections.
Capability: Full database access and/or server code control.
This is the scenario AgentVault is specifically architected to survive. A full backend compromise exposes only ciphertext, public keys, and metadata. No message content can be recovered.
Attack Vector
Mitigation
Read message content
Impossible — only BYTEA ciphertext stored; no private keys on server
Derive encryption keys
Impossible — keys exist only on client devices
Use stored invite tokens
Impossible — only BLAKE2b hashes stored; raw tokens are one-time-use
Inject malicious messages
Detected — Ed25519 signatures on message headers verify sender identity
Modify ciphertext
Detected — Poly1305 authentication tag fails on tampered ciphertext
Attacker gains full read access to PostgreSQL.What they find: - messages.ciphertext (BYTEA) -- random-looking bytes - messages.header_blob (BYTEA) -- encrypted headers - devices.identity_public_key (BYTEA) -- public keys only - invites.token_hash (BYTEA) -- irreversible BLAKE2b hashesWhat they can do with it: Nothing. No private keys. No plaintext. No usable tokens.
Mitigation: Ciphertext-only storage. No server-side keys. BYTEA columns for all cryptographic material.
Attacker gains control of an agent's host machine.Immediate impact: - Can read current and future messages for that agent - Can send messages as that agentCannot: - Access other tenants' data - Read messages sent before the compromise (forward secrecy) - Survive device revocation
Mitigation: Owner revokes the device, which immediately closes WebSocket connections and returns 403 on all API calls. Owner re-enrolls with a new invite. New X3DH key agreement establishes fresh keys.
A code change accidentally omits tenant_id from a query.Impact: - Could expose data across tenants
Mitigation: RLS is enforced at the database level, independent of application code. Even a query that omits tenant_id in its WHERE clause is filtered by the RLS policy. The app.current_tenant_id session variable is set by middleware on every request.
Attacker convinces an owner to approve a malicious device.Impact: - Attacker's device joins the tenant with valid keys - Can send/receive messages in conversations it's added to
Mitigation: Device fingerprint verification during approval. Fingerprints are displayed as hex-encoded BLAKE2b hashes that the owner compares against the agent’s console output. Short-lived invites (10-minute expiry) limit the attack window. Single-use tokens prevent reuse.
Being explicit about what AgentVault does not protect against is a deliberate security practice. Overstating security claims erodes trust; honest limitations build it.
Non-Goal
Rationale
Fully compromised host OS
An attacker with root on the owner’s device or agent host can extract keys from memory. This is true of all software-based encryption. Hardware security modules (HSMs) are a future enhancement.
Screenshot / screen recording prevention
Once plaintext is displayed on screen, it is outside the encryption boundary. DRM-style protections are unreliable and platform-specific.
Nation-state traffic obfuscation
Traffic analysis (who communicates with whom, when, and how much) is visible at the network level. Onion routing or mixnets would be required to mitigate this — out of scope for the current architecture.
Metadata minimization
The server necessarily knows message timestamps, conversation participants, and message sizes. Sealed sender (a la Signal) is a potential future enhancement.
Post-quantum cryptography
X25519 and Ed25519 are not quantum-resistant. Migration to ML-KEM/ML-DSA is planned but not yet implemented.
