Security
What the platform actually does, rather than what it aspires to. Where a control is absent or is a deliberate trade, it says so.
Separation between venues
Every record carries the venue it belongs to, and the database itself enforces the boundary through row level security policies on all 56 tables. A query that forgot to filter returns nothing rather than everything.
This is deliberately two layers. The application filters, and the database refuses. Both exist so that a mistake in one is not a data leak. The application connects as a database role that is neither an administrator nor the owner of the tables, because either would be exempt from the policies and would leave them in place but inert. A deployment check refuses to pass if that is misconfigured.
Customer profiles are never shared between venues and nothing is inferred across them, even where the same telephone number contacts two.
Encryption
In transit, TLS 1.2 or above. At rest, through the encryption provided by the managed database and object storage. Credentials for messaging and for venue systems are held in a secrets store, encrypted, never in an ordinary database column, and can be rotated without downtime.
Who can see what
Access is denied by default. A permission not granted by an assigned role is refused, and it is refused by the operation itself rather than by hiding a button, so knowing a URL gains nothing.
Roles are narrow on purpose. Floor staff see the booking list with contact details masked to the last digits of a number. Playing a call recording is, for some roles, permitted only with a stated reason, and the reason, the person and the time are recorded permanently.
Aimatric staff do not hold routine access to your customers' conversations or contact details. Support and onboarding roles are scoped to the venues they are assigned. Elevated access is granted against a stated reason and expires automatically within a day. The role that administers the platform is deliberately not the role that can read conversations at will.
Multi factor authentication is switched off in this deployment. The console is password only. This is a deliberate decision for the current pilot, not an oversight, and it is the one control on this page that is weaker than the platform supports. It is a single configuration value to restore.
What is recorded
An unchangeable log of every configuration change, every manual booking action, and every access to a recording or a transcript, with who, when and from where. Venue owners can read their own. It cannot be edited or deleted by anyone, including us.
Data that is never held
- Payment card details. Excluded by design, which keeps the platform outside PCI DSS scope entirely rather than merely compliant within it.
- Voice biometrics. Nobody is identified by their voice.
- Identifiers in transcripts and logs. Telephone numbers, card patterns and government identifiers are stripped before anything is written down.
Where data lives
Indian venues are served from Indian infrastructure and Malaysian venues from Singapore or Malaysia, with no routine copying of personal data between regions. One deployment serves one market.
Two things do leave: delivering WhatsApp messages involves Meta, and the language understanding currently used runs outside both markets. Both are listed on the sub-processors page with what they receive.
Retention
Recordings, transcripts and profiles are deleted automatically at the end of their period by a scheduled job. A deletion that fails is treated as an incident, not a warning. Nobody has to remember.
Untrusted input
Everything a customer says, and everything read out of a venue's own system, is treated as data and never as an instruction to the assistant. Attempts to redirect its behaviour are refused and logged.
The defence that matters here is structural rather than clever: the language model cannot authorise anything. It cannot select a table, write a booking or reach a customer record. Those decisions are made by ordinary code, and anything the model proposes is re-checked by that code before it is acted on.
What we do not claim
No third party certification is claimed. There is no ISO 27001 or SOC 2 report, and this page should not be read as implying one. An independent penetration test is planned before the first production venue and is not yet complete.
Reporting a vulnerability
Write to security contact not set with enough detail to reproduce it. We will acknowledge, keep you informed, and will not pursue anyone who reports in good faith and does not access other people's data.