Security · Missived

The short version

Your data goes to servers we run ourselves, in the US. Only a handful of companies that run the service handle any of it, and each is named on our privacy promise.
Everything travels encrypted, and messages and files are encrypted before they're stored, in every workspace. Calls are encrypted between your device and our call server.
It isn't end-to-end encryption. Our servers can read messages so search, moderation and notifications work. We say so plainly below, along with what we do with that trust.
No trackers, no ads, no selling your data. Not in the app, the website, the desktop app or our emails.
Security rules are written down and tested. Each feature is built against them, with tests that fail if a boundary is crossed.

How your data travels

Swipe sideways to see the whole diagram, or read it in words below.

A lock marks what's encrypted on each hop and how. Numbered markers show where the abuse checks sit:

Marker 1, Rate limits: per network address for the API, per person and per connection for chat; bursts alert us.
Marker 2, Permission check and word filter: on everything people type that others will see.
Marker 3, Upload checks: a file's contents must match its type, and profile pictures and icons are re-drawn. Virus scanning is coming.
Marker 4, Outbound guard: our server fetches only public addresses and re-checks every redirect.
Marker 5, Webhook checks: deliveries from services you connect are verified, by their signature or a secret link, before we read them; signed ones are accepted only once.
Marker 6, Confirm it's you: password and current code again for sensitive account and workspace actions.

The same picture in words:

Opening the app. The web app's own files (the code your browser runs) come from Cloudflare's network, over HTTPS. They contain no data of yours.
Messages, files and everything you do in the app go from your device straight to our app server, encrypted with TLS 1.2 or newer (older versions are refused). Cloudflare doesn't sit in the middle of that connection, so your messages don't pass through it.
Files are encrypted on our server first, then stored with Cloudflare's file storage. So are our nightly database backups. Cloudflare holds them, but can't read them.
Calls (voice, video, screen shares and the Virtual Office) connect to our own call server, encrypted with the standard every browser uses for calls (DTLS-SRTP). When a network blocks a direct route, the call is relayed through our own relay server, never a public one. Our call server is set up so it doesn't hand your browser Google's or Twilio's public connection helpers, so they don't learn who is calling. Until we've confirmed that on the live server, our privacy promise still lists them.
Email (sign-in codes, invites, the notifications you choose) is sent through Resend. Push notifications, if you turn them on, go through your own browser's push service (Apple, Google, Mozilla or Microsoft), encrypted so that only your browser can read them.
Images from other websites load through our server, so those sites don't see who's looking.
Integrations move data only when someone in your workspace connects one, and only what it needs. What they send us is checked before we read it (marker 5), and anything our server fetches from another website goes through a guard that refuses private and internal addresses (marker 4).
Inside our app server, the database and the cache aren't reachable from the internet at all; the only way in is the encrypted front door. Background jobs send email and push, run reminders, delete files you removed and make the nightly backup.

A message's journey

This is a person's message. Apps and webhooks post only where they've been added, within budgets of their own. Markers match the diagram above.

You send it from your device, over TLS.
Rate limit. Each person and each connection has a budget, so a flood is slowed down before it reaches anyone.
Is it allowed? Can you post in this channel; does it pass the platform's word filter and your workspace's; AutoMod; are you timed out; is slow mode on. Anything that fails stops here and isn't stored.
Stored, sealed with your workspace's own key (AES-256-GCM, tied to that one message), in every workspace. For search we keep keyed fingerprints of its words, never the words themselves.
Delivered live, and only to people who can see that channel at that moment. If someone loses access, their open connection stops getting it at once.
Notified. A direct or group message's notification says who sent it, not what, unless you choose to see the text; any notification leaves the text out if you, or your workspace, chose that. A browser that has Missived open on screen gets no push; it's held until you look away.

Encryption

On the way. Every connection to the app and our API uses TLS, and our API tells browsers to insist on it (HSTS). Calls use DTLS-SRTP, the encryption built into every browser's calling.

