Security: data handling, encryption, and compliance posture
Where Call2Me stores data, what's encrypted, what's logged, and how to handle PII responsibly when your agent might hear it.
Updated May 6, 2026
This doc covers the security model — what's encrypted, what's logged, what's your responsibility, what's ours.
Transport
| Channel | Encryption |
|---|---|
| Browser ↔ platform (WebRTC) | DTLS-SRTP |
| Carrier ↔ platform (SIP) | TLS for signaling, SRTP for media when carrier offers |
| API (REST) | HTTPS only; plain HTTP redirected then closed |
| Webhooks (outbound) | HTTPS only on your endpoint |
The platform refuses unencrypted SIP traffic from carriers that haven't been explicitly configured for plaintext (rare, used only for legacy test trunks).
At rest
Recordings, transcripts, knowledge base content, and database records are encrypted at rest by the underlying cloud storage. Keys are managed by the cloud provider's KMS.
What's stored:
- Call metadata — call_id, timestamps, duration, status (always)
- Transcripts — text of what was said (always, used for analytics)
- Recordings — audio files (only if
recording_enabled = trueon the agent or call) - Knowledge base content — your uploaded documents and texts (until you delete them)
What's not stored:
- Audio frames during a live call (memory only, not persisted unless recording is on)
- API key values after creation (you see the key once at creation; we store only a hash)
Authentication & access
API access is via Bearer keys; see Authentication. Keys are workspace-scoped and admin-controlled. Audit logs track:
- key created / revoked
- agent / KB / campaign created / updated / deleted
- billing events (top-up, refund)
Audit log is visible at Settings → Audit Log for admins.
PII handling
The platform treats anything in a call transcript as potentially sensitive. By default:
- Transcripts and recordings are visible to workspace members with the right role
- API calls from your code can fetch any call's transcript or recording
- Webhooks can deliver transcript data to your endpoints
For sensitive workflows you can:
- Disable recording on the agent — produces transcript only, no audio
- Disable transcripts — when even the text is too sensitive (rare; this disables a lot of features)
- Use a separate agent for PCI-style capture — route card-number collection to a flow that bypasses the LLM and sends DTMF directly to your processor
Compliance posture
Call2Me's compliance posture varies by region and use case. The platform exposes the primitives — recording on/off, transcript on/off, webhook endpoints, audit logs — and you build the policy on top to match your regulator.
For specific frameworks (HIPAA, PCI-DSS, GDPR, KVKK), contact support@call2me.app to discuss your requirements before deploying.
Reporting a security issue
If you find a vulnerability, email security@call2me.app. Please don't file public GitHub issues for security findings.
We acknowledge within one business day and credit reporters in our hall-of-fame on request.
What's next
- Authentication — the access-control primitives
- Webhooks — signature verification for inbound events
- Calls — the recording_enabled flag
Frequently asked
Q.Is voice data encrypted in transit?
Yes. Browser-to-platform uses WebRTC with DTLS-SRTP. Carrier-to-platform uses SIP over TLS with SRTP when the carrier supports it. API calls are HTTPS only — plain HTTP is rejected at the edge.
Q.What about at rest?
Recordings, transcripts, and database records are encrypted at rest by the storage layer. Encryption keys are managed by the cloud provider; we do not surface BYOK as a self-serve option today.
Q.Can I disable call recording for sensitive calls?
Yes — per agent. Agents can be configured with recording_enabled = false; calls placed through them produce a transcript but no audio file.
Q.Does the LLM see sensitive fields like card numbers?
By default yes — the LLM sees the full transcript. For PCI-style flows, mark the agent's prompt to refuse card-number capture and send the caller to a separate IVR flow that bypasses the LLM.