Your customers' conversations, protected
Support data is some of the most sensitive data a business holds. ReplyX is built so isolation, encryption and least-privilege access are the default — not an add-on.
How it is built
Isolation, encryption and least privilege are the defaults
Not a tier, not an add-on, and not a policy document — each of these is something the code does whether or not anyone is watching.
Tenant isolation with RLS
Every workspace's data is separated at the database level with PostgreSQL row-level security. The application connects as a restricted role, so one tenant can never read another's conversations — enforced by the database, not just app code.
Encryption at rest for secrets
Provider keys and channel access tokens (Anthropic, Stripe, Meta and more) are encrypted with AES-256-GCM before they touch the database. They're decrypted only in memory at the moment they're used, and never returned to the browser.
Least-privilege access
Owner / admin / agent roles scope what each teammate can do, and agents can be restricted to specific products. Support access to a workspace is read-only, time-limited and fully audit-logged.
Verified integrations
Inbound webhooks are signature-verified (Meta X-Hub-Signature, Stripe signed webhooks). Payments are only confirmed by server-to-server callbacks — never by a browser redirect that could be spoofed.
Auditability
Sensitive operator actions are recorded in an append-only audit log — who changed a subscription, a setting, or accessed a workspace, and when. Secret values are never logged.
Reliability
A fair-scheduling queue keeps one busy tenant from starving others, rate limits protect the public surface, and errors are tracked so issues surface fast.
Isolation, demonstrated
The same question, asked as you and as somebody else
Not a promise that we filter by tenant. The rule lives in the database, so a query that forgot to filter still cannot reach another workspace.
replyx=> SET app.tenant_id = 'rupas-closet';replyx=> SELECT count(*) FROM "Conversation"; 1832 replyx=> SET app.tenant_id = 'some-other-shop';replyx=> SELECT count(*) FROM "Conversation"; 0 replyx=> RESET app.tenant_id;replyx=> SELECT count(*) FROM "Conversation"; 0
The third block is the one that matters. With no tenant set, the database returns nothing — not everything.
Most multi-tenant software keeps your data apart by remembering to add “where tenant = you” to every query. It works until one query forgets, and then it fails silently and in the worst possible direction.
Here the rule lives in the database. Postgres row-level security is switched on for every tenant table, and the application connects with a restricted role that those policies apply to — so a query that forgot to filter returns your rows and nobody else's, because that is the only thing the database will hand it.
The session on the left is the check, run against the real schema. The same question, asked three ways, with the answer coming from the database rather than from us being careful.
When we look
Read-only, thirty minutes, and written down
Almost every SaaS lets its staff log in as you, with your permissions, indefinitely, and tells nobody.
Sometimes we need to see what you are seeing to help you. Almost every SaaS handles this by letting staff log in as you, with your permissions, indefinitely, and telling nobody.
Ours is read-only and lasts thirty minutes. Every write is refused by the server — not greyed out in the interface, refused — so there is no version of it where someone changes your agent, your billing or your data while “helping”.
And the fact that anyone looked is written to an audit log with who and when. Access you cannot see is access you cannot check.
Read-only support session — expires in 27 minutes.
They try to change a setting
This is a read-only support session — changes are not allowed.
Refused by the server, not hidden in the interface.
And the looking itself is recorded
14:02 support@replyx.io · tenant.impersonate
14:29 support@replyx.io · session.expired
And what it does not do
The short list of things that never happen
Message content is never written to logs
Operational logs record that a call happened, to which provider, and whether it failed — never what a customer wrote or what the AI answered.
Secrets never come back to the browser
Provider keys and channel tokens are decrypted in memory at the moment of use. The console shows you a masked preview, never the value.
Support cannot change your workspace
An operator can be granted a read-only view for thirty minutes. Every write is refused, and the fact that they looked is in the audit log.
Deleting means deleting
Closing your workspace removes the conversations, contacts and knowledge with it — not a flag on a row we keep. What we are required to retain, and for how long, is written down.
Have a security question, or need a data-processing agreement for procurement? Get in touch — we are happy to walk your team through the details.
Judge it on your own conversations
Start free, connect one channel, and see how it handles the messages you would not want mishandled.
No card required · Free plan forever · Set up in minutes