Security
Your customers' conversations,
and who can reach them.
Every claim on this page is something the product does today, and where a protection has a limit, the limit is written down next to it.
⚖
One tenant cannot read another. The database enforces it.
Every tenant's data sits behind rules the database itself enforces, and the application connects with an identity that cannot see past them. A missing check in the application is an ordinary bug in most products and a data breach in some of them. Here the request is refused one layer below the application, where a mistake upstairs cannot reach it.
Application-level checks still run on top. They are not a substitute: one of the two can be undone by a single careless change, and the other cannot.
- One workspace cannot read another's conversations.
- Checked on every request, a layer below the application.
- Not a setting anyone in the workspace can switch off.
◈
Stored in India
Messages, media and backups sit on infrastructure in India. There is no second copy in a cheaper region that surfaces during a procurement review.
⌨
We never hold your password
Sign-in goes through your Comsky account. Comsky Chat has no password field, no reset link and nothing to leak — the identity lives in one place, which is also the one place to disable when somebody leaves.
◔
Access down to a single line
A member can be restricted to specific numbers. The fence holds everywhere — the list, the thread, attachments and search results — not only in the places somebody remembered to check.
▨
Customer numbers can be masked
Separately from access, a member can be marked masked. They work conversations normally while phone numbers arrive redacted, and the contact editor refuses to save a redaction over a real number.
▤
Two logs, because they answer different questions
The audit trail records configuration changes — roles, connected channels, exports — and is admin-only, because it contains rows about the managers themselves. The activity log records what the team did to conversations and is open to managers. Merging them would have leaked one or hidden the other.
🔑
Credentials are encrypted or hashed, never stored plainly
Mailbox and Slack tokens, WhatsApp session material and connector auth headers are encrypted at rest, each under its own derived key. API tokens are hashed — an API token is shown once, at creation, and nobody including us can recover it afterwards.
↯
Webhooks are signed
Every delivery carries a signature, so your endpoint can tell our call from anybody who guessed the URL. Failures retry with a growing gap and an endpoint that keeps failing is disabled rather than retried forever.
⛒
Connectors cannot be pointed inward
A data connector calls an endpoint of yours. The address is checked against internal and metadata ranges when you save it and again on every call — a hostname that was public when the connector was written can be repointed later, and only the second check catches that.
The XML parser is written for the same reason: it will not follow a reference out of the document it was handed, so the classic file-reading and memory-exhaustion attacks against XML have no code path to travel down.
◷
We hold less than you would expect
Inbound WhatsApp media is relayed from WhatsApp rather than copied here, so this server does not become a duplicate of every photo your customers have ever sent. The trade is honest and stated in the product: once WhatsApp stops serving a file, it reads as media expired rather than silently breaking.