It reads what you connect. It separates every member.
Here is exactly how that separation is enforced, and where it stops — including what we do not have. This page is written to be handed straight to a security reviewer. Every control below is one we can point at in the running code; every control we lack is named further down rather than left for you to discover in a questionnaire.
Four layers, and none of them trusts the request
One member's question can only ever reach that member's data. That is not a policy or a prompt instruction — it is enforced four separate times, in four different places, and the assistant is on the wrong side of all four.
-
The identity comes from a signed cookie, never from the request
Who you are is read from a signed session cookie and verified server-side. It is never taken from the body of the request, from a header a client controls, or from anything the model produced. On the corporate portal that address has already passed the active-membership check for your organisation before a single line of chat code runs.
A client cannot name whose data to read. There is no parameter for it.
-
Every tool is called with that identity
The assistant works by calling tools — search files, search inside documents, read a file, list recent email. Every one of them takes the session's address as its first argument, supplied by the server at the call site rather than by the conversation.
The model can supply a query. It can never supply a person.
-
Every query filters on it in the database
Each search carries the member's own address into its SQL:
WHERE email IN (<your address>, <the shared company key>)The only second value the union ever adds is the reserved shared-vault key described below — a sentinel with no in it, which is why it can never be a real login. Searches over chat, Telegram and WhatsApp history are filtered the same way, on the member's own address.
-
Reading a document by id is an ownership check, not just a filter
Fetching one specific document resolves it by id and owner together. If the id belongs to somebody else the row does not resolve and the call is refused — it does not fall back to a broader search, and it does not return a redacted stub. A guessed id is simply not yours.
→ { "error": "file not found (or not yours)" }Underneath all four, extracted text is written to disk in a directory keyed by the owner's address, so the filesystem layout mirrors the same boundary.
Two kinds of agent, and only one is sandboxed
The brief-writing agents run as a separate operating-system account with no administrative rights, against a read-only copy of the notes that has been swept for secrets first. The agents your portal can run today are the other kind — and we would rather draw that line ourselves than have a reviewer find it.
No privileges, no keys
The sandboxed account has no administrative rights on the machine — we verified it cannot escalate. It cannot read the application's environment file either: that holds the credentials and is readable only by root and the web process.
A scrubbed mirror, not the vault
Those agents see a separate published copy of the notes, owned by root and readable only by the agent group. The working vault the application writes into is a different directory they have no access to at all.
It hard-fails rather than leak
Before that mirror is swapped in, the publish step sweeps it for credential-shaped strings — tokens, access keys, assignments to anything named secret or password. If one survives the scrub, the run aborts and publishes nothing.
The line we owe you: the agents granted on this portal today are the second kind. They are scripts the server starts as the web application's own user — so they run with the application's own access to its configuration and to the extracted files, not inside the sandbox described above. The sandbox covers the brief-writing agents, and none of those is granted to anyone today. If a reviewer's question is "what can an agent reach", the honest answer is "whatever the application can", and the control that matters is the next paragraph rather than the account it runs as.
Every agent run started from the portal is forced into draft mode by the server, so it writes a brief for a human to read instead of posting to a live channel. The assistant itself is held to the same shape: it can send an email from your own mailbox only by passing back a draft you reviewed and confirmed in the conversation — it cannot compose and send freely.
A six-digit code, to an address on a domain you registered
Your portal is its own host with its own member list. Sign-in is an email code — no password to leak, and no shared account. That is the whole mechanism today.
The code only goes to your company
A code is sent only when the address's domain is one registered to your organisation. Everyone else gets the same neutral response, so the sign-in form cannot be used to discover who does or does not work for you.
Matching is exact, not a suffix test
The domain must equal a registered domain exactly. A lookalike that merely ends with yours — the classic yourcompany.com.attacker.com — does not match, and neither does an unregistered subdomain.
The gate fails closed
If the portal host cannot be resolved to an active organisation — a database error, a suspended account — the request is denied. It never falls through to the consumer site, and the membership check answers "no" on any error rather than defaulting to yes.
Your staff are not consumer accounts
Verifying an employee writes to your organisation's member list and deliberately never to the consumer membership table, so a corporate sign-in can never become a paid account on the public site. Agent access is private by default: an employee sees nothing until an admin grants it, and the grant list comes back empty on any error.
Encrypted in transit. On disk, only in part
This is the question most often answered vaguely, so here is the precise version — two columns, and the second one is real.
- In transit. HTTPS to the site. The language-model proxy is bound to the machine's own loopback address and is not reachable from the network.
- Google refresh tokens. Encrypted at rest in the database, with the key held outside the table that stores them. These are the credentials that would let someone re-read your mailbox, so they get the strongest treatment we apply.
- Database backups. Dumped, compressed and AES-256 encrypted nightly, then pushed off the box. The passphrase is deliberately never uploaded alongside them and is held separately, so the off-box copy is unrecoverable ciphertext on its own.
- Document and email text. The extracted plain text of everything ingested sits unencrypted on the server's disk.
- Database contents. We checked this rather than assumed it: the filesystem carries no full-disk encryption layer, and the database reports zero encrypted tablespaces. Chat history, the generated notes and the file index are stored in the clear.
- The layer underneath. Whether the cloud provider encrypts the underlying volume at its own platform level, we have not verified — so we do not claim it. If that matters to your review, treat it as unanswered rather than as a yes.
One server, one region, no choice of region
There is no cluster here to describe. Everything runs on a single machine, and a residency question has a one-word answer today.
- ProviderOracle Cloud Infrastructure
- RegionMumbai, India — one region, one availability domain
- FootprintOne virtual machine. The website, the portal, every database, the model proxy, the extracted document store and the local backups all live on it.
- ReplicaNone. No standby, no failover, no second region.
- Residency optionsNone. You cannot choose where your data is stored.
So the answer to the question that usually follows: if your data must stay in the EU, the answer today is no. We would rather say that on this page than in week three of a procurement review.
Who else sees it, named
An assistant that reads your documents has to send them somewhere to think. These are the parties involved, and there is no per-tenant switch to turn any of them off.
Anthropic
Your content is sent to Claude as prompt data — that is how the assistant answers questions about your documents at all. It goes out through a proxy running on our own machine, on a Claude subscription rather than a per-call API account.
Drive, Gmail and Analytics, for the accounts each employee connects themselves through your organisation's own OAuth client. Access is whatever that employee granted, and a disconnect removes the stored connection.
ElevenLabs not on the corporate portal
Speech-to-text and text-to-speech for the voice assistant — which exists on the individual product and not on the corporate portal. That surface is text-only today, so if your employees use the portal, ElevenLabs sees nothing of yours.
DeepSeek
If the primary path is unavailable, a degraded turn can be answered by a secondary model provider. A key for it is configured on the live system, so this is a real path rather than a theoretical one: your content can reach a second model vendor when the first is down.
Sites the assistant reads
If someone asks it to read a link, it fetches that page, and the request goes to whoever runs that site.
Us, with root on the box
We run the machine, so we can read what is on it, and there is no in-product trail of administrative access. Dressing that up would be dishonest. If that boundary is unacceptable, the section below is the version where you hold the machine instead.
What we do not have
The most important block on this site. If one of these is a hard requirement, you have your answer without spending a call to get it.
Absent today — every one of them
- No certification of any kind. No SOC 2, no ISO 27001, no HIPAA, no penetration-test report. There is no trust centre and no badge to show you, because there is nothing behind one.
- No data-processing agreement, and no published sub-processor page. The list in the section above is the closest thing that exists, and it lives here rather than in a signed document.
- No SSO, SAML, SCIM or directory sync. Sign-in is a six-digit email code. There is no identity-provider integration and no automatic provisioning from your directory.
- No customer-visible audit log. Nothing shows an admin who asked what, which documents the assistant opened, or who ran which agent. We will not call the product auditable, because that log does not exist.
- No self-serve offboarding. The member record has states for suspended and removed, and no part of the application ever writes them. Removing a leaver is a request to us and a manual change on the server today — which also means anyone with an address on your registered domain who signs in once stays enrolled until we act.
- No self-serve export or erasure workflow. A member can disconnect an account and remove a vault source, but nothing purges the extracted text, the generated notes, the chat history or the summary built from them. There is no right-to-erasure button, and we are not going to imply one.
If that answer isn't enough, run it yourself
Every limit above follows from us holding the machine. There is a version where you hold it instead. Yours to run. Yours to audit.
Open source, AGPL-3.0
The stack is public. The repository ships a Dockerfile, a compose file, install notes, the database schema and tests. It is a published snapshot of the project, and we have not diffed it line for line against the copy running on our server — so read it as the source, not as a mirror of our production box.
What we are not promising
We have not run the installer end to end against a fresh environment, so we will not quote you an install time. There is no supported on-premise edition, no enterprise self-hosted plan and no deployment service behind this.
It is source you can read, audit and run. That is the whole claim.
Bring your security reviewer to the call
This page is the questionnaire answered in advance, so the call can start from facts instead of assumptions. Bring the person who would otherwise send us a spreadsheet — the sharp questions are the useful ones, and the honest answer to some of them is still no.