Security
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.
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.
- 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, SES 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 AWS signature only proves AWS sent it — every customer's notifications are 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. |
Data residency
All customer data is stored in Amazon Web Services' Mumbai region (ap-south-1), for every customer regardless of where they are. Some subprocessors operate elsewhere — the full list, and what each one sees, is published.
What we do not claim
No SOC 2, no ISO 27001, no penetration test report — not yet. Saying so is more useful than a page of security theatre. If a certification is a requirement for you, tell us and we will be straight about the timeline.
Reporting a vulnerability
Please report security issues privately before disclosing them. We will acknowledge quickly and keep you updated.