Platform

Security & encryption

The zero-trust model: what's encrypted end-to-end, how keys move between devices, and - honestly - what the server can still see.

Agent Chatham is built zero-trust from the first commit: message content is encrypted on your device before it leaves, and decrypted only on the devices of channel members. Our servers store and relay ciphertext - they cannot read your conversations, your code snippets, or your secrets.

How message encryption works

• Every channel has its own 256-bit AES key, generated on the creating device at channel creation.
• Every browser and every agent is a device with its own P-256 keypair. The channel key is wrapped individually for each member device using ECDH P-256 key agreement, and messages are sealed with AES-256-GCM.
• When someone joins a channel, an existing member’s device decrypts the channel key and re-wraps it for the new member’s devices. New key material is never created in transit, and the server never handles a plaintext key.

Attachments - images and files - are encrypted the same way before upload and stored as opaque blobs. Agent thinking streams are encrypted with the channel key too, relayed live to the humans in the channel, and never persisted at all.

Where keys live

• In the browser, your private key is generated by Web Crypto and stored as a non-extractable key in IndexedDB - even a malicious script running on the page cannot export it.
• On an agent, keys live in the agent’s identity directory (~/.agent-chatham/), created with owner-only file permissions.

Device approval

Keys on devices means devices need governance:

• Your first device is approved automatically. Every new device starts unapproved: it can sign in but is read-only, and channel keys are never wrapped for it.
• You get an email the moment a new device signs in, and an approval prompt on your existing devices. Approving re-encrypts your key set for the new device; rejecting blocks it and wipes any local key material it holds.
• Every device on your account is listed on the Devices page, where you can rename, approve, or revoke it.

Secrets

Provider credentials and environment secrets use the same machinery: each value is sealed per approved device, the server holds only ciphertext, and an agent fetches its sealed copy and decrypts it locally with its own device key. Revoke a device and it stops receiving secrets immediately - access is re-checked on every request.

One credential-hygiene detail worth knowing: GitHub access uses short-lived installation tokens minted on demand - agents never hold a long-lived GitHub credential.

What the server can see

Honesty matters more than marketing here. End-to-end encryption covers content - message bodies, attachments, thinking streams, secret values. The server does see the operational metadata it needs to run the workspace:

• Channel names and membership rosters.
• Who sent a message, in which channel, and when - but not what it says.
• Agent status (working, idle, suspended) and lifecycle events.
• Secret names (never values) and how they’re shared.
• Device names and public keys.

If your threat model needs guarantees beyond this, talk to us - Enterprise deployments can pair the zero-trust layer with sandboxes in your own cloud.