A policy text is cheap. The locks sit in the database, and each one is proven by a test.
We do not mirror your systemsThey are read when someone asks, or when an automation you have approved runs. Nothing is written to them unless a person has approved exactly that action, or an admin has signed a mandate that covers it.
Not even your admin reads a colleague’s chatConversations are private to each user, and the database decides it.
Nothing runs unloggedA call to your systems that cannot be written to the audit log fails instead.
How the platform treats your data: what we store, where it is, who reaches what, and which mechanisms enforce it. Last updated 2026-10-08.
Three locks, and the proof of each
What sets this platform apart is that the locks sit in the database and are proven by tests: for each of them there is a test that tries to get past it. The tests are to be green before a stage of development counts as done. The automatic run at every code change, however, is not in order today, so it is our working routine, not a machine, that sees to it that they are run.
Customer isolation is the database’s job, not the app code’sProven by a testRow level security is switched on and forced on every customer table. The test suite signs in as users in two different customer environments and proves, table by table, that one’s data does not exist for the other, also through the application’s own code paths. Nor can we as the supplier read a customer’s data through the app, except in the time-limited support mode the customer’s owner switches on (section 3). The app asks as the signed-in user, and the privileged database role, which scheduled runs for example need, is confined to named server modules. A test raises the alarm if any file outside them touches it.
The privacy of conversations is proven, not promisedProven by a testA test signs in as an admin and tries to read, write in and take over a colleague’s conversation. The database answers with nothing, every time.
Nothing runs unloggedProven by a testA tool call to your systems that cannot be written to the audit log fails rather than runs unlogged. The rule sits in the call chain, not in a description of routine, and the receipt is written before contact is made.
1. What we store, for each customer
Each customer (tenant) is its own, strictly bounded unit in the system. What we store for you:
Integration credentialsFor example your Shopify token. They are kept in a separate secrets vault, never in the database. The address of the vault entry is worked out in our server code from your customer id and the connection’s identity, never from a stored path or anything the browser sends, so nothing stored can be pointed at someone else’s credentials. A credential is never shown again after the connection is made, not even to your own admin, and it is masked out of error messages and logs.
Business dataWe do not copy your connected systems in the background. A system is read when you connect it and the connection is tested, when someone asks a question, and when an automation you have approved runs. What is saved is what the work leaves behind: answers with their value, time window and source references, receipts of reads and actions, and the content you create or bring in yourselves (the wiki, governed definitions, skills, automations, tables, files you upload or have created, and files you read from GitHub). A table can hold data from your systems, but only because a person put it there or an automation you approved wrote it there. The audit log holds the names of the arguments (never their values) and result excerpts of at most 2 000 characters, masked as the row on personal data below describes and readable only by your own admin and owner.
Writes to your systemsThe tools the assistant calls can only read. When something is to be changed or sent, for example an email, a Slack message or a draft order, it happens as an action: the platform builds an exact preview from the live system, and the named person confirms just that one, once. An automation writes only within the manifest an admin has signed, with a ceiling per action, and a new automation that sends something outward starts with every such action in a review queue where a person approves. An unclear outcome is recorded as unknown and is never done again automatically. The platform’s own notices about waiting approvals go only to a Slack or Teams channel an admin has connected, with fixed text and a link back here.
Conversations with the assistantPrivate to each user. Not even your admin can read a colleague’s conversation. For oversight your admin sees in the audit log who asked which question (at most 500 characters) and metadata about the answer (model, tokens used, number of sources of each kind), but never the answer’s content and never the whole thread. So a personal memory the assistant repeats in an answer can never leak into the audit log. Files you upload in the chat, and files the assistant creates for you, only you can read.
Personal memory notesThe user writes them, in the memory row beside the chat. The assistant cannot save a note for anyone, and that is deliberate: a note is read back into the assistant’s instructions at every later question, so a text the model itself worded would be the model writing its own instructions. Notes are never shared with colleagues, and their content never reaches the audit log, which shows only that a note was saved or deleted.
Audit logsEvery governed action (tool calls, actions on your systems, approvals, searches in protected spaces, questions to the assistant, support mode) is logged with actor, time and outcome. When you write the row yourselves the database stamps the actor from your signed-in session, and the client cannot name anyone else. The rows the platform writes for you (outgoing calls, fetched pages) are stamped instead by our server code with the same verified user id, precisely so that a member cannot create them themselves.
Personal dataIt is masked in four places: in the audit log, in the automations’ run log, in the receipts and in what is sent to the language model. Fields a connection has expressly pointed out as personal data are masked exactly. Beyond that the platform looks in free text for email addresses, phone numbers, Swedish personal identity numbers and card numbers or IBAN. For names and street addresses it deliberately does not look in free text, because that cannot be done reliably, so they are masked only where a connection has pointed out the field. What is actually to be carried out is not masked: an email must have its recipient, and your automation code must be able to reach the customer it works for. A value can be let through to the model only expressly, in an automation’s approved manifest or through a temporary permission you give yourself in the chat (15 minutes, for the data it names), and never to logs, receipts or the audit log. The question you write in the chat yourself is your own words and is not masked.
The assistant’s ordinary answers are preliminary, and marked as such.
A governed figure exists only as an answer the metric engine has worked out from an approved definition. The model’s own prose can never become such a figure, however sure it sounds: the database derives the marking from the answer’s source references, so it cannot be claimed into being. Preliminary answers are material to think with, never shared truth, and they cannot be fed into an automation, a governed definition or a wiki page without a person approving it.
This we would rather say plainly
If you ask the assistant to remember something in the chat, two things happen: it cannot, and the sentence you wrote is still your question, and questions are logged (at most 500 characters) for your admin’s oversight. If you want something never to stand in the audit log, write it straight into the memory row instead of asking for it in the chat.
Today the assistant itself writes text that leaves the platform: drafts of emails and Slack messages, its own search queries in the wiki, and arguments to reads in connections you have built yourselves. Nothing that changes anything in your systems is sent until a person has confirmed exactly the preview that is shown. Reads and searches, however, need no confirmation, and so a malicious model could in theory carry out something it has seen, for example from a personal note, in a search query or in an argument to a read. We say so plainly instead of pretending the channel does not exist. It is bounded: a search query is at most 300 characters, goes only to our supplier of search indexing and is visible to you in the answer’s receipt, while your admin’s audit log shows only its length. An argument to a connection you have built is checked against the connection’s declared schema and goes only to the address the connection was approved for. When the model points out an object in a pre-built connection it chooses no characters at all: it hands back a reference the platform itself gave out. And a web page is fetched only if you yourself wrote its address in the conversation, or within a research approval you gave: for a session of at most an hour, or for one task you asked it to do independently, the assistant may follow links from the page you approved, and then only links the platform itself found on a page it fetched under that approval. No other address is fetched.
2. Where your data is
Database and storageSupabase (Postgres), region EU.
ApplicationPlanned: a server of our own in Google Cloud, region EU. It is not in operation yet. Until it is, nothing is served to customers from it, and this row describes what has been decided, not a running service.
Secrets vaultGoogle Cloud Secret Manager, region EU. The planned server reaches it with its own dedicated service account, with no stored Google key.
This we would rather say plainly
AI inference does not happen in the EU. The language model (Anthropic Claude) is called through Anthropic’s API, which processes calls in the USA or globally. The same holds for OpenAI’s API for search indexing (embeddings). We offer no alternative with EU-only inference today. If you require inference to happen within the EU, the platform is not right for you yet, and that answer we want to give before the contract instead of after. What is sent to the model is the question and the material needed for the answer, with personal data masked as far as section 1 describes, and nothing is used for training (see section 4).
3. Who reaches what
Roles, and a personal account behind every actionAccess follows the role (owner, admin, approver, editor, member). Every action is tied to a personal account: the database stamps the actor from the session, so nobody can act in someone else’s name.
The application asks as youThe application asks the database as the signed-in user. Row level security in the database decides what comes back, also for the AI assistant’s searches: what a user may not read can never reach their answer.
Four eyes, and the owner’s own signatureGoverned definitions, skills, automations and connections you build yourselves require four eyes: the one who proposes cannot approve. The exception is the company’s owner, the highest role, who may approve their own proposals, because the product is also sold to one-person companies. Such an approval is permanently marked as self-certified, and the audit log shows which role approved: honesty rather than pretended control. Every other role meets four eyes, also an admin who is alone in being able to approve.
We as the supplier, and support modeWe work against the system through the same locks and are not members of your company. We can read with you only in support mode: your owner switches it on (it is off from the start), one of us starts a session with a stated reason for 30, 60 or 120 minutes, and every page we ask to see becomes a row in your audit log under our own identity. Support mode reads only what every member with you may read, never conversations, memory notes, files, personal connections, settings or the audit log, and it cannot chat, call your systems or change anything. If the owner switches it off, every session in progress ends at once. Administrative access to the operating environment is governed by the data processing agreement.
4. Training on your data
None. Anthropic does not train models on API data by default, and OpenAI does not train on API data by default. Both suppliers’ own terms are linked in the list below. Nor do we train any models of our own on your data.
5. Deletion and retention
While the contract runsYour data is kept as long as the contract runs, with two automatic exceptions. The content of files (uploads, files the assistant or an automation has created, and exports) is deleted after 30 days and the record of the file after 24 months. The content of what comes in to an automation’s webhook or email address is deleted after 30 days. Beyond that there is no automatic time-based removal in the current version, not of the audit log either, and you yourselves own what is written and deleted in the wiki, definitions and skills.
At terminationExport of your data on request, then complete deletion within 30 days. Every customer table hangs by cascade on the customer’s root row, so the database part is built to disappear in one operation, not through a manual hunt. Your integration credentials in the vault are deleted as a step in the same wind-down.
This we would rather say plainly
Deletion at termination is a commitment from us, not a finished function. In the current version the database refuses to delete a workspace that still has members, among other things because a workspace must never be left without an owner. The cascade exists, but the wind-down flow that takes care of it is not built yet.