Security

Tenant isolation

Every record in the platform is scoped to an organization_id. Requests resolve a tenant before any query runs, and that resolution is server-side — it comes from your session, a verified custom domain or subdomain, or an audited impersonation token. A client cannot ask for another tenant's data by changing a request parameter.

Recordings and other media live in per-tenant private storage buckets. Nothing is public-readable; files are reached only through short-lived signed URLs issued to an authenticated user in the owning tenant.

Authentication and authorisation

• Sessions are JWT-based. Every API request verifies the token before the route runs.
• Multi-factor authentication (TOTP) is available to all users, and an organisation can require it for everyone in the tenant.
• Roles run agent → supervisor → org admin → billing admin → tenant admin → owner, and are enforced on the server, not just hidden in the UI.
• Platform authority is separate from tenant authority. A tenant can write its own members' roles, so tenant role is never accepted as proof of platform access — platform staff have a distinct platform role stored outside tenant control. This closes an obvious self-elevation path.
• Support access to a tenant happens through an explicit impersonation flow. It is written to the audit log every time and shows a persistent banner in the UI for the duration.

Encryption

• All web and API traffic is TLS 1.2 or 1.3, with HSTS enabled.
• Data at rest is encrypted by the managed database and object storage layers.
• Stored infrastructure credentials — for example media server access details — are encrypted with AES-256-GCM using a key held only by the application tier.
• Machine-to-machine channels between the application and media servers are HMAC-signed with timestamped signatures, so a captured request cannot be replayed later.

Credential separation

Media servers handle SIP and RTP and are therefore internet-facing, so they never hold your integration credentials. When an AI agent on a call needs to touch your calendar, sheet or CRM, the media server calls back to the application over the signed channel and the application performs the action with credentials it alone holds. The set of callable operations is allowlisted, and the tenant is resolved on the application side rather than taken from the request.

SIP and telephony security

• SIP traffic is continuously monitored for attack patterns. Sources crossing the configured threshold are automatically blocked at the firewall and an alert is sent.
• Inbound calls are matched against known trunk sources before they are allowed into call routing.
• A phone number can route inbound to exactly one tenant. This is enforced by a database constraint, not by convention, so a number cannot be quietly claimed by a second tenant.

Auditability

Administrative actions, authentication events and support access are written to an audit log that tenant admins can review in-app under Admin → Audit Log. Platform-level actions are logged separately. Audit records are deliberately not user-deletable.

Reporting a vulnerability

If you find a security issue, please tell us before telling anyone else. Contact us with Technical support selected and "security" in the subject line, and include enough detail to reproduce it. We will acknowledge and keep you updated through to a fix. We will not pursue action against researchers who report in good faith and do not access other tenants' data.

Certifications — the honest answer

Neo Dialer does not currently hold a SOC 2, ISO 27001 or HITRUST certification. The controls described on this page are real and in place, but they have not been audited by a third party, and we would rather say so than imply an attestation we cannot produce.

If your procurement process requires a formal attestation, a security questionnaire, a penetration test report, or a signed DPA or BAA, talk to us — we will tell you exactly what we can and cannot provide today.