For IT and the CTO
What you want to know before you approve Boldcaster
Boldcaster holds a company's strategy, numbers and performance reviews. Whoever has to approve that asks a few standard questions. Here they are, with the answers. What is not there yet is listed too.
Where is our data stored?
- The database is in the European Union, with Supabase in Ireland.
- AI analyses run at Mistral, a French company that processes in the EU. Employee names are replaced with a neutral label before anything goes to the AI.
- A few services outside Europe receive a limited part: Calendly and Stripe a name, an email address and a time, and Resend the address and content of the emails we send, such as an invitation or a reminder.
- If someone connects their own AI assistant, what they request goes to the provider of that assistant. That connection is off by default.
Who can access which data?
- Each organisation is isolated in the database itself, with row level security on every table. A request for another organisation's data returns nothing, even outside the app.
- Within an organisation the role decides what someone sees: owner, admin, management team, employee or external contributor. An external contributor only sees the tasks they are linked to.
- The owner switches areas on or off and decides which roles see each area. What is switched off cannot be opened, not even through an old link.
- A project can be private. Then only the people linked to it see it, and nothing from it leaves through a webhook.
- Who may assign which role is fixed: an admin cannot make anyone an owner or admin.
Is there two-factor authentication?
- Yes. Anyone can switch it on in their profile, with an authenticator app. When you set it up you get ten recovery codes.
- The owner can make it mandatory for the whole organisation. Anyone who has not set it up then cannot get into the app.
- That requirement is enforced in the database and not only on screen. A session without a code sees nothing from an organisation that requires it, not even directly through the API.
- The API and the AI connection work in such an organisation too. The code is asked when you approve the connection and when you create a key, and then counts only for that one connection.
- If someone loses their phone, they sign in with a recovery code, or the owner or an admin resets their two-factor.
- You can sign in with email and password, or with a Google or Microsoft account.
What happens when someone joins or leaves?
- A new team member gets an invitation by email and chooses their own password.
- Remove someone and from that moment they see nothing of the organisation. They only come back with a new invitation.
- An API key or AI connection belongs to a person and sees what that person sees. When the person leaves, the key sees nothing either.
- Every key and every connection can be revoked separately, by the owner or by the person themselves.
- What the person created stays: tasks, measurements and reflections belong to the organisation.
What can we connect, and what leaves the building?
- A REST API with a key per person. Read only by default; the owner chooses which areas can be requested through the API.
- A connection for AI assistants (MCP). Off by default. Creating or changing something takes two steps: the assistant first gets a proposal back and only writes after a confirmation.
- Webhooks: Boldcaster sends a signed message to an address the owner provides. It contains titles, statuses and ids, not descriptions, notes or the content of a reflection.
- Every call through the API or an AI assistant is in a log the owner can inspect. Sent webhooks stay in their own log for thirty days.
- Importing tasks from a Jira or ClickUp export happens in the browser, without AI.
Can we leave again?
- Yes. The owner or an admin exports everything from the organisation in one go, as Excel or as JSON.
- The file also states what is missing or failed, by name. An export that looks complete and is not does not exist.
- Attachments on tasks download separately, as a zip. Login details and keys are never included.
How do you know it is right?
- Automated tests run on every change, including checks on access rights.
- We check permissions by replaying them in the database: signing in as a user with that role and counting what they see.
- Changes to the database are numbered migrations in version control.
What is not there yet?
- Signing in through SAML, and creating and removing accounts automatically through SCIM.
- Signing in with a passkey (fingerprint or face). Supabase, which runs our sign-in, has offered it in beta since May 2026; we are waiting until it is stable.
- Self-hosting. Boldcaster only runs with us.
Is your question not listed?
Email it and you will get an answer from the person who built it: security@boldcaster.com