Implemented controls

How Open Voice Shield is secured

SIP ingress is authenticated by a per-tenant IP allow-list. The web and API surface uses bcrypt password hashing, short-lived access tokens, rotating refresh sessions and optional WebAuthn passkeys. Every endpoint is scoped to one tenant, with an audit log of administrative actions. Outbound webhooks are HMAC-signed and SSRF-guarded, inbound payment webhooks are signature-verified, recordings live in operator-controlled storage with real retention deletion, and secrets are write-only over the API.

The call path

SIP ingress

Source-IP allow-list: Each tenant registers the CIDRs its switches send from. Authorization runs first on the initial INVITE: an unlisted source gets 403 and no call record, so scanner traffic never reaches the pipeline or the SIP trace. Ranges are overlap-checked across tenants, and a minimum prefix length stops an account claiming half the internet.
No registrar, no digest surface: REGISTER is answered 403. There is no SIP password anywhere in the design, so there are no SIP accounts to brute-force.
Destination guard: A destination that resolves to loopback, link-local, multicast or the proxy's own address is refused with 403 Destination Not Allowed. A customer-controlled destination cannot reach the host network or loop back into the proxy.
Transport: The ingress listens on UDP and TCP. The onward leg can use TLS where the destination is configured for it. Portal and API are HTTPS with HSTS at the edge, under a strict Content Security Policy allowing only same-origin script and style.

Caveat, stated plainly

The TLS client profile for the beta Voice AI destination does not verify the remote certificate, and its digest credential is one shared value rather than one per destination. That is why Voice AI forwarding is labelled beta and not offered as a production path.

Who gets in

Accounts, sessions and credentials

Authentication and session handling as implemented.
Control	Implementation
Password storage	bcrypt at cost 12. A minimum length is enforced; a password longer than bcrypt's limit is rejected, not silently truncated.
Login responses	A wrong e-mail and a wrong password return the same error in the same time, so the form is not an account-existence oracle.
Access tokens	Short-lived and signed. Changing a password or signing out everywhere invalidates every token issued before that moment.
Browser sessions	A refresh token in an HttpOnly, SameSite=Strict, path-scoped cookie, rotated on every use, with a required custom header as CSRF protection. Replaying a rotated token revokes the whole family.
Second factor	Optional WebAuthn passkeys. Challenges are single-use; the signature counter must move forward, so a cloned authenticator is detected.
First sign-in	An operator-created account starts with a temporary password and must change it before anything but the auth endpoints will answer.
API keys	Stored hashed, bound to the user who minted them, revocable, and dead the moment that user is deactivated. Only an owner can mint credentials.
Rate limiting	On authentication and on public endpoints, counted against the real client address, not a header a client can set.

Who sees what

Tenant isolation and the audit log

Every customer-facing endpoint is scoped to the calling tenant in the query itself, not by filtering afterwards. Administrative endpoints are separate routes with their own authorization. Customer responses are built from explicit allow-lists, not by serializing a record and deleting fields, so internal fields never appear on one.

Administrative and security-relevant actions are written to an audit log against the acting user's e-mail: settings changes, top-ups, credential and pilot changes, exports, share creation and revocation. An operator may open a customer's portal in a read-through support session, which is recorded. That session cannot change the customer's password, end their sessions or manage their passkeys.

Data leaving the platform

Webhooks, payments and shared links

Outbound webhooks

Signed HMAC-SHA256 with a per-tenant secret, carrying a delivery id so a receiver can be idempotent. The target URL passes an SSRF guard, then is connected to on the exact IP that was validated. A DNS answer that changes between check and connection cannot redirect the delivery.

Inbound payment webhooks

Verified against the provider's signature before any state changes, and idempotent on the session identifier. A replayed or forged notification cannot credit an account.

Shared call links

Server-generated password stored as a bcrypt hash, rate-limited per token and per address, marked noindex and no-store. An unknown link and a wrong password return an identical response, so the link space cannot be probed. Revocation is immediate.

Secrets the platform uses to authenticate to something else — mail relay password, payment keys, webhook secrets — are write-only over the API. They can be set and replaced, never read back, and they are excluded from the audit log and the application logs.

Data at rest

Recordings, captures and retention

Where the audio lives: On the operator's own disk, or in an operator-controlled S3 bucket with server-side encryption on and public access blocked. Nothing is stored in a bucket the operator does not own.
Retention: Independent windows for recordings, media captures and SIP logs. Expiry deletes the object, local or in the bucket; the call keeps its metadata, and the missing artefact is reported as an omission rather than an error. Source captures are deleted as soon as they are converted.
What is kept indefinitely: Call detail records, transcripts, analyses, ledger entries and the audit log have no automatic deletion. Removing an account and its content is a deliberate, manual operation on request.
Backups: Scheduled database dumps to the operator's bucket or disk, retaining the last N. A dump contains everything the database does, webhook secrets included, so it is treated as a secret itself.

Third parties in the path

Where call content goes

Speech-to-text runs either on the operator's own server, where the audio never leaves it, or against a cloud API. Fraud analysis runs against a cloud analysis API. The portal badges both stages local or cloud per call, so you can see whether a call's content left the machine. A cloud provider receives the audio channels or the transcript with the call metadata, under that provider's own terms.

Operator FAQ