Skip to content

Security

What holds one customer apart from another.

Ringfully carries several businesses’ phone calls through the same software and the same database. This is the machinery that keeps them separate, who can see what inside one of them, and what is still missing.

31 permissions across 7 groupsA suite whose only job is isolationTwo separate token-signing keys
Custom role31 permissions
Calls9
Contacts2
Messaging2
Voicemail2
People & access4
Organization10
Emergency calling2

Isolation

Every customer shares one database, and every table that holds customer data carries an organization id. Queries filter on it without exception, and that id is read from the verified session token rather than from anything the request supplied — so there is no parameter to tamper with.

There is a test suite whose only purpose is to attempt cross-customer reads and writes and assert that all of them fail.

Two sets of keys

Customer sessions and our own operator sessions are signed with different keys, and that separation is load-bearing rather than tidy. Our data layer treats a missing condition as "no condition", so a token that was validly signed but missing its claims would otherwise match an arbitrary account. Different keys mean such a token fails at the signature and never reaches that code.

The operator console

The console we use to administer customers is on its own hostname, requires a second factor with no way to opt out, and has no registration route at all — accounts are created by hand. Its session lives in a cookie the page's own JavaScript cannot read, because that console can list every customer and a stolen durable session there would matter far more than one agent's.

Sessions

Access tokens are short-lived and refresh tokens rotate. Re-using an old one is treated as theft and revokes the whole chain rather than just refusing that one request. Repeated failed sign-ins lock the account itself, not the address they came from, because locking by address is trivial to spread around.

When a flow calls your systems

A call flow can make an outbound request — to look something up before deciding where to route a caller. That is a genuinely dangerous thing to allow, so it goes through a firewall of our own: HTTPS only, and only to hosts an admin has explicitly added, default-deny.

The address check happens inside name resolution rather than before it, so the address we approved is the address actually connected to. Checking first and connecting second leaves a window where a name can be re-pointed in between. Redirects re-run the whole check, since a permitted host answering with a redirect to an internal address is the usual way past this kind of control.

Recording

Dual-channel, and the policy belongs to the organization rather than the individual: always, the agent's choice, or never, plus whether an agent may stop one that is running. Playback is permissioned separately from recording.

What we do not have

No independent security certification. No federated sign-in. No exportable administrative event log — actions are attributable in our own logs, but there is no report you can pull yourself. No configurable retention schedule yet, and data deletion requests are handled by hand rather than through a self-service export.

Each of those is on the list. If one of them is what your procurement process will actually stop on, ask and I will tell you where it really is rather than what would be convenient.