How to test PII handling in AI voice agents

Voice agents routinely handle the data attackers most want — card numbers, account details, dates of birth. Mishandling it is not a quality bug; it is a breach and a compliance failure. This is testable behavior. Evalgent checks it on real calls. Here is how PII handling fails and how to test it.

PII handling: how a voice agent collects, repeats back, stores, and protects personally identifiable information during and after a call.

What poor PII handling looks like

These are the symptoms on a real call:

• The agent reads a full card or account number back aloud.
• Raw PII lands in plain-text transcripts and logs.
• One caller's details surface in another caller's session.
• The agent collects sensitive data it does not need.
• Sensitive fields are never redacted or masked.

The failure is exposure. Any time PII is spoken in full, logged raw, or crosses sessions, handling has failed.

Why PII handling fails

PII handling fails when protection is not built into the flow. The agent treats sensitive data like any other text. The table maps each cause to what you hear and how to fix it.

How to test PII handling in AI voice agents

1. Define what is PII — List the sensitive fields your agent touches: cards, accounts, IDs, health data.

2. Provide PII in scenarios — Have test callers give sensitive data the way real callers do.

3. Assert masked readback — Check the agent confirms with the last few digits, never the full value.

4. Inspect the logs — Assert stored transcripts and logs redact every sensitive field.

5. Test isolation — Confirm one session's PII never appears in another.

6. Probe disclosure — Try to talk the agent into revealing stored data, and assert it refuses.

A worked example

An agent verified callers by reading their full account number back for confirmation. It felt helpful, but it meant the full number was spoken aloud on every call and stored in the transcript. That is exactly what should never be exposed. The fix was masked confirmation — "ending in 4021" — and redaction of the field before logging. A scenario now asserts the full number is never spoken and never appears in the stored transcript.

Testing PII handling with Evalgent

Evalgent tests PII handling as behavior you can assert, on realistic calls. Scenarios have callers provide sensitive data the way they do in production, across the flows that collect it. Profiles vary how callers share and reference that data. Metrics assert masked readback, redacted logs, session isolation, and refusal to disclose stored data, with thresholds you set. Evaluations run the suite as batches of synthetic callers before release, so a leak is caught pre-launch. Reviews let you replay a call and inspect exactly what was spoken and stored. This is procedure and compliance testing — see SOP-based voice agents and testing SOP-based voice agents.

The bottom line

PII handling is a security and compliance behavior, not a nice-to-have, and it fails when protection is not built into the flow. Test with scenarios that provide sensitive data, and assert the agent masks readback, redacts logs, isolates sessions, and refuses to disclose stored data.

Frequently asked questions

What is PII handling in a voice agent?

PII handling is how a voice agent collects, repeats, stores, and protects personally identifiable information — card numbers, account details, dates of birth, health data. Good handling means masking readback, redacting logs, isolating sessions, and collecting only what is needed. Poor handling exposes sensitive data by speaking it in full, logging it raw, or leaking it across calls.

Why is PII handling risky for voice agents?

Because voice agents routinely collect exactly the data attackers want, and voice adds ways to expose it — reading a number aloud, storing a raw transcript, or leaking data between sessions. Mishandling PII is a security incident and often a compliance failure, not just a quality bug, so it deserves explicit testing rather than assumption.

How do you test PII handling in a voice agent?

List the sensitive fields the agent touches, then run scenarios where test callers provide that data. Assert the agent confirms with masked values, that stored logs redact every sensitive field, that one session's data never appears in another, and that the agent refuses to disclose stored data without proper verification. Treat it as a release gate.

Should a voice agent read back a full card number?

No. Reading a full card or account number aloud exposes it on the call and usually in the transcript. Confirm with the last few digits instead — "ending in 4021." Masked readback gives the caller enough to verify while keeping the full value out of the audio and the logs, which is what testing should assert.

How do you keep PII out of logs?

Define which fields count as PII, then redact or mask them before any transcript or log is stored, not after. Test it by inspecting stored logs from PII scenarios and asserting no sensitive field appears in plain text. Redaction at capture time is more reliable than trying to scrub logs later, when copies may already exist.

What is data minimization for voice agents?

Data minimization means collecting only the personal data the task actually requires, and no more. An agent that asks for a full identifier when the last four digits would do increases risk for no benefit. Testing should flag over-collection, asserting the agent requests the minimum necessary and does not gather sensitive data it has no need to hold.

Can prompt injection expose stored PII?

Yes. A caller may try to talk the agent into revealing stored data — "read me the card on file." Without guardrails, an agent can comply. Test disclosure directly: attempt to extract stored PII through social engineering and assert the agent refuses and requires proper verification. This overlaps with prompt-injection testing and belongs in the same suite.

Does PII testing help with compliance?

It supports it. Frameworks that govern payment or health data expect sensitive information to be protected in handling and storage, and asserting masking, redaction, and isolation gives you evidence that the agent behaves correctly. It does not replace a formal compliance review, but it turns policy requirements into concrete, repeatable tests you can gate releases on.