Security architecture

This page shows how the platform is protected, with a diagram for each part. It describes what each control does, not how it is built. Suppliers are named by the job they do; the sub-processor list names the categories and regions.

​

Trust boundaries

Every request crosses the same boundaries. Traffic is encrypted between each hop. A request from your team is checked for a signed-in user and a workspace, a message between our own services is checked for a valid signature, and the database itself refuses rows that belong to another workspace.

​

Tenant isolation

Each customer is a workspace. Isolation is enforced twice: the application checks that the signed-in user belongs to the workspace named in a request, and the database applies row-level security so a query can only ever return that workspace’s rows. A mistake in the application layer still cannot return another customer’s rows. Recordings in file storage are protected by the same per-workspace access rules.

​

Secrets and environments

• Credentials you connect, such as messaging tokens and calendar or email sign-ins, are stored in an encrypted vault. The ordinary database row holds only a marker, so a copy of the database alone does not reveal them.
• Platform secrets are never kept in source code or written to logs. They are injected into the running service at deploy time.
• Production and test environments are separate. Production credentials and customer data never flow into test or development, and test data is synthetic.

​

Staff access and step-up sign-in

Our own staff follow least privilege. Production access is limited to a small set of named people, and every platform administrator must have two-factor authentication.

• Step-up for cross-workspace actions. An administrator acting outside their own workspace must have completed a second factor in the current session. A password-only session is refused, even for an administrator.
• Staff reads are logged. When a platform administrator opens a recording, a transcript, a contact or an export for a workspace they are not a member of, the access is written to a log first. If the log entry cannot be written, the recording is not opened.

​

Audit trail

Changes to agents, knowledge bases, phone numbers, team members, roles, permissions and workspace settings are recorded in an append-only audit log with the person who made them and when. Workspace owners can review their own log in the app.

​

Approval before an agent change goes live

A workspace owner can switch on Approve agent changes. From then on, an edit to an agent’s instructions or settings is saved as a draft and does not reach callers until a second person approves it. The person who made the edit cannot approve their own change, and every step is written to the audit log.

​

Signed messages

• Between our services. Messages from the voice engine to the rest of the platform, such as a tool call during a call or the report when a call ends, are signed and checked. An unsigned or altered message is refused.
• From us to you. When an agent calls your own systems through an HTTP tool, the request is signed so your endpoint can prove it came from us. See Signature verification.

​

Browser protections

Our web origins use HTTPS only, with HTTP Strict Transport Security. A strict content security policy, which limits the scripts a page may run, is in report-only mode: browsers report anything it would block, and we will switch it to enforcing once those reports are clean.

​

Related pages