Your people and Bixie’s agents, working every conversation together.
Vesper is the secure workspace where your team and Bixie’s expert agents collaborate side by side — in channels, conferences and customer calls. Mention an expert and it researches, drafts and summarises right in the thread, then lines up the next action for a person to approve — without ever creating a readable copy somewhere else.
Messaging, calls and file sharing run on infrastructure you operate, with Bixie built in. The people who run the servers cannot read what passes through them, and every message still carries its own protection.
Reviewing this on behalf of a security team? The cryptographic detail is further down the page.
What It Means
The four questions you will be asked in the room.
Answered here rather than in a follow-up call.
Who can read our messages?
Only the devices you have authorised. Not the people who run the servers, not their database administrators, not the infrastructure operators, not the cloud provider, and not any single approver or company administrator acting alone. The one thing encryption cannot do is protect a message after it has been displayed on an authorised device that someone else has taken control of, and we would rather write that down than let you find it out later.
What happens when someone loses a device?
You withdraw that device’s authorisation and the conversations it belonged to move to new keys, so it receives nothing further. What it keeps are the ordinary messages already stored on it and the sensitive ones it had already been approved to open. Anything it was never approved for stays closed, and the highest level requires a fresh approval on every single access, so a lost device cannot be used to go back through an archive.
Can we host it ourselves?
Yes, and that is how it is meant to be run. The whole service runs in your own environment, including voice and video, so message content stays inside infrastructure you control and in the country you chose to run it in. Nothing of ours sits in the middle of your conversations holding your messages. The one thing that reaches us is the Bixie assistant, and only when a member of your team asks it something, which is set out in full below.
What does this do to our regulatory position?
It improves the answers you can give without pretending to answer for you. Because you host it, content does not leave your control. Because content is readable only on authorised devices, a demand served on whoever operates the servers does not produce readable messages. Security-relevant events are recorded in a form designed to make later edits detectable. Vesper has cleared an independent cryptographic audit and penetration testing, though that is not a substitute for any certification your own regulator requires.
Security Levels
4 levels, chosen message by message.
The level belongs to the message and is set when it is sent. Raising the bar for one sentence does not mean raising the friction on every conversation your organisation has, which is the reason people actually use the higher levels instead of routing around them.
The everyday level. Only authorised devices can open the message, and the servers carrying it hold nothing readable. This is the floor, not the ceiling.
Narrows who may open a message to fewer people than the conversation itself contains, and withholds it from the AI assistant. For when being in the room is not the same as needing to know.
The message opens for nobody until the approvers you nominated have agreed to release it. No single approver can do it alone, and neither can an administrator.
The same requirement as Protected, except agreement is never remembered. Every individual access needs its own round of approvals, so opening it stays a decision rather than a door left open.
How It Works
The design decisions that actually matter.
Each one in plain terms, and what it changes about the risk your organisation is carrying.
Protection belongs to the message, not the room it was sent in
This is the decision the whole product is built on. A message is not safe because of the conversation it arrived in — it carries its own protection and its own rule about who may open it. That is what makes an approval requirement on a single message possible at all, and it is why someone who gets into a history does not thereby get an archive.
Nothing readable ever reaches the servers
Messages, files, voice and video are protected on the device before they leave it. The servers move sealed content between people and store sealed content at rest, so an operator with complete access to the infrastructure, or anyone who compels them, still has nothing to read.
The means to open a message only ever exists on your people’s devices
The keys that open messages are created on the device and stay there. They are never sent to a server, and a server generating them on your behalf is on the published list of things we refuse to build, so it cannot be quietly introduced in a later release.
No administrator can let themselves in
There is no master key and no administrative override. A message that requires approvers requires them even when the person asking is the company administrator. That is a thing you can tell your own people plainly, which changes what they are willing to put in writing.
A rule set on a message cannot be lowered afterwards
The level and the policy are fixed at the moment of sending. Nobody can go back and reduce what a sensitive message demanded, and a message whose record has been altered does not open at all rather than opening under a rewritten history.
Calls and files are treated exactly like messages
Voice and video are readable only by the people on the call, and files are protected before they are uploaded. There is no point in the path where a conversation has to become readable in order to be delivered.
A record that shows whether it has been altered
Security-relevant events are written to a log built so that quietly changing history afterwards is detectable. This is the first stage of that work rather than the finished version, and it is listed among the limits below.
A second PIN that opens a decoy
For the case where the risk is not a remote attacker but somebody standing next to your employee demanding they unlock their phone: a second PIN opens a decoy instead of the real account.
Several organisations on one desktop, properly separated
The desktop app holds more than one enrolled organisation at once, each with its own keys and its own isolated session, with one search across the ones you are entitled to see. Someone working for two organisations does not have to trust that the boundary is being respected.
Bixie Inside
Bixie inside, without creating a readable copy somewhere else
When somebody asks Bixie a question, the request goes from their device straight to Bixie. It does not travel through Vesper’s servers on the way, so adding an assistant does not create the readable waypoint the rest of the design exists to avoid.
The assistant is not permitted to see your sensitive messages
There is a hard ceiling. Anything above the everyday level is withheld from the assistant even when the person asking can read it perfectly well, and they are told how many messages were held back. The assistant is bound by the same rule as everyone else rather than trusted to behave.
Content only leaves a device when a person asks it to
Nothing is sent for the assistant to look at in the background. A question from a member of your team is the only thing that moves anything, and it moves only that thread.
An expert invited into a conversation holds no keys
A Bixie expert can be invited to a channel the way a colleague can, appearing in the member list and answering when mentioned. It has no device, so nothing can be sealed to it: it reads nothing at all until somebody asks it something, and then only what that person could already read.
Ask in the thread, get the answer in the thread
Mention Bixie in place and the reply is posted back into the conversation as an ordinary end-to-end encrypted message, labelled as having come from Bixie so nobody mistakes it for a colleague.
The same experts, with approvals where they matter
The assistant inside Vesper is the same set of expert personas as the rest of Bixie. It works through a problem in the open, returns tables and charts, and asks a named person to sign off before anything consequential happens.
One organisation’s assistant cannot see another’s
Each enrolled organisation gets its own assistant session with its own separate credentials, so what the assistant was told for one employer cannot surface in a conversation with another.
Where It Runs
The full desktop workspace: several organisations at once, one search across them, and a panel that tells you exactly what protected the message you are reading.
A native app with conversations, calls and the Bixie assistant.
Everything runs on infrastructure you operate, including voice and video. What that consists of is set out for your engineers further down the page.
Honest limits
A security product that hides its caveats has already told you something about how it handles the ones it has not found yet. Here are ours, starting with the one that matters most to a purchasing decision.
- Group messaging uses an interim epoch-secret model. It rotates keys on membership change, but it does not yet provide the post-compromise security of a full RFC 9420 MLS ratchet tree.
- Native iOS and macOS only for the full experience. There is no web client and no admin console. The React Native app does not include the Bixie assistant.
- Bixie service notifications are server-visible plaintext by design. They are a deliberate, bounded exception to the encryption model, not a gap — but they are not end-to-end encrypted.
- Memory zeroisation is best-effort. Secrets are held in zeroising buffers, but an operating system may still page or snapshot memory, so erasure is not guaranteed.
- Quorum-gated calls, call recording and transcription are out of scope.
- Presence has no per-user opt-out yet. Anyone you share a conversation with can see whether you are reachable and roughly when you last were.
- No agent tool surface. Bixie can be used inside Vesper, but Vesper is not exposed to agents as callable tools.
For Your Security Reviewers
The cryptographic detail, and a list of what we refuse to ship.
Everything from here down is written for the person your organisation asks to check this. “Military-grade encryption” means nothing, so here are the named constructions, the mechanisms behind the levels above, and the constructions our own contribution rules prohibit — which is the half of the story you can hold us to. All of it has now been through independent cryptographic audit and penetration testing.
Per-message keys, with the header bound into the ciphertext
Every message has an independent content-encryption key. Message id, conversation, sender, sender device, security level, policy hash and timestamp are supplied as associated data to the AEAD, so changing any one of them makes decryption fail rather than quietly succeed against a rewritten header. This is also why policy is immutable after send.
Device key custody
Device signing and encryption seeds are generated inside a Rust crypto core and held in the platform keychain, non-exportable where hardware backing is available. They are never transmitted to a server, and server-generated private keys appear on the prohibited list below precisely so this cannot be relaxed later.
Quorum mechanics for Protected and Vault
The content-encryption key is split with Shamir secret sharing over GF(256) and the shares are sealed to approver devices. A requesting device reconstructs the key locally only after the configured threshold has approved; the backend never holds a plaintext share. Vault does not cache the outcome, so each access repeats the exchange.
Group messaging uses an interim epoch model
Groups currently use the epoch-secret model in ADR-0005, which rotates key material on membership change and excludes history from new members. It is not a full RFC 9420 MLS ratchet tree and does not provide the post-compromise security of one. Full MLS is future work, not shipped.
Calls
Voice and video run over a self-hosted LiveKit SFU with media encrypted under a per-call key wrapped to each participant device. The SFU forwards frames it cannot read, so media has no plaintext hop on the server. A participant with no device — an invited Bixie expert, for instance — receives no key and hears silence.
Attachments
Files are encrypted client-side and uploaded as ciphertext, so object storage holds no readable content and no plaintext file ever exists server-side.
Tamper-evident logging
Security-relevant events are appended to a hash-chained log, which makes silent retroactive edits detectable. This is the first phase of a transparency log rather than a finished one.
The AI context ceiling is enforced on the client
The client refuses to include anything above Normal in a request to Bixie and reports to the asker how many messages were withheld. The ceiling is enforced on the device that already holds the plaintext, rather than by a server being asked to be trustworthy.
What you run to self-host it
The stack is yours to operate: the API service, PostgreSQL, Redis, NATS JetStream, S3-compatible object storage, and LiveKit with coturn for calls. There is no web client and no admin console.
Ed25519X25519XChaCha20-Poly1305HKDF-SHA-256SHA-256 / BLAKE3Shamir over GF(256)OS CSPRNGThese are enforced as contribution rules in the repository, not aspirations. A patch that introduces one does not get merged.
Bring your team and your agents into one secure workspace
If humans and AI working the same secure conversations is a real problem for your organisation, we want to hear about it — and we will show you exactly how Vesper handles it, end to end.