Security and data protection

Checks we have completed

Checks on 3 and 4 November 2026. Some concern the live service; the others were run locally, with fictional accounts and data, on the code then published. Here is what was tested and what the results establish.

On the live service

Published pages and files, 4 November. After each release, the public pages were loaded and the application’s files compared with the published version: they match. Without signing in, account access and backup copy requests are refused.

Scope of the check: This check covers what is served; it does not go through the application once signed in.

Backups, 3 November. The 3 November report showed no missing copies or failed verification. Reading and restoring copies were checked in an isolated environment.

Scope of the check: This check does not simulate a full production outage.

Email delivery, 3 November. An email sent from a test workspace arrived in Gmail. BonDossier received and displayed its Delivered status.

Scope of the check: This check covers one Resend delivery. It does not guarantee delivery of every message or cover bounces and complaints.

Sign-up and sign-in, 3 November. Trade demos, switching between French and English, and links to sign-up were checked in a browser. A new account and its first workspace were checked, with access through Google.

Scope of the check: First-time Microsoft sign-up and an external Microsoft business connection still need end-to-end verification.

Locally, with fictional data, 4 November

Account recovery. In a browser: a reset cuts the old personal access and an old API key is refused at once; the second factor is asked when it is on; cutting everything or removing a sign-in needs a recent confirmation. A security email interrupted by an outage goes out afterwards.

Scope of the check: A real Google or Microsoft sign-in was not reproduced locally.

Rights of people, agents and API keys. A workspace sees nothing of another; a hidden field does not come up in search; the history does not reveal a hidden record. A read-only person adds no note, file or task, and a guest shares nothing beyond read access. In these tests, an agent whose rights were removed while it worked wrote nothing afterwards; on the live service, removing rights can take a brief moment to apply everywhere.

Scope of the check: These tests cover known cases; they do not prove that no flaw exists.

Backup copies. Only the owner, after a recent confirmation, gets a read-only copy, and the original workspace stays intact. The original’s connections, keys and agents are not turned back on; writing, creating a key or connecting a mailbox is refused there; export works; other members’ private documents stay unreadable.

Scope of the check: Tests in a local environment close to the hosting; no real data was copied.

Outages and simultaneous operations. An interrupted copy starts over, with no half-filled copy visible; an old operation can no longer write into a copy already opened; two simultaneous requests make one copy; a deletion that fails is retried. Cutting access holds even in a workspace that does not answer.

Scope of the check: Outages simulated locally: they do not reproduce every production condition.

Malformed requests. Badly encoded addresses, cookies or file names are refused cleanly, with no server error and nothing stored.

Scope of the check: Known cases checked, not an exhaustive search.

These checks are performed by the BonDossier team, with the help of AI tools. They do not replace an independent security audit, which we have not yet completed.

Each workspace is separate

• Each workspace has its own database, apart from every other workspace’s. Accounts (email address, password, sessions) are kept apart too.
• The pages and the application are served over HTTPS. The host, Cloudflare, encrypts databases and files at rest.
• Passwords are never stored in readable form: only a hash is kept. Sessions are stored as hashes too, and the sign-in cookie only travels over HTTPS, out of reach of page scripts.
• You sign in with a one-time code sent by email, a password, a Google or Microsoft account, or your organisation’s single sign-on.

Two-factor authentication

• Enable it in Settings, My profile. Each new sign-in asks for a code from your authenticator app after your password, email code, Google, Microsoft or company single sign-on.
• The setup key is encrypted. Ten single-use recovery codes let you recover access if you lose your authenticator. Keep them separately: an email alone does not replace the second factor.
• Enabling it closes your other sessions. Previously authorised API and MCP access stays separate and can be revoked in its settings. Two-factor authentication is a personal choice; workspace-wide enforcement is not offered.

If someone may have used your account

• Resetting your password cuts the access opened in your name before the reset: Google or Microsoft sign-ins, assistants connected in your name, personal API keys and other sessions. Old keys are refused as soon as you reset; removing them from each workspace’s list can take a little longer. With two-factor authentication on, nothing is cut before the second factor.
• What belongs to a workspace is not cut: assistants with their own identity, webhooks, automations, connected mailboxes and Drive, and other members’ access. If someone else may have used your account, check them in each workspace.
• In Settings, Security, you see what is open in your name, and you can cut everything or remove a Google or Microsoft sign-in. These actions need a recent confirmation: a code sent by email, entered in this browser, and the code from your authenticator app if it is on.
• Removing a Google or Microsoft sign-in does not close the sessions already opened with it: the application says so and offers to cut everything at once.
• An email tells you when a Google or Microsoft sign-in is added or removed, and when access is cut.
• Email code requests and wrong passwords are limited for each address: past the limit, you wait before trying again. A code sent by email only works in the browser that asked for it. On a browser you have never used with this account, repeated requests by someone else can delay a code.

Access based on roles

• Four roles: owner, admin, member and guest. Managers set access per table, per field and per team, in Settings, Access.
• Managers can read the workspace’s activity log, including agents’ answers to members.
• A guest sees the workspace’s teams and members’ email addresses. A read-only person can comment on a record.
• An API key acts with the rights of the person who created it, never more. It can be read-only and can be revoked at any time.

AI agents work with your rights