When it's stored:

Files: always. Every uploaded file is encrypted with AES-256-GCM, with its own random starting value and an integrity check, before it leaves our server for storage. The one exception is pictures meant to be shown to anyone who visits: workspace icons and profile pictures.
Messages: always, in every workspace. Every message, direct message and group chat message — with its link previews and app cards, plus forum titles, posts waiting to be sent, meeting chat and the few words AutoMod keeps — is stored sealed under that workspace's own key. Messages from before this was on everywhere are sealed by a background job, a batch at a time, while chat goes on — until it reaches them they, and their old search index, are stored as written, and backups taken before then still hold them so until they expire. It can't be switched off. Table cells, whiteboards, Knowledge page text, sign-ups and similar text are sealed from when the workspace got its key.
Search still works. Each word is stored only as a keyed fingerprint (HMAC-SHA256 under a key derived from the workspace's), so a sealed message's search index holds no words. Every word you type must match, and the last also matches as the start of a word; exact phrases and misspellings aren't matched.
What isn't sealed this way: names (of the workspace, channels, people, files, events), channel topics, profiles and statuses, who sent what and when, poll questions, and the words Knowledge search keeps for published pages. Org Settings → Security → Encryption lists it all for Owners and Admins.
Owners can rotate the workspace key there, after confirming it's them: new messages are sealed with the new key, older ones stay readable and findable, and the rotation is recorded in the workspace's audit log.
Some private details are sealed too, each for its own purpose: authenticator-app secrets, the keys and tokens for services you connect, meeting passcodes and manage links, and what people type when they sign up for an event. Each is sealed for one purpose, so a sealed value can't be moved and opened as something else.
Things we only need to recognise are stored only as one-way fingerprints (SHA-256), never as themselves: API tokens, invite and overlay links, calendar links, webhook links and emailed sign-in links. A new API token is shown to you once and can't be shown again.
Passwords are stored with bcrypt at a work factor of 12, never in a form that can be turned back into the password.
Backups are encrypted (with age) as they're made, so a backup is never written to disk unencrypted, and the key to open them isn't kept on the server. We've practised restoring from them.

What's encrypted today

"On the way" means on the network; "when stored" means on our disks and in storage. "Who can read it" is who can see the words or the picture with the access they normally have. In every row the keys are held by our servers, never only by you — so none of this is end-to-end encryption.

What	On the way	When stored	Who can read it
Messages, direct messages and group chats	Encrypted (TLS) to our own app server	Sealed with your workspace's own key, in every workspace. Older messages are sealed by a background job	Our server; the people in the channel or conversation; a workspace's Owners and Admins, for a message someone reports to them
Tickets subjects, messages, notes and requester details	Encrypted (TLS)	Sealed at rest; requester addresses use keyed lookup fingerprints	Our server; the queue’s authorised team; a requester sees only their own public conversation. Personal assistants need separate consent; apps never read Tickets
Files	Encrypted (TLS)	Encrypted before they're stored with Cloudflare. File names and sizes aren't; workspace icons and profile pictures are public by design	Our server; whoever can see the message or meeting they're in
Calls: voice, video, screen shares, meetings, the Virtual Office	Encrypted (DTLS-SRTP) to our own call server, relayed only by our own relay	Not stored, except a recording	Our call server handles every stream, as every group call server does; the people in the call
Call recordings	—	Only when a host records, never in a direct or group call. Encrypted before they're stored	Our server; the people the workspace lets see them
Push notifications	Encrypted so only your browser can read them, through its own push service	Not kept	Our server writes them. A direct or group message's says who sent it, not what, unless you choose; "no message text" leaves it out of every one
Emails	Encrypted to our email company (Resend); we refuse to send without it	Resend keeps delivery logs	Resend and your email provider see what an email says. An email about a direct or group message you missed counts them and doesn't quote them, unless you choose
Search	—	Keyed fingerprints of words, never the words (older messages once the background job reaches them)	Our server
AutoMod's log	—	The few words that tripped a rule, sealed. Nothing at all from a direct or group message	A workspace's Owners and Admins
Link previews	Our server fetches the page, so the site sees our server, not you	Sealed with the message	The people who can see the message
Backups	Encrypted as they're made, then stored with Cloudflare	Encrypted; the key to open them isn't kept on our servers	Nobody without that key
Logs	—	Content-free: no message text, email addresses or names	Our servers only
Passwords and sign-in secrets	Encrypted (TLS)	Passwords as one-way bcrypt hashes; authenticator secrets sealed; tokens as one-way fingerprints	Nobody can turn a password back; our server opens the sealed secrets to check a code

We're also confirming that the disks of our own servers are encrypted underneath all of this, and we'll say so here once we have.

Is Missived end-to-end encrypted? Not yet. Everything you send travels encrypted, and calls are encrypted between your device and our own call server. Messages, files and backups are encrypted before they're stored. But our servers hold those keys. That's what lets Missived search your messages, filter words, notify people and run bots. It also means that someone in full control of our servers could read messages and could, in principle, listen to calls. We never do, and we never sell or share your data. We're working on true end-to-end encryption, starting with direct and group calls, then direct messages, group chats and meetings — it's on our roadmap. When it's on, only the people in the conversation hold the keys, and some features work differently; we'll say exactly which before you switch it on.

What we can and can't see

Missived runs on a trusted server: the server holds the keys, so it can read your messages in order to search them, filter words, notify people and hand them to the people allowed to see them. That is a deliberate choice, and it's how Slack, Teams and Discord work too. It is not end-to-end encryption, and we won't call it that.

What encryption at rest protects against: someone who gets a copy of our storage or a backup. Files and messages in it are unreadable without keys that live elsewhere, and their search index holds no words (for older messages, once the background job has sealed them).
End-to-end encryption is coming for direct messages, group chats, their calls and meetings — and it will cost things (server search, bots and some moderation can't reach what our servers can't read). Until it ships, nothing in Missived is end-to-end encrypted.
What it doesn't: the running service itself. In principle, someone with full control of our servers could read what's on them. That's why access to them is limited to us, and why we write down and test the rules below.
Our admin console manages workspaces from the outside. It can't sign in as you and has no view into chats.
What we promise to do with that trust: we never sell or share your data, never train AI on it, and never send it to an AI service unless someone in your workspace connects one.

Signing in and your account

Short-lived sign-ins. The app holds a pass that expires within minutes and is renewed in the background. In the browser, the renewal token sits in a cookie that page scripts can't read and that other sites can't send (HttpOnly, SameSite=Strict). It's replaced every time it's used, and if an old one is ever replayed, that session is ended.
Two-step sign-in: authenticator apps, backup codes and a secret number, plus a code for every new device. If you've set up an authenticator, a code from your email alone is never enough to get past it. Wrong guesses lock the factor after a few tries.
Confirm it's you for the big things. Adding a second factor, making an API token, handing over ownership, exporting or deleting a workspace and deleting your account all ask for your password and your current code again, even if you're already signed in.
Passwords are checked against common and known-breached ones and your own details, following NIST's guidance: long rather than complicated, and no forced changes.
See your sessions and sign out of any of them. "Sign out everywhere else" keeps the device you're holding and nothing else, and there's a cap on how many devices can be signed in at once.
Sign in with Google is your choice, and it never attaches itself to an existing account just because the email address matches: you confirm with your password first. Your second factor still applies.
An Owner can't take over your account. Workspace Owners can help a member back in, but not reset the password of someone who also uses their account in other workspaces.
API tokens and apps get only what they're given. Each token has scopes you pick, is shown once and is stored only as a fingerprint. An app never reads direct messages; a personal token does only if you tick that box. Apps connect through a standard consent screen (OAuth) and you can disconnect them any time. No token can change your password, manage your sign-in or reach the admin console.

Keeping workspaces and people apart

Every query is scoped to its workspace. One workspace can't read another's channels, files or people.
Every file link is signed for the person viewing it, and access is checked again on every download, so a forwarded link doesn't open someone else's files.
Losing access takes effect at once. When someone is removed from a workspace or a channel, an app that's already open stops receiving it straight away, not at the next reload.
"Must never see" tests. Where a feature keeps people apart, there is a test that tries to cross the line and fails the build if it can: Guests and their categories, under-18s, client-portal contacts, partners in a shared category, apps and AI assistants, and people who see only part of a Table.
Under-18s get extra protection: a direct message can only come from someone in a workspace they share, never an outside Guest; adults-only channels stay closed to them; and their notifications leave message text out unless they choose otherwise.

Where it runs

Our servers are rented from OVHcloud in Virginia, in the US, and run by us: one for the app, its database and cache, and one for calls. A second call server is being added before launch, so there's room to grow and one can be updated without cutting calls off.
Cloudflare serves the website and the app's files, and stores files and backups that are already encrypted. Resend sends our email. Those are the companies that run the service. A few others are involved only when you use something that needs them: your browser's push service, Google if you choose Continue with Google, and Anthropic if you choose to send a bug report to our assistant. Every one, and what it sees, is on our privacy promise.
Strict browser rules. Every API response tells the browser not to frame it, sniff it or pass on where it came from. The web app's content security policy lets it talk only to our own servers, and allows no inline scripts and no running text as code. The desktop app's pages carry the same kind of policy.
No third-party trackers of any kind: no analytics, ad networks, session recorders, pixels or fingerprinting.
The service refuses to start with weak settings. In production it won't run with missing or default sign-in secrets, without its encryption key, or with an open-to-everyone origin.
Errors don't leak details. An unexpected error is logged on our side and you get a plain "something went wrong".
Logs are operational, not personal. Our app's logs record which kind of request it was, whether it worked and how long it took. They never contain message text, names, email addresses, secret links, sign-in codes or your network address: each address becomes a scrambled code that changes every day and can't be turned back, so we can only tell that two requests came from the same place that day. Tests fail if personal data reaches the logs. Rate limits still use the real address for a short time to slow attackers down. This covers our app's own logs; the front door's and the call servers' logs aren't covered by it yet.
Our operations code is private; the product is opening up. The self-hosted edition is licensed as open source (AGPL), so anyone will be able to read the code that runs it. The public repository is coming soon.

Stopping abuse

Rate limits slow down anyone trying to guess passwords or flood a workspace: per network address for the API (a whole home or office network counts as one), and per person and per connection for chat. Bursts alert us by email.
Word filter. A platform list that can't be relaxed, plus a profanity list and words an Owner adds. Blocked text is refused, never stored or logged.
Age rules at sign-up, with the protections for under-18s above.
Sign-ups are open. When the service is near capacity, new workspaces wait in a queue instead of slowing everyone down. We can temporarily require an invite code to contain sign-up abuse.
Our server never fetches just any address. When it fetches a link preview, a feed or anything else someone points it at, it refuses private and internal addresses, and checks every redirect again. The same goes for the game-server status checks, which talk to the outside world only through one guarded path.
Webhooks are signed and checked. Messages from other services are verified before we read them, and each can be used only once, so a captured one can't be replayed. What we send out is signed so the receiver can check it came from us.
Uploads are checked. A file's contents must match its type, profile pictures and icons are re-drawn to strip anything hidden, and files with macros carry a warning. Coming: virus scanning of every upload, on our own server, as part of the server upgrade before launch.
An audit log. Owners and Admins can see who changed what in their workspace: roles, settings, integrations, encryption, deletions.
E-signatures (coming soon) have their own email guardrails, daily limits and a tamper-evident signing record. How e-signatures work explains independent verification and the seal's limits.

Deleting and leaving

Deleting means deleting. When a message, a file or a whole workspace is deleted, the stored files are deleted too, through a queue that keeps trying until it's done.
Download my data: a zip of your profile, your messages and the files you uploaded, from Settings.
Delete my account: it waits 7 days so you can change your mind (we remind you the day before), then your profile is wiped and your sessions end.
A workspace is never deleted out of the blue. When an Owner deletes one, everyone in it, Guests too, is told by email and in the app, with 14 days to save what they want, a reminder the day before, and a banner on every screen until then. Any Owner can cancel, and everyone hears that too.
You're told when your words go. If a channel you wrote in is deleted, or someone else removes your message, you get a note saying what went and who did it.
Workspace export: an Owner can download the whole workspace. DMs, group chats and personal channels are never part of it, and the other Owners and Admins are told when one is made.
Keep message text out of notifications: a setting for you, and a rule an Owner can set for the whole workspace, so a lock screen or an inbox never shows what was said. Our emails carry no tracking pixels or click tracking.

How we keep it secure

We'd rather tell you exactly what we do than claim more. Missived is built by a small, self-funded team, with AI coding assistants working under the founder's direction.

How it has worked so far. Security rules are written into the project's rulebook, the instructions every change is built and checked against. From the first weeks it held the basics (workspace separation, short-lived sign-ins, encrypted files); since early October it has grown into a detailed set of rules, one for each sensitive area, each with the tests that hold it. Since August an automated test run has checked every change, and today a change can't be merged until it passes. Some milestones, in order:

July: two-step sign-in, session limits and email password reset, with the workspace audit log.
August: rate limits and alerts.
6 October: a hardening pass over sign-in, sessions, passwords, security headers and how files are signed and served, and our server refusing to fetch private addresses for anyone.
13 October: every integration's incoming webhooks are verified and can't be replayed.
22 October: a privacy pass: our own call relay instead of Google's and Twilio's, encrypted backups, real file deletion, account export and deletion, and notifications without message text.
26 October: a full review of the whole service: sign-in, who can reach which workspace and channel, what the app shows, what goes in our logs, and every library we depend on. Every serious problem it found was fixed, each with a test that fails on the old code, and the follow-ups after it too. The app's libraries had no known high-severity problem afterwards.

What that isn't. Not every phase had its own dedicated security review: the rules and their tests went along with each feature, and the first full review was on 26 October. Those reviews were our own, not an outside audit. We can't yet afford an independent penetration test, so we'll say so here when we've had one. Missived doesn't hold its own SOC 2 report or ISO 27001 certificate yet; our compliance page says where we stand, what we're working towards, and what our infrastructure providers are certified for.

What we do now, on every change (from 30 October):

A code review before every change is merged, looking for bugs and security problems, with what it found and what was fixed written into the change.
Independent AI code review on every pull request, alongside our own, looking for bugs and security problems. What it finds is fixed the same way, each with a test.
"Must never see" tests and the rest of the suite on every change, plus tests that fail if personal data reaches our logs.
Automatic scanning on every change for risky code patterns, leaked secrets and libraries with known serious problems. For now it flags what it finds for us to review rather than blocking a change, and every finding is checked and fixed or explained.

Found a problem?

If you think you've found a security problem, please write to [email protected] with "Security" in the subject. Say what you found, how to see it happen, and what you think it lets someone do. A person reads every message. Our contact details are also published in the standard place, /.well-known/security.txt.

We fix what's real, tell you when it's fixed, and thank you by name if you'd like.
We'd ask you to keep it private for 90 days, or until it's fixed, whichever is sooner.
We're small and self-funded, so there's no bug bounty.
Test only with your own account and workspace: don't look at other people's data, slow the service down, or point automated scanners at it.

How we keep your data safe

On this page