Zero-Knowledge Encryption for Autonomous AI Agents

Contents

1. 1.The Problem: Agents Need Memory, Memory Needs Walls
2. 2.Cryptographic Architecture
3. 3.Key Derivation & Management
4. 4.File Encryption Lifecycle
5. 5.Agent UX: Security Without Friction
6. 6.Threat Model
7. 7.Infrastructure & Compliance
8. 8.How We Compare
9. 9.Conclusion

1. The Problem: Agents Need Memory, Memory Needs Walls

Autonomous AI agents are the fastest-growing class of cloud consumers. They generate, store, and retrieve sensitive data at a pace that dwarfs human users. Yet the storage layer they depend on — S3 buckets, managed databases, cloud drives — was designed with a fundamental assumption: the service provider is trusted.

In the agentic era, that assumption breaks down. An agent orchestrating financial workflows stores API keys, transaction logs, and user data. A medical research agent holds patient records. A legal agent manages contracts. If the storage provider can read this data, every breach, subpoena, or insider threat becomes an existential risk.

BitAtlas exists to solve this. We provide persistent, globally available storage where the server is cryptographically blind. Even with full database access, root SSH, and physical possession of the drives, an attacker learns nothing about the contents. This is zero-knowledge encryption — not as a marketing term, but as a mathematical guarantee.

2. Cryptographic Architecture

Design Principles

• Zero-knowledge: The server never has access to plaintext documents or encryption keys.
• Client-side cryptography: All encryption and decryption occurs locally — in the browser (Web Crypto API) or in the agent runtime (Node.js crypto).
• Defense in depth: TLS 1.3 in transit, AES-256-GCM at rest, bcrypt for auth, separate key derivation paths for authentication and encryption.
• Minimal trust: Even a fully compromised server yields only encrypted blobs and encrypted key material.
• Agent-native: Designed from day one for MCP (Model Context Protocol) integration while maintaining full security boundaries.

Cryptographic Primitives

3. Key Derivation & Management

A critical design decision in BitAtlas is the complete separation of authentication and encryption key paths. Your login credentials and your encryption key are derived from the same password but through entirely different, non-reversible processes.

Authentication Path (server-side)

User password + salt → bcrypt (10 rounds) → Password hash
  → Stored in PostgreSQL for login verification
  → Cannot be used to derive the encryption key

Encryption Path (client-side only)

User password + user-specific salt → PBKDF2-SHA256 (100k iterations)
  → 256-bit Master Key
  → Lives only in browser/agent memory
  → Never transmitted, never stored server-side

This means that even if our database is fully exfiltrated, an attacker has bcrypt hashes (useless for decryption) and encrypted key material (useless without the master key). The master key exists only in volatile memory on the client.

Per-File Key Architecture

Each file gets its own randomly generated 256-bit AES-GCM key. This per-file key is then encrypted ("wrapped") with the owner's master key. The wrapped key is stored server-side alongside the encrypted blob. This design means:

• Compromising one file key does not compromise any other file.
• Password changes only require re-wrapping the file keys, not re-encrypting every file.
• Emergency access can be granted by wrapping the file key with an additional key, without exposing the owner's master key.

4. File Encryption Lifecycle

Upload (Encryption)

1. User or Agent selects a file
2. Client generates a random 256-bit file key
3. File is encrypted with AES-256-GCM using the file key
   → Produces: encrypted blob + IV + authentication tag
4. File key is wrapped with the owner's master key (AES-256-GCM)
   → Produces: ownerEncryptedKey + ownerIV
5. Upload to server:
   • Encrypted blob → S3-compatible object storage (EU-only)
   • ownerEncryptedKey, IV, authTag → PostgreSQL (EU-only)
6. Server never sees: plaintext file, file key, or master key

Download (Decryption)

1. Client requests file metadata from API
2. Server returns:
   • Presigned URL to the encrypted blob
   • ownerEncryptedKey, IV, authTag
3. Client decrypts:
   a. Unwrap ownerEncryptedKey using master key → file key
   b. Download encrypted blob via presigned URL
   c. Decrypt blob using file key + IV + authTag → plaintext
4. Server never sees the plaintext at any point

The presigned URL mechanism ensures that even the download path is time-limited and authenticated, without requiring the server to proxy (and potentially inspect) the data.

5. Agent UX: Security Without Friction

The biggest challenge in zero-knowledge systems is usability. For human users, this means password prompts and key management. For AI agents, the challenge is different: how do you give an autonomous process access to encrypted data without creating a permanent security hole?

MCP Integration (Model Context Protocol)

BitAtlas is natively compatible with MCP, the emerging standard for AI agent tool use. An MCP-compatible agent (Claude, Cursor, Windsurf, or any custom agent) can:

• List vault contents — see file names and metadata (never plaintext).
• Upload encrypted files — encrypt locally in the agent's runtime before upload.
• Download and decrypt — retrieve encrypted blobs and decrypt in-memory.
• Search — query metadata without exposing contents.

API Key Scoping

Each API key can be scoped with fine-grained permissions:

{
  "permissions": ["vault:read", "vault:write"],
  "maxFiles": 100,
  "expiresAt": "2026-04-25T00:00:00Z",
  "allowedCategories": ["legal", "financial"]
}

This means you can give an agent write access to one category of your vault, with an automatic expiry, without exposing your master key or granting access to unrelated files.

The Agent Trust Boundary

The master key must be provided to the agent's runtime for decryption. This is the fundamental trust boundary: you trust the agent's execution environment (its sandbox, its memory) the same way you trust your own browser. BitAtlas does not attempt to solve the "malicious agent" problem — that's the agent framework's responsibility. What we guarantee is that the storage layer itself is zero-knowledge, and that key material never leaves the client-side boundary.

6. Threat Model

7. Infrastructure & Compliance

European Data Sovereignty

All BitAtlas infrastructure is hosted on European-owned providers. We do not use any US-owned cloud services (AWS, GCP, Azure) for data storage or processing. This means:

• No CLOUD Act exposure: US law enforcement cannot compel a European provider to hand over data stored on European soil.
• GDPR-native: Data residency is in Germany and Finland, fully within EU jurisdiction.
• SOC 2 Type II: Our infrastructure providers maintain SOC 2 certification.

The Privacy Stack

8. How We Compare