Why Encryption Matters for AI Agents
AI coding agents are uniquely sensitive. Unlike a typical SaaS tool that processes a single form field or document, an AI coding agent sees everything — your entire codebase, environment variables, API keys, database schemas, internal architecture decisions, and the full back-and-forth of your debugging sessions. When you run an agent locally, that data stays on your machine. But the moment you stream those sessions over a network — to a cloud relay for remote monitoring, team collaboration, or multi-device access — the stakes change dramatically.
Glueprint was designed from the start to support cloud relay without compromising on data privacy. Encryption is not a feature we bolted on after launch. It is a foundational layer of the architecture, baked into the protocol from the first line of the relay implementation. For a full overview of our security commitments, see the security policy.
The Zero-Knowledge Principle
Glueprint’s cloud relay operates on a zero-knowledge architecture. The relay server routes encrypted event envelopes between connected clients — your desktop app, a teammate’s web portal, a monitoring dashboard — but it never has access to the encryption key or the plaintext content of your sessions.
Encryption and decryption happen exclusively on the client. The relay receives opaque ciphertext, stores it, routes it, and delivers it. If the relay server were compromised tomorrow, an attacker would find only encrypted blobs and routing metadata. No session content, no file contents, no agent responses, no API keys.
This is not a policy decision. It is a cryptographic guarantee. The server literally cannot decrypt your data because it never possesses the key material required to do so.
Key Derivation with PBKDF2
The encryption pipeline begins with key derivation. When a client connects to the relay, it needs a Data Encryption Key (DEK) to encrypt and decrypt session content. That DEK is generated server-side and delivered to the client in a wrapped (encrypted) form. To unwrap it, the client must first derive a Key Encryption Key (KEK) locally from a secret only it holds.
The derivation runs PBKDF2 with HMAC-SHA256 at 600,000 iterations against a server-supplied salt — high enough to make brute-force attacks computationally expensive, while remaining fast enough for a single legitimate derivation on modern hardware. The output is a 256-bit KEK, used exactly once to unwrap the DEK via AES Key Wrap (RFC 3394). The KEK is then immediately zeroed from memory. The user’s secret never leaves the client.
AES-256-GCM Encryption
Once the DEK is unwrapped and held in memory, every event gets encrypted with AES-256-GCM before it leaves the client. GCM (Galois/Counter Mode) is an authenticated encryption mode — it provides both confidentiality and integrity. If a single bit of the ciphertext is tampered with in transit, decryption fails with an authentication error rather than silently producing corrupted output.
A fresh 12-byte (96-bit) nonce is drawn from a cryptographically secure random source for every encryption operation. The nonce is not secret — it travels alongside the ciphertext in the event envelope so the recipient can decrypt. What matters is that each nonce is unique. Reusing a nonce with the same key under GCM would be catastrophic, which is why every encryption call generates a fresh one.
Decryption is the mirror image: ciphertext plus nonce in, plaintext out. If anything is wrong — wrong key, wrong nonce, tampered ciphertext — GCM’s authentication step fails and the receiver refuses to produce output.
The DEK itself lives in memory inside a wrapper that overwrites the key bytes with zeros on disconnect or explicit lock, so a memory snapshot taken after the session ends contains no usable key material.
Event Envelopes and Sequence Numbers
Encrypted content does not travel as raw ciphertext. Each event is wrapped in a structured envelope that pairs the ciphertext with the metadata the relay needs to route and order it: which session it belongs to, a per-session sequence number, the event type, a timestamp, and the nonce required for decryption. The content field itself is opaque to everything between sender and recipient.
Sequence numbers are monotonic per session and assigned client-side before encryption. They make the protocol reliable under unreliable networks: if a client reconnects after a brief interruption and finds a gap — say it has events 1 through 47 but the server reports the latest is 52 — it can request a surgical fill of just events 48 through 52 rather than resyncing the entire session. Large fills are paginated so they don’t overwhelm a single WebSocket frame. For more on how the relay handles connections and routing, see the cloud relay documentation.
Cross-Platform Consistency
Glueprint runs on four very different surfaces: a Rust desktop application, a TypeScript web portal, a Flutter mobile app, and a Rust CLI daemon. Each one needs to encrypt and decrypt the same session data, which means each one runs the same cryptographic pipeline — PBKDF2-HMAC-SHA256 at 600,000 iterations for key derivation, AES Key Wrap (RFC 3394) for DEK unwrapping, and AES-256-GCM for content encryption — against the same parameters.
A session encrypted on a desktop host can be decrypted by a teammate watching from the portal, on a phone, or by a daemon on a remote server. Iteration count, key length, nonce size, and GCM tag handling are identical across platforms, because anything less would break interop.
What the Relay Sees
To summarize what the relay server can and cannot see:
The relay sees: envelope metadata — session IDs, sequence numbers, timestamps, event types, source identifiers, and the encrypted flag. This metadata is necessary for routing, ordering, gap detection, and presence tracking.
The relay never sees: the actual content of your sessions. No code, no file contents, no agent reasoning, no tool outputs, no API keys, no prompts. The content field of every envelope is AES-256-GCM ciphertext, and the relay does not possess the DEK required to decrypt it.
This is the core guarantee of Glueprint’s zero-knowledge architecture. The relay is a routing layer, not a data layer. It moves encrypted envelopes from point A to point B, tracks sequence numbers for reliable delivery, and provides gap fill when events are missed. It does all of this without ever knowing what is inside those envelopes.