Security and privacy
Last updated: 23 September 2026
The first thing a company asks before uploading its handbook and its contracts is where those files end up and who can read them. This page answers that in full, including the parts that are limitations rather than features.
How your documents are separated from everyone else's
Every organisation's content is separated at the query layer, not by convention. When someone asks a question, the search for relevant passages is filtered by organisation identifier before it runs. There is no request path that returns a passage belonging to another customer, because no search is ever issued without that filter in place.
The same applies inside your own company. Before a search runs, the system works out the exact list of folders that person is allowed to read, and searches only that list. A private folder they have not been granted is not searched at all — it is not searched and then filtered out of the answer, which is the arrangement that tends to leak.
Folder permissions and how inheritance works
A folder is open to your whole organisation by default. Make it private and you name the email addresses that may read it.
Permission is inherited down the tree, and deliberately in the strict direction: to read a folder, a person must also be permitted on every private folder above it. This means you cannot accidentally expose confidential material by creating an open subfolder inside a restricted one. Administrators in your organisation can read every folder, since they are the people who manage the documents in the first place.
Where your data is stored
| What | Where it lives | Why |
|---|---|---|
| The uploaded file itself | Cloudflare R2 object storage, in a private bucket | So it can be downloaded again by an administrator |
| Extracted text and search index | Supabase (managed PostgreSQL) | So passages relevant to a question can be found |
| Accounts, folders, permissions | Supabase (managed PostgreSQL) | To know who may read what |
| Questions and answers | Supabase (managed PostgreSQL) | So your administrators can review what is being asked |
| Payment details | PayPal — never on our systems | We never see or store a card number |
The storage bucket is private. Downloads are served through short-lived signed links generated per request, so a file URL cannot be forwarded and reused later.
Which outside services see your content
Answering a question requires sending the relevant passages to a language model. We use these processors, and no others, for that:
- Voyage AI — converts your document text into the numeric vectors that make search by meaning possible.
- DeepSeek — receives the question and the retrieved passages, and writes the answer.
- Google Gemini — receives scanned PDF pages, and only those, to recognise their text. It is not used on plans without scanned-PDF reading.
Each of these receives what it needs for that one request. None of them receives your whole document library, and none of them receives your account or billing details. The full list of processors, including infrastructure providers, is in the privacy policy.
Your documents are not used to train models. They are stored to answer your team's questions and for nothing else. They are not pooled with other customers' content and not used to improve any model.
What deletion actually removes
When an administrator deletes a document, the stored file, the extracted text and every search index entry derived from it are removed together. A deleted document stops being reachable by the chatbot immediately, because the passages it would have drawn on no longer exist.
The same happens automatically when a free trial ends without an upgrade: the documents, their index and the chat history are deleted. The account, the organisation and the member list remain, so upgrading later means uploading again rather than starting from nothing.
Accounts and sign-in
- Sign-in is handled by Supabase Auth. Passwords are stored hashed; we never see them.
- All traffic runs over HTTPS. The application refuses plain HTTP.
- The browser keeps a session token in local storage. It is not an advertising cookie and is not shared with any third party.
- An administrator can remove a member at any time, which ends their access immediately.
Who at BotClarify can see your content
We would rather state this plainly than leave it implied. Our system administrators can technically read stored documents and chat history, because operating and supporting the service requires it — diagnosing a failed upload, for example. That access is restricted to the people who need it, and the administrator console makes the scope of the role explicit to anyone granted it.
If your organisation handles material where that is unacceptable, do not upload it. We would rather lose the sale than have you discover this afterwards.
What we do not claim
BotClarify is a young product and it is worth being straight about where it currently stands:
- We do not hold SOC 2, ISO 27001 or any comparable certification.
- We do not offer a contractual uptime guarantee.
- There is no customer-managed encryption key or on-premise deployment.
- Answers are generated by a language model and can be wrong. Every answer names the document it drew on precisely so that anything important can be checked against the source.
If any of those is a requirement for you, tell us — it is useful to know what buyers are blocked on. Get in touch.
Reporting a vulnerability
If you believe you have found a security problem, please write to security@botclarify.com with enough detail to reproduce it. We will confirm receipt and keep you posted while we work on it. Please give us a reasonable window to fix the issue before disclosing it publicly, and please do not access, alter or retain another customer's data while investigating.
Related
- Privacy Policy — what we collect, why, and your rights over it
- Terms of Service — the agreement covering use of the service