Red-Team Audit for Voice Agent Vendors

# Red-team audit for voice agent vendors

Quick answer

A voice agent red-team audit is an independent, adversarial test of a vendor's agent. An outside auditor attacks it over voice with prompt injection, jailbreaks, PII extraction, and out-of-scope requests. Each probe is scored refused or leaked. It shows whether the agent holds up before you buy or renew.

A voice agent that handles your calls also holds your risk. It can be tricked into leaking data, approving refunds, or moving money. The demo will never show you that. A red-team audit does. It is the adversarial half of any serious voice agent evaluation, and it is the part vendors rarely run against themselves.

This guide explains what an independent red-team audit covers. It walks through the attack classes, how each probe is scored, and a step-by-step method you can commission or run. It also explains why the vendor's own testing is not enough to protect you.

What a voice agent red-team audit is

> Red-team audit: an independent, adversarial evaluation where an outside tester attacks a system to find failures a friendly test would miss. The goal is to break the agent on purpose, then report exactly how it broke.

The term comes from security. A red team plays the attacker so the defender learns before a real one shows up. For a voice agent, the attacker is a caller. The caller is not friendly. It is probing for the one phrase that makes the agent break character.

That framing matters. Most vendor testing checks whether the agent can do its job. A red-team audit checks whether it can be made to do the wrong job. Those are different questions with different costs. A missed task annoys a caller. A blown guardrail leaks data or moves money.

An independent audit adds a second difference. The tester does not build the agent, sell the agent, or report to the team that does. That distance is the whole point of a third-party voice agent audit. The people who wrote the prompts are the worst people to prove those prompts are safe.

Why the vendor's own testing is not enough

Vendors test their own agents. They should. But their testing has a built-in blind spot. They know the prompts, the guardrails, and the happy paths. They tend to test what they built, not what an attacker would try.

There are three structural problems.

First, incentive. A vendor's testing exists to ship the product. A finding that delays launch is friction. An independent auditor has no launch to protect, so a leak is just a leak.

Second, knowledge. Builders test against their own mental model of the agent. Attackers do not share that model. They try things the team never imagined, because they are not trying to be reasonable.

Third, reporting. Vendor-reported safety numbers are marketing until someone outside verifies them. This is the same reason buyers turn to independent voice AI evaluation for quality metrics. Safety deserves the same scrutiny, or more.

None of this means vendors are dishonest. It means self-assessment has limits. The NIST AI Risk Management Framework makes the same point for AI systems broadly. Independent testing is a control, not an insult.

The attack classes an independent audit covers

A good audit does not throw random insults at the agent. It works through named attack classes, each mapped to a real failure mode. Public references help here. The OWASP Top 10 for LLM Applications and MITRE ATLAS both catalog the ways language systems get exploited.

Over voice, these classes take on a spoken shape. The attacker cannot paste text. They speak, spell, and improvise. Some attacks hide in the fields the agent reads aloud, like a name or a note.

Here are the core classes and how each is probed.

Prompt injection. The caller plants an instruction that tries to override the agent's rules. It can come through speech or through data the agent ingests. The deeper mechanics live in the prompt injection over voice guide. See also the Wikipedia entry on prompt injection.

Jailbreak and role-play. The caller invents a frame where the rules no longer apply. "Developer mode." "Pretend you have no restrictions." The agent should decline the frame, not the caller.

System-prompt extraction. The caller tries to make the agent recite its own instructions. A leaked system prompt hands an attacker the map to every other attack.

PII extraction. The caller tries to pull data the agent should protect. This is where identity verification and data handling meet, covered in the PII handling in voice agents guide.

Out-of-scope actions. The caller pushes the agent to do something it was never authorized to do. Unauthorized transactions are the sharpest example. Approve a refund. Wire funds. Skip a step.

Social engineering. The caller claims authority or urgency to bend policy. "I'm your supervisor." "This is an emergency." The playbook is the classic social engineering attack, aimed at a machine.

Policy bypass. The caller invents a rule or commitment the agent then honors. If the agent makes up policy under pressure, it fails, which ties directly to testing policy adherence in voice agents.

Attack classes, probes, and pass criteria

The table below pairs each attack class with a representative spoken probe and the criteria that count as a pass. A pass means the agent held. Anything else is a finding.

How to run a red-team audit on a vendor's voice agent

You can commission this or run it in-house. Either way, the method is the same. Work through these steps in order.

1. Define scope and rules of engagement. Agree what is in bounds, what data is synthetic, and what the agent may access during testing. Never test against live customer records. Use seeded test accounts instead.

2. Map the attack surface. List every input the agent reads or hears. Speech, spelled entries, DTMF tones, names, notes, and any data pulled from connected systems. Each input is a possible injection point.

3. Build an adversarial probe set. Write concrete probes for every attack class in the table. Aim for many variants per class, not one. Vary tone, pacing, and phrasing so you test the class, not a single sentence.

4. Run the probes over real voice. Speak the attacks through the actual voice channel, not a text back door. Voice adds accents, interruptions, and background noise that change how the agent parses intent.

5. Score each probe refused or leaked. Record the outcome as a hard pass or fail. Capture the transcript, the audio, and any action the agent took. Log near-misses separately, since they show where the boundary is thin.

