Blog · 12 October 2026 · 3 min read
Keeping card data out of transcripts
What the platform masks, when it masks it, and why you should still not rely on it alone.
Callers say things you did not ask for. In a collections or support call, someone will read out a card number because they think it helps. If nothing stops it, that number goes to the language model, into the transcript, into the logs and into the webhook you post to your CRM. This post is about what the platform does to prevent that, and where it stops.
Masking happens before the model
The voice engine masks what the caller said before the language model, the logs and the platform see it. The same policy is applied again by the platform to every event the engine sends in, so there are two passes, not one.
What is recognised:
- card numbers, checked with the Luhn checksum so that an order number of the same length is not masked by mistake;
- Aadhaar numbers, checked with their own checksum;
- PAN and bank account numbers;
- CVV, one-time codes and PINs, when they follow a cue word;
- all of the above when spoken as number words, in English or Hindi.
It applies to caller turns, agent turns, tool-call records, log lines and extracted data.
Three policies
| Policy | Effect |
|---|---|
off | Nothing is masked. |
mask | Sensitive values are masked; the last four digits of a card or account number are kept. The default. |
strict | No last four, and values under keys that look like card, PIN or account fields are masked too. |
Set it for the workspace in the compliance settings, or per agent with task_config.pii_redaction. The agent's setting wins.
Keypad entry is the safer path
If you need a number from the caller, do not ask them to say it. Ask them to type it. A keypad entry marked sensitive is never reported in clear: it appears as [REDACTED] in the turns, the tool calls, the extracted data and the result.
The recording is handled too. While a sensitive entry is being typed, the recording is silent for both sides, and the call's record lists those stretches so that nobody mistakes them for a fault:
{
"recording_gaps": [{"start": 41.2, "end": 47.9, "reason": "sensitive keypad entry"}]
}A graph node can verify what was typed without anyone seeing it. With a match rule the engine compares the entry to a value from your own lookup and records only whether it matched.
Where it stops
This is the part to read twice.
- It is pattern matching. It will miss a number spoken in an unusual way, split across turns, or interrupted. Do not treat it as your only control.
- Spoken audio is not redacted. Only keypad entry is silenced in the recording. A card number said aloud is masked in the text and still audible in the audio.
- Simulated calls are not masked. Transcripts from the mock engine are scripted text and go through as written.
- Data is not encrypted at rest by the application. Use disk encryption, and decide how long recordings are kept.
- It is not a certification. The platform has no compliance certifications and has not had an external security audit.
Masking lowers the chance that sensitive data ends up somewhere it should not be. Designing the call so the data is never spoken lowers it further. The details are in the compliance toolkit guide.