How we protect your documents

Last updated July 17, 2026

1. At a glance

2. Access to your files

When you connect a cloud drive, surfawiki asks your provider for the narrowest permission that lets us read documents. We request these scopes and no others:

You choose which drives or folders to expose, and you can disconnect a source at any time from your dashboard. Because the grant is read-only, no bug, misconfiguration, or compromise on our side can alter the files in your drive. Your originals stay exactly where they are — surfawiki builds its wiki alongside them, never in place of them.

3. Where your data goes

This is the complete path a document takes through surfawiki:

1. You authorize a source. We store an access token for your drive, so we can read the folders you chose. Nothing is copied yet.
2. We read and index. surfawiki reads the documents, extracts text (including OCR on scans and drawings), and writes an index into storage reserved for your workspace.
3. You ask a question. We search your index — and only your index — to find the passages most likely to answer it.
4. An AI provider writes the answer. Your question and the relevant passages are sent to the model provider named in Sub-processors, which returns the answer with citations. The provider does not retain your content to train on it.
5. The answer is cited back to your files. Every claim links to the document it came from, so you can check it.

4. Workspace isolation

A workspace is the boundary around your data. Your documents, your index, and the facts surfawiki derives from them all belong to exactly one workspace.

Enforcement happens on every request: your identity is resolved to a workspace before any data is read, and if we cannot resolve one, the request is refused rather than defaulted. Document storage is physically separated per workspace on disk, and searches and AI answers are scoped to the requesting workspace.

We back this with an automated test suite that runs on every change to the codebase. It checks, among other things, that a fresh account never inherits another account's data, that unauthenticated requests to data routes return an error and never content, and that every API route in the web application authenticates before forwarding a request. We would rather show you the tests than ask you to trust an adjective.

5. Authentication & API keys

Sign-in is handled by our identity provider, which supports passkeys and two-factor authentication. Your password is held by that provider and never reaches us. Sessions use signed, expiring tokens whose signature, issuer, and expiry we verify on every request.

API keys let your own tools and scripts query your wiki without a browser session. Each key:

• is generated from 256 bits of cryptographic randomness;
• is stored only as a one-way hash — we cannot recover or show you the key again, which is why we display it exactly once at creation;
• is scoped to a single workspace and a single role, so a read-only key can never write;
• records its own last-used time, so you can spot a key you have forgotten about;
• can be revoked instantly, and revocation takes effect on the next request.

Roles. Members of a workspace are viewers, editors, or admins, and every route checks the role before acting. Requests are rate-limited to blunt brute-force and scraping attempts.

6. Encryption

In transit: every connection to surfawiki uses TLS. Every call we make to a cloud provider or model provider uses HTTPS.

At rest: your documents and index live on encrypted persistent disks provided by Google Cloud, using their platform-managed keys.

To be precise about the limits of that: this is infrastructure-level encryption, not application-level encryption with keys you hold. It protects against physical media compromise at the hosting layer. It does not mean your documents are individually encrypted with a key only you control — no managed cloud service that has to read your files in order to index them can honestly claim that. If you need keys you hold, the local and air-gapped configurations exist for exactly that reason.

7. Sub-processors

These are the third parties that may process your data, and what each one touches. We will update this page before adding a new sub-processor that handles customer content.

Every model provider above operates under terms that prohibit training on the content we send them, and each retains it only briefly, if at all, for abuse monitoring. We route between them for capacity and cost; the content each one sees is the same — your question and the passages we retrieved to answer it.

If you supply your own model API key ("bring your own key"), your content goes to the provider you choose instead. We enforce an allowlist of permitted providers; requests to providers outside it are blocked.

8. What we learn across customers

surfawiki gets better at organizing a kind of document as it sees more of that kind. That improvement is meant to travel; your content is not.

What crosses between customers is structural: that a document type tends to contain certain sections, that a category of file usually relates to another, that a term of art means what it means in a given industry. Before any learned pattern is stored, it passes through a filter that strips project labels, prices, and quoted passages.

We will be straight with you about the shape of this guarantee. The filter is mechanical for the categories above and it is not infallible — a general-purpose scrubber cannot prove a negative about free text. This is an area we are actively tightening, and it is the reason we support local and air-gapped configurations for work where the answer must be "nothing leaves, ever." If cross-customer learning is not acceptable for your data, tell us and we will disable it for your workspace.

9. What we haven't done yet

Most security pages only list strengths. Here is the other half, so you can make an informed decision:

We would rather you learn these from us than discover them later. If any of them is a blocker for your use case, write to us and we will tell you honestly whether and when we expect to close it.

10. Reporting a vulnerability

If you believe you have found a security issue in surfawiki, please email security@surfawiki.ai with enough detail to reproduce it. We will acknowledge your report within two business days and keep you updated until it is resolved. This contact is also published in machine-readable form at /.well-known/security.txt.

We will not pursue legal action against anyone who reports a vulnerability in good faith, acts in a way that respects the privacy of other users, and gives us a reasonable opportunity to fix the issue before disclosing it publicly. We do not currently run a paid bug-bounty programme, but we will credit you if you would like us to.

This page describes our security practices as of the date above and is not a warranty. No method of transmission or storage is perfectly secure, and we cannot and do not guarantee absolute security. See our Privacy Policy and Terms of Service for the governing terms.