Security
Vroxy holds your customers’ conversations. Here is how that data is kept apart, who can reach it, and what we deliberately refuse to do with it.
Tenants are isolated at the boundary, loudly
Every conversation, visitor, message, and document belongs to exactly one workspace, and access is checked where the request enters — not by a silent global filter applied deep in the stack.
That is a deliberate choice. A default scope that quietly returns nothing hides a bug; an explicit check at the boundary turns the same bug into an error somebody has to fix. We would rather fail loudly than leak quietly.
The widget can’t be talked into more than it has
The key in your embed snippet is public by design — it is in the page source of every site running the widget, and it grants nothing but the ability to start a conversation.
An origin allowlist caps which pages may boot your widget at all. Identity claims are only trusted when signed with your workspace secret using HMAC-SHA256, and only a verified claim can unlock a tool that reads customer data. Unsigned claims are accepted as a convenience for display and are trusted for nothing.
Tokens are scoped, hashed, and shown once
API tokens are stored as a SHA-256 digest, never in plaintext, and matched with a constant-time comparison so a token cannot be recovered by timing the failures. The raw value is displayed exactly once, at creation. Tokens are scoped to a workspace and carry explicit read or write scope.
Permission is one question with one answer
Access is a named capability — docs.write, chats.read — resolved through
one code path used by the API, the dashboard, and the mobile app alike.
Unknown capability names raise in development and deny in production, so
a typo can never quietly become a permanent grant.
Nobody can act on a teammate who outranks them, grant a role above their own, or remove the owner’s seat. Every workspace change is recorded with who made it and when.
Data stays where you put it
Conversation transcripts, visitor identity, and documents live in our database and are not mirrored to third-party analytics, resold, or used to train anybody’s model. Tools that fetch from your servers are guarded against being pointed at internal network addresses. Deleted records are soft-deleted first so an accidental deletion is recoverable, then purged.
What we ask of you
Keep your workspace identity secret on your server, never in browser JavaScript. Give teammates the lowest role that lets them do the job, and use individual grants for the exceptions. Rotate API tokens when someone leaves. And keep the origin allowlist tight — it is the cheapest control on this page.
Security question, or something you think we got wrong? [email protected]. We would genuinely rather hear it from you.