Built for business
Conversations with customers are personal data, and often a trade secret as well. What follows are not statements of intent but mechanisms: every one of them can be verified in the database schema or in the code.
Built for business
Not statements of intent — mechanisms you can verify in the code and in the database schema.
Data isolation
Every customer sees only their own. It is a property of the database (row-level security on 36 tables), not of developer discipline.
Encrypted secrets
Provider keys are stored under AES-256-GCM; the master key never lives in the database.
Roles and permissions
Five roles with real boundaries. The public API has per-action permissions on every key.
Audit log
Critical actions leave a record: who changed what, when, and to what.
Retention
Call recordings are deleted on schedule once the term expires — automatically, not when somebody remembers.
Data subject requests
Access, deletion, correction and portability — tracked in the system as first-class records.
Isolation you cannot forget to switch on
The most common way to show one customer another one’s data is to forget a condition in a query. So the separation does not live in application code — it lives in the database.
- Row-level security is enabled in FORCE mode on 36 tables — it applies even to the table owner
- Every transaction sets the customer identifier; without it a query returns nothing rather than everything
- Application roles have no superuser rights and cannot bypass row-level security
- Every view is created with security_invoker — otherwise it would run with the owner’s rights and step around the policy
- The rule is checked by a separate test against a live database, not only by code review
Keys and secrets
Provider keys give access to a paid account and to customer conversations. They are never stored in the clear anywhere.
- AES-256-GCM encryption in the secret store
- The master key is never kept in the database — losing it means losing the secrets, and that is a deliberate trade-off
- The voice process receives only the keys on its allowlist and has no access to the rest
- A key value never reaches the audit log — neither the old one nor the new
- Database password rotation is done by a script, not by hand
Recordings and retention
A call recording is the most sensitive thing in the system. That is why it is off by default and switched on deliberately.
- The agent is required to say out loud what exactly is stored — text or audio
- If the customer objects, the agent does not argue and hands the call to a human
- Recordings land in your own S3 storage, not in ours
- The retention period is configurable; after it, files are deleted automatically on schedule
- The recording row stays as evidence of deletion — the file disappears, the trace does not
Data subject rights
GDPR is not a policy page but a working process: requests have to be accepted, fulfilled, and demonstrably shown to have been fulfilled.
- Requests are tracked separately: access, deletion, correction, portability
- The audit log records who fulfilled a request and when
- Customer data is tied to the record — deletion leaves no leftovers inside conversations
- Roles with real boundaries: viewer, operator, sales manager, supervisor, administrator
- A public API with per-action permissions — an integration gets exactly what it needs
Send us your requirements list
We will go through it point by point and say plainly what already exists and what would have to be built.
Show us one of your calls
We will show you how CallBridge runs it: what the agent asks, which facts it collects and the moment it hands the conversation to your manager.