Security and encryption

Last updated: 16 September 2026

This is the page the encryption claim points at. It exists so the claim can be checked rather than

taken on faith, and so the parts that are not covered are as easy to find as the parts that are.

We have been wrong about this before. Earlier versions of our privacy policy claimed encryption

we did not ship — inherited copy from the project this app was forked from, rebranded without being

re-verified. That correction is still on the Privacy Policy, and it stays there. It is

the reason this page lists the gaps first-class instead of in a footnote.

The short version

When end-to-end encryption is active on a session, its chat messages and terminal output are

encrypted on your own devices, and our servers hold only ciphertext for them. The keys are generated

on your devices and the private halves never leave them.

It is not the case that everything in Mycolab is end-to-end encrypted. Session titles, project

paths, machine names, timestamps, uploaded file contents and most service calls are not. Some of those are

merely not built yet and some cannot work by construction — the sections below say which is which,

because a gap we intend to close and a gap we cannot are not the same promise.

What is end-to-end encrypted

• Chat messages — your conversation with the agent, sealed under a per-session key.
• Terminal output — the output of commands run in a session, sealed under a separate

per-terminal key, minted per terminal rather than per session.

• Terminal input — what you TYPE into a session's terminal. Listed separately from the output

above because until September 2026 it was NOT covered: we encrypted what the terminal printed and

not what you typed into it, so a password typed into a session we described as encrypted was

visible to us. That gap is closed.

• Secrets you save — when you store an API key or other credential for a machine, the value is

encrypted to that machine and we never see it. (Reading them back was already safe: the machine

sends only a masked preview, never the value.)

Both use AES-256-GCM, bound to the address of the stream they belong to, so a sealed record cannot be

replayed into a different session and still open.

What is not end-to-end encrypted

Stated plainly, because this is the half that gets buried. It is split by why, because "we have

not built it yet" and "this cannot work by construction" are very different promises and a single

list hides that difference.

Not covered today — and there is no technical reason it can't be

These are ordinary backlog, not limits. We list them separately so the gap is a commitment rather

than a shrug:

• Most other service calls — when one of your devices calls a service on another, the arguments

and the reply generally still pass through us readable. The two that carried the most sensitive

arguments — saving a secret, and terminal input — are encrypted now and are listed above; the rest

of that surface is not yet. This is a staged rollout rather than a limit: the mechanism is built and

running, and each remaining call is a decision to extend it, not a thing to invent.

• File contents — files you upload, or that a session produces, in our object storage. They are

encrypted in transit and at rest by the storage provider, but not end-to-end: we hold keys that can

read them. File bytes go straight to storage without passing through our logic, so there is nothing

structural in the way here either.

Not covered because of how the system works

• Session and machine metadata — session titles, project directory paths, machine identifiers and

names, lifecycle state, and the timestamps and sizes of messages. We can see that a session

happened, on which machine, in which directory, and how much was said — even when we cannot read

what was said. This one is genuinely hard rather than merely unbuilt: our servers merge edits to

this state, which means they have to be able to read it. Encrypting it means redesigning how that

state is shared, not adding a cipher.

• Scheduled work — a workflow's schedule has to be read by us to know when to run it. A time we

cannot read is a time we cannot act on.

Not covered because you asked us to publish it

• Anything you publish — a served site, an exposed HTTP endpoint, an MCP attachment. Publishing

takes content out of the envelope; that is what publishing means.

• Your account details — the email address you sign in with, and ordinary connection metadata

(IP address, request headers) that any web service receives.

When encryption actually turns on

Three conditions, all of which have to hold. If any does not, the session is created unencrypted

rather than half-encrypted or broken:

1. New sessions only. A session created before encryption was available for your account stays

readable by us, permanently. We do not retroactively encrypt, because it would not help: we

already received that content in a form we could read, and re-sealing it would be theatre.

Sessions imported from a previous install are in this category.

1. Every active device must be enrolled. A session key is wrapped individually to each of your

devices' public keys. If any active device has not yet published one, new sessions stay

unencrypted instead — locking one of your own machines out of your history is a worse outcome than

an honest "not encrypted".

1. The workspace must have it enabled. Encryption is rolled out per workspace.

For the encrypted calls above there is a fourth condition, and it is worth stating because you can

observe it: the machine you are calling must have published its public key. A machine running

software older than this feature has not, so calls to it fall back to the unencrypted path rather than

failing. We chose that over refusing to talk to your own computer — but it means "this call was

encrypted" depends on the machine at the other end, not only on your account.

Because of (1) and (2), turning encryption on does not change anything you already have. It

changes what happens next.

Keys, devices, and recovery

• Every device generates its own key pair, and the private half never leaves that device.
• We do store key material — but only in wrapped form, and we hold no way to open it. Your account

key is generated on your device and wrapped separately by your passkey, by your recovery code, and by

each enrolled device. Those wrapped blobs sit on our servers, which is what lets you add a new phone

or recover an account without us ever holding a usable key. It is the same shape a password manager

uses. We say this explicitly because "the keys never touch our servers" would be the easier sentence

and it would not be true.

• Each session gets its own data key, which is wrapped separately to each enrolled device. That is

what lets a new phone read a session without any of your machines being online.

• A recovery code is the fallback if you lose every enrolled device. If you lose all devices and

the recovery code, we cannot recover encrypted sessions for you. That is the cost of us not holding

the keys, and it is not a defect.

• Removing a machine stops it receiving keys for future sessions. It does not retroactively

revoke the sessions it already holds keys for — it has already read them.

What this does and does not protect against

• It does protect the content of encrypted sessions from us, from anyone who obtains our stored

data, and from a lawful order served on us — we cannot produce plaintext we do not have.

• It does not protect the metadata above, which we can still see and could still be compelled to

produce.

• It does not protect you from someone with access to your own unlocked device, or from the agent

itself sending content somewhere you told it to.

• It does not make us unable to see future content. We ship the client. A future version could

behave differently; the defence there is that the code is open and this page is dated.

How to check it yourself

• In the app — an encrypted session shows a lock beside its name in the session list. It appears

only on positive evidence: the session's log is encrypted and this device holds the key. A session

whose state has not been determined shows nothing at all rather than guessing.

• In the source — the sealing and key-wrapping code is public in

the repository, as is the design that produced it.

Everything else that protects your data

These apply to all sessions, encrypted or not:

• Encryption in transit — TLS (HTTPS / WSS) on every connection between your devices, our edge,

and your machines.

• Encryption at rest — storage is encrypted at rest by the provider.
• Workspace isolation — each workspace is a separate, single-tenant object; cross-workspace access

is denied by default.

• Scoped, revocable tokens — bound to one workspace and one permission level; authorization fails

closed.

Reporting a vulnerability

Email oeway007@gmail.com. Please include enough detail to reproduce it. We will confirm receipt,

and we would rather hear about a problem than have it stay quiet.