Where the boundaries actually are
Multi-tenant systems fail in predictable ways. These are the specific places we put the boundary, and why there rather than somewhere more convenient.
On this page
At a glance
- Tenant isolation is enforced by the database itself — a bug in our code cannot cross it.
- Every outbound message passes a consent, suppression and sending-identity check that nothing can route around.
- Opt-outs are one-way hashes, so they survive erasure without retaining anything readable.
- Credentials live in a managed secrets store and never reach a browser after they are set.
- Your administrator can export the whole workspace, or erase it, from the product — no ticket.
- Data is stored in Mumbai; AI replies are produced by our AI model provider outside India, on terms that exclude training.
- No certifications yet — and we say so, rather than implying otherwise.
Where the boundaries are
Each of these is a specific, checkable claim about where enforcement lives — not a posture statement.
| Control | How it works here |
|---|---|
| Isolation enforced by the database | Every row carries its owner. Row-level security policies are enabled and forced on every tenant-scoped table, and the application connects with a role that cannot bypass them — so a bug in application code cannot show one customer another's data. This is verified by tests that run against a real database, not by reading the schema. |
| Credentials are never copied | WhatsApp tokens, email-sending identities and your own provider keys live in a managed secrets store. The application holds a reference, and the value never reaches a browser after the form that set it. |
| Suppression contains no readable address | An opt-out is stored as a one-way hash. That is what lets it survive erasure of the person — without it, deleting someone who unsubscribed would silently make them contactable again. |
| Identity is merged only on exact matches | Email, phone number, or a signed link token. We never infer that two people are the same person from a similar name, and every merge is reversible with the losing record's full payload retained. |
| Webhook signatures are not enough on their own | A valid signature only proves our cloud provider sent it — every customer on that provider has notifications signed by the same certificate. We also require the topic to be on an allowlist, and default to rejecting anything that is not. |
| Everything is audited | Who did what, to which record, when — including the agent's actions and every time a rule refused one. |
| Erasure reaches everything, including the copies | Erasing a person destroys their messages, identities, memories, notes, the merge history that held a copy of their record, and the raw email files their messages were parsed from. Erasing a workspace walks every table in the schema — a table has to be argued into the short list of what survives, not remembered into the list of what goes. |
| Encrypted at rest, backed up, and gone on schedule | The database and every file store are encrypted at rest. Automated encrypted backups are kept for 14 days and no longer, so a deleted record leaves the backups on that schedule too. |
| Dependencies are audited on every build | Every push checks the Python and JavaScript dependency trees against known-vulnerability databases, and a high-severity finding fails the build. |
Data residency
All customer data is stored in Mumbai, India, for every customer regardless of where they are: the database, uploaded files, inbound email and backups. It is processed outside India in two places — our AI model provider, which produces the agent's replies, and our identity provider, which signs your staff in. Sub-processors are listed by category and country, with what reaches each, in the data processing addendum; the named list is available on request.
AI processing
When the agent replies, the conversation, the matching knowledge passages and the relevant catalogue entries are sent to our AI model provider and the reply comes back. We use it on paid terms, under which prompts and responses are not used to train its models and are kept only transiently for abuse detection. We do not train models on your data. The model is given nothing it did not need for that reply: no other customer's data, no other workspace, and nothing the agent's role was not granted — the allowlist of what it may read is enforced in code, not in the prompt.
Taking your data, or destroying it
Two things a workspace administrator can do without asking us. Both are permissions in the role editor, so you decide who holds them.
- Export produces one archive with a JSON file per table — every contact, conversation, message, consent record, deal, rule and setting the workspace holds, every column.
- Erase destroys the workspace: every row in every table, the files you uploaded, the channel credentials you connected, and refuses the organisation's next sign-in so nothing can quietly re-create it. It asks you to type the workspace name back first. What survives is listed in the response: opt-out hashes, and the account's own billing records, none of which name a person.
A single person is erased the same way from their record, and the response says what was destroyed and what was kept, with the reason.
What we do not claim
Reporting a vulnerability
Please report security issues privately before disclosing them. We will acknowledge quickly and keep you updated.
Questions we have not answered here?
Ask, and you will get a straight answer from the person who built it.