Security
What we claim about security, and what we don't.
Written for the person who has to answer a client's security questionnaire. What's planned is marked as planned, without a date we can't stand behind.
Last reviewed 24 September 2026.
In place today
The baseline
- Sign-in
Google or Microsoft accounts only. No passwords, and no open sign-up: people join by invitation.
An invitation names the person, expires after 48 hours and stops working once it's used. Your own organisation's multi-factor authentication applies when people sign in.
- Hosting
One production service on AWS in London. The pilot runs on it.
The server has no open web port. Traffic reaches it through a Cloudflare tunnel that the server opens outwards. Administrator access is by SSH key from named addresses, or through AWS's own console behind multi-factor sign-in.
- In transit
Encrypted on every path: HTTPS to Cloudflare, then an encrypted tunnel to the server. Plain HTTP is redirected to HTTPS.
- Backups
Nightly database backups, encrypted before they leave the server, kept for 35 days in London.
The key that decrypts them isn't kept on the server.
- Your computers
Each member's computer holds the notes they can read, as plain markdown. Encrypting those disks is up to you: on a Mac, turn on FileVault.
- Separation
The server enforces access; the app can't grant itself anything. Stored content is tied to the vault it belongs to.
When someone loses access, their connection ends too, including their AI's.
- Pictures
A picture has exactly the access of the folder it sits in.
The AI boundary
Your AI is you, with a record.
Each person connects their own AI. synoia decides what it can reach, and keeps a record of what it changes.
- Scope
Your AI connects through synoia's MCP connector, signed in as you. It reaches every vault you can, checked on every call, and nothing more.
- Writes
It can write wherever you can write. How your people use AI is your organisation's decision.
- Record
Every write is saved in the person's name and the connection's, checked against the latest version of the note, and logged.
- No model
We run no AI model over your content.
- Your provider
What your AI reads goes to your AI provider, under your terms with them. Claude, for example, stores data in the US. Our London hosting covers the vault and the sync. The AI path is yours to choose and to declare.
What your AI client can do also depends on its plan. When we checked in September 2026, ChatGPT allowed connector writes only on its business plans.
Operator access
Who can read your notes
Our staff don't read your content. The honest limit: the service can technically read what it stores, because it has to answer your AI, and the people who run it could. We say so plainly rather than promise otherwise.
That's why synoia isn't end-to-end encrypted. A vault your AI can work with is a vault the service can read.
Who else is involved
The companies in the path
- AWS hosts the service and its backups, in London.
- Cloudflare sits in front of the service and carries its traffic. It decrypts traffic at its edge and re-encrypts it to our server.
- Google or Microsoft handles sign-in, whichever you use.
- Your AI provider sees what your AI reads. You choose it, under your own terms.
Planned
What we intend to do next
These are intentions, not yet built. Each moves to "In place today" when it's done.
- Per-company encryption keys, held apart from the database, so that a copy of the database alone doesn't reveal your notes.
- A full audit log covering deliberate reads and every write, including any access by our own staff, with a write-once copy kept for twelve months.
- Deleting an organisation's data from the service, with evidence that it's gone.
Limits
What we don't claim.
- Sovereign AI. The AI path belongs to your provider.
- That we can't technically read what the service stores.
- End-to-end encryption.
- A certification for synoia, or an independent penetration test. Neither has happened yet.
- That it suits material a contract, a client or government rules require you to keep off commercial cloud services.
Questions your security team will ask
Where is our data stored, processed and backed up?
On each member's computer, as plain markdown. On our side, in one production service on AWS in London (eu-west-2), with nightly encrypted backups kept in London for 35 days. Traffic passes through Cloudflare. What your AI reads goes to your AI provider.
Who on your side can read our content?
Nobody reads it as a matter of course. The honest limit is that the service can technically read what it stores, and the people who run it could. Server access is by SSH key from named addresses, or through AWS's own console behind multi-factor sign-in. A full audit log, including any access by our staff, is being built.
What can an AI client do, and can we restrict it?
Whatever the person could do: list, read and search notes, create and edit them, move and delete notes and folders, all within that person's access. To restrict an AI, restrict the person, or share less with them. Every write is attributed, checked against the latest version and logged.
How are organisations kept apart?
Logically, at the server. Every stored item is tied to its vault, and access is checked at the server against the person's membership, including for AI connections. Each organisation's data isn't yet encrypted with its own key; that's planned.
Can we take everything and leave?
Your notes are already on your computers. A vault removed from synoia stays a folder of markdown that Obsidian opens. Deleting your data from the service, with evidence, is planned.
When was your last penetration test?
There hasn't been one yet.
How do we report a vulnerability?
Email contact@synoia.app, beginning the subject line with SECURITY and a colon. Include what you found, how to reproduce it if you can, and which part it affects.
Ask us the hard questions.
Pilot members get straight answers from the people who build and run the service.