The smallest access
the product allows.
A product that touches your documents has to hold itself to a high standard. Here are the concrete decisions, the trade-offs we chose on purpose, and the things we haven't locked down as tightly as we'd like — explained without spin.
Read-only, and never even marked as read.
A mailbox is the most sensitive thing you can connect to anything. It gets the narrowest treatment in the product.
Opened read-only, always
Mailboxes connect over IMAP with an app password and are opened in read-only mode. Findest can find matching attachments, but it can never send, delete, label, or move anything — and it doesn't even mark a message as read, so your unread count is exactly what you left it. Outlook connects through Microsoft's own sign-in with the equivalent read-only Mail.Read permission.
The app password is encrypted before it's stored
It's encrypted with AES-256-GCM, with a fresh initialisation vector every time and the key held in a separate secrets store rather than beside the data. A dump of the database on its own doesn't open anyone's mailbox. AES-GCM also authenticates: if the stored value were tampered with, decryption fails rather than quietly producing something that gets sent to a mail server.
An app password is not your password
It's issued by your provider, scoped to mail only, and revocable on its own — killing it doesn't touch your real account password or lock you out of anything else.
Revoke it whenever you want
Disconnect from Findest's Connections page, or remove the app password (or the connected app, for Outlook) directly from your provider. Either way access stops immediately, and nothing lingers.
The narrow permission where it exists, and the honest reason where it doesn't.
Google offers a narrow Drive permission and Findest takes it. OneDrive and Dropbox have no equivalent, so there we ask for more than the strict minimum — a real trade-off, and here's the actual reasoning rather than a reassuring sentence.
The narrow permission is only useful if the provider pairs it with a picker. Google does: you choose the folder in Google's own dialog, and that single choice is what Findest is granted. Without a picker, a narrow scope means an app-only folder — a Findest folder, not your folders.
On Google Drive we use drive.file, the narrow one: Findest only ever gets the folders you pick in Google's own picker, and the files it writes into them. On OneDrive (Files.ReadWrite) and Dropbox there is no per-folder equivalent, so the grant is broader and the folder browser reads folder names to show you your real tree.
What it doesn't buy: nothing already in your cloud is read, indexed, or catalogued. The access is used to list folder names when you're choosing one, and to create files where your rule says.
A connection is tied to the browser that started it.
When you connect a cloud, a one-time value is generated in your browser and kept there. Only its fingerprint travels onward, inside a signed hand-off, and it's checked again at the end with your session in front of it.
This closes an account-linking attack that a signed hand-off alone doesn't: on its own, a signed value proves that some Findest user began the flow, not that this browser did. Both halves are needed, and in the attack they end up in different browsers.
Every new connection also sends an email to your account address naming the provider and the account, so a connection you didn't make would surface the same day rather than never.
Isolated, encrypted, and genuinely deletable.
Per-user isolation at the database level
Every file is stored in private storage with per-user row-level security policies. No client can read or list another client's data, and that's enforced by the database engine rather than by the interface in front of it.
Cloud tokens are unreachable from the browser
The OAuth credentials for your cloud live in a table with no access policy from the browser at all: only an internal process with server permissions can read them, and only to perform the upload.
Platform secrets are encrypted at rest
The keys Findest itself depends on live in a dedicated secrets store, not loose in plaintext environment variables.
Servers in Europe
Database and processing are hosted in the European Union.
Real deletion, not deactivation
Deleting your account cascades to your documents, rules, connections, and history. You can also revoke any single cloud connection without deleting the account.
To be clear — what we don't do.
We never send, delete, or change anything in your mailbox.
We don't share or sell your documents to third parties, under any circumstances.
We don't use your documents to train AI models.
We don't archive anything until you've written the rule that allows it.
We don't read what's already sitting in your cloud folders.
What we'd tell you if you asked in private.
We hold no third-party security certification. No SOC 2, no ISO 27001. Those audits cost more than a product at this stage can justify, and claiming to be “enterprise-grade” without one would be marketing rather than security. If your organisation requires a certified processor, Findest is not currently that.
The cloud permission is broader than the minimum, for the folder-browser reason above. It's a deliberate trade-off, not an oversight — but it is a trade-off, and you're entitled to weigh it yourself rather than have it described as though it were free.
Findest is young. The security decisions on this page are real and implemented, but the product has not yet been through the volume of adversarial attention that an older product has. We'd rather say that than imply a track record we haven't earned.
Found a security issue?
Email [email protected] with what you found. We'd much rather hear about a problem from you than discover it ourselves later, and we'll reply.
GDPR by construction
Hosting and processing inside the EU means Findest was built under GDPR from the start rather than adapted to it afterwards. You can request access to or deletion of your data at any time by writing to the same address, beyond what you can already do yourself from your account.
Questions people actually ask
Can Findest read emails that have no attachment?
It reads messages in your mailbox to find attachments, and messages without any usable attachment are recorded as seen and ignored. Nothing about them is archived.
Does anyone at Findest look at my documents?
No, and per-user row-level security means the normal path can't return another account's data at all. Support can't browse your files.
Are my documents used to train AI?
No. Documents are sent to be classified and the answer comes back; they aren't contributed to model training.
What happens to my files if I delete my account?
Documents, rules, connections, and history are deleted with the account. Files already archived to your own cloud stay in your cloud — they're yours, in your folders, and Findest deleting its records doesn't reach into your Drive.
Do you have SOC 2 or ISO 27001?
No. See the candid section above rather than a softer answer.
See it for yourself.
Create a free account, connect one mailbox, and check the permissions on your provider's own security page.