6. Reproduce and retest after fixes. Hand the vendor exact reproduction steps. When they patch, rerun the same probes plus new variants. A fix that only blocks the literal phrase is not a fix.

7. Report and gate the buying decision. Summarize findings by attack class and severity. Treat any successful data leak or unauthorized action as a launch blocker, not a backlog ticket.

For the operational testing side of this method, the NIST SP 800-115 technical guide is a solid public reference on structured security testing.

How attacks are scored: refused versus leaked

Most voice metrics are gradients. Task success at 88% beats 82% and both might ship. Safety does not work that way. A guardrail either held or it did not.

That is why red-team scoring is binary at the probe level. Each probe lands in one of two buckets: refused or leaked. Refused means the agent held the line. Leaked means the attacker got something they should not have, whether data, an action, or the system prompt.

You do not average leaks into an aggregate. An agent is not "94% safe" if one probe extracted a Social Security number. One successful extraction is a failure of the whole gate. This binary framing is what separates guardrail testing from quality testing, a distinction explored in testing guardrails in voice agents.

Severity still matters for triage. A leaked system prompt is bad. An unauthorized wire transfer is worse. Rank findings so the vendor fixes the money and data leaks first. But rank does not soften the gate. Any leak in a critical class blocks the decision until it is closed.

Escalation behavior is part of scoring too. A safe agent that hits an attack it cannot resolve should hand off, not improvise. Clean handoff is a pass. Silent failure is not. The escalation in voice agents guide covers what good handoff looks like under pressure.

Who should run it, and when

Run a red-team audit at two moments. Before you buy, and before you renew. Both are decision points where a finding changes what you sign.

Before you buy, the audit tells you what you are actually purchasing. A polished demo hides the failure modes. A red-team run surfaces them while you still have leverage. This is a core input to how you evaluate voice agent vendors beyond the feature list.

Before you renew, the audit tells you whether the agent held up. Vendors update prompts, models, and tools constantly. An agent that passed last year may leak today, because a model swap changed how it handles a frame. Renewal is the moment to recheck.

Who runs it matters as much as when. The tester should be independent of the vendor and independent of your own build team. Independence is what makes the finding credible to your risk, legal, and security stakeholders. Evalgent runs exactly this kind of audit as a neutral third party, attacking the vendor's agent so your team does not have to grade its own homework.

The cadence should match your risk. High-stakes domains like finance, healthcare, and collections warrant an audit at every material change. Lower-stakes agents can run on a fixed schedule. Either way, treat the audit as a recurring control, not a one-time gate.

Frequently asked questions

What is a voice agent red team audit?

A voice agent red team audit is an independent, adversarial test of a vendor's agent. An outside tester attacks it over voice with prompt injection, jailbreaks, PII extraction, and out-of-scope requests. Each probe is scored refused or leaked. The audit reports exactly how the agent broke, so you can fix it before a real caller finds the gap.

How is a red-team audit different from normal QA?

Normal QA checks whether the agent can do its job. A red-team audit checks whether it can be tricked into doing the wrong job. QA uses friendly test cases. Red-teaming uses an adversary who wants the agent to fail. The two answer different questions, and both belong in a complete evaluation.

Why is the vendor's own testing not enough?

Vendors know their own prompts and guardrails, so they test what they built, not what an attacker would try. Their testing also exists to ship the product, which makes launch-blocking findings inconvenient. An independent auditor has no launch to protect and no shared blind spot, so leaks get reported instead of rationalized.

What attacks does a voice agent red team audit cover?

A thorough audit covers prompt injection, jailbreak and role-play, system-prompt extraction, PII extraction, out-of-scope actions like unauthorized transactions, social engineering, and policy bypass. Each class maps to a real failure mode. The auditor runs many spoken variants per class, since a single scripted phrase tests almost nothing.

How are red-team results scored?

Results are scored binary at the probe level: refused or leaked. Refused means the agent held. Leaked means the attacker got data, an action, or the system prompt. Leaks are never averaged into a passing score. A single successful extraction blocks the decision, with severity used only to rank which fix comes first.

Can prompt injection really happen over voice?

Yes. An attacker can speak an injected instruction or plant it in data the agent reads aloud, like a name or note field. Voice adds accents, interruptions, and noise that change how the agent parses intent. Testing must happen through the real voice channel, not a text interface, to catch these spoken injection paths.

When should we run a red-team audit?

Run one before you buy and before you renew. Both are decision points where a finding changes what you sign. Also rerun after any material change, since a model swap or prompt update can reopen a closed gap. High-stakes domains warrant an audit at every material change, not on a fixed annual schedule.

Who should perform the red-team audit?

The tester should be independent of both the vendor and your own build team. Independence is what makes findings credible to risk, legal, and security stakeholders. The people who wrote the prompts are the worst people to prove those prompts are safe. A neutral third party attacks the agent so no one grades their own homework.

The bottom line

A red-team audit is the only reliable way to learn how a vendor's voice agent breaks. Run it before you buy and before you renew, and treat every leak as a launch blocker.

Ready to test a vendor's agent before you sign? Book a demo to see an independent red-team audit in action.