• An agent works for one person, with that person’s rights: it sees and changes nothing more than they can. An agent can also be limited to some tables.
• What an agent prepares is a proposal. The CRM agent shows you each change to your structure before applying it, and an agent never applies an access rule: a person approves it.
• The Organization and Sales agents act on their own on tasks and notes, unless a manager ticks “Approve before acting”. A follow-up email only goes out if sending was turned on, and with “Approve before acting”, each email waits for your approval.
• Agents delete no record, field or table: they create, complete or rename. An applied change cannot be undone in one click: read the proposal before applying it.
• Every agent run is kept in its history, and you can stop it while it runs.
• AI protection, turned on by a manager in Settings: a coded check, then JEV, look at every email, note, document or record before an agent or a connected assistant reads it. The coded check spots invisible or encoded text and known attack phrasings, even when JEV does not answer; JEV judges the meaning of the rest. Text that gives orders to an AI is withheld, a fraud attempt is flagged, and when in doubt the agent changes nothing without your approval until its task ends. No automatic check is perfect: this protection lowers the risk, it does not remove it.

Your AI assistants and the API

• Claude, ChatGPT or another compatible assistant connects through BonDossier’s MCP connector, after an authorization you give (OAuth). You choose the workspace and the level: read only, or read and write.
• The assistant acts with your rights, never more, and can be limited to some projects. Through the connector it reads, creates and updates; it deletes nothing. Its changes are recorded under your name.
• Requests per connection are rate-limited. You can cut access at any time, in My agent access; a refresh token used twice ends the connection.
• Webhooks sent by BonDossier are signed: your tool can check that they come from BonDossier and were not altered.

What our providers receive

• Cloudflare hosts and runs the service: it keeps the databases, files and backups. It also provides the agents’ fallback model (Workers AI).
• Anthropic (Claude model) receives, for a request made to an agent, the request and the records and documents it needs, within your rights.
• Codiv (OpenJev model) receives the text of emails and notes to sort, and your requests to pick an operation your rights allow; BonDossier checks the operation before running it. When the AI protection is on, it also receives the contents an agent or a connected assistant is about to read, to spot hidden instructions or fraud.
• Resend receives the emails BonDossier sends itself (sign-in codes, notices): the recipient and the message. Messages sent from a connected mailbox go through Gmail or Microsoft 365.
• Stripe receives your payments; BonDossier never sees your card number. Google, Microsoft and the services you connect receive or provide what is needed for sign-in, the mailbox or the documents you choose.
• If you connect Google Calendar or Outlook, BonDossier reads events from your primary calendar after separate authorization: title, times, location and participants. Imported meetings stay private; the connection does not change your calendar.
• BonDossier does not use your data to train any model. What each service does with what it receives is governed by its own policy, on its own site (links above).
• Some providers process data outside the European Union, notably in the United States. The current list and the framework of these transfers are in the privacy policy (in French).

Backups, export and the end of a subscription

• Every workspace and the accounts are copied every day when they have changed. Each copy is encrypted by BonDossier before it leaves, then stored in the European Union, apart from the databases.
• One copy a day is kept for 7 days, then one a week up to 30 days; the newest always stays. Restoring the copies is checked on isolated copies, without touching your working data.
• A workspace owner can recover a backup as a copy, in a new read-only workspace, after a recent confirmation. The original workspace is not changed. The copy can be read, exported and deleted; nothing can be written in it.
• The copy does not bring back members, API keys, connections (mailboxes, calendars, Drive), webhooks, automations or agents. Other members’ private emails and documents cannot be read in it.
• You can export your data as CSV whenever you want (Settings, Import and export), or read it through the API.
• When a trial ends without a subscription, the workspace stays open for 7 days, then you have 30 more days to export or subscribe; two emails warn you before anything is removed.

What the BonDossier team sees

• The application gives the BonDossier team no access to the content of your workspace, unless you invite someone as a member. Its diagnostic tools show counts and fingerprints, to check a backup or a migration, not the content of your records or messages. The migration tools copy the content of a designated workspace into the new version of BonDossier, without displaying it.
• Your data is not end-to-end encrypted: the people who administer the hosting can technically access it.
• If a data breach affects you, we tell you without delay, and within 72 hours at the latest, with what we know and what we are doing (see the privacy policy, in French).

Dedicated hosting in Europe, on quotation

• An OVHcloud server reserved for your company, located in the European Union: this option is offered following a technical review and a quotation. It requires a separate setup and migration before it goes live and is not included in standard subscriptions.
• The quotation specifies the data hosted, backups and connected services. This option alone does not guarantee that AI, email or payment providers process data only in Europe. To discuss your needs: contact@bondossier.com.

Limits of the standard service

• BonDossier has no security certification and no independent audit.
• Workspaces created since November 2026 by a company located in Europe (European Union, European Economic Area, Switzerland, United Kingdom) run and are stored in the European Union, in Cloudflare’s European jurisdiction, as all backups are; a workspace created from another country is kept near that country. Workspaces created before stay where they were created until they are moved, and accounts (email addresses, passwords, sessions) are not confined to the European Union. Self-service installation on your own server is not offered.
• A backup never replaces a workspace in use: it can only be recovered as a read-only copy. A closed workspace can be restored from its backup by the BonDossier team, at its owner’s request.
• A security question, or a vulnerability to report: contact@bondossier.com. The legal details are in the privacy policy, the legal notice and the terms (in French).