Voice AI Agent Threat-Model Lab
A voice AI agent’s risk profile is decided by what it can do — an agent that only answers questions is worlds apart from one that authenticates callers and moves money. Pick the capabilities your deployed voice agent has — takes actions / makes tool calls, handles PII, authenticates callers, processes payments, is internet-reachable, uses cloud inference — and this lab surfaces the relevant threats across audio prompt-injection / jailbreak, speaker-spoofing / authentication bypass, PII leakage & recording consent, tool-call abuse & over-scoped actions, toll/usage fraud & DoS, and transcript/data retention — each with concrete mitigations. You get a prioritized threat list, a weighted risk index and an exportable model. It is a defensive modelling aid, not a scanner: it reaches nothing and captures no audio.
A defensive, educational threat-modelling aid. Pick the capabilities your voice AI agent has and it surfaces the relevant threats and mitigations. It is not a scanner — it reaches nothing, captures no audio and contains no attack tooling. General guidance only, not security advice.
What can your voice agent do?
Select every capability that applies. The threat list updates live.
No capabilities selected — showing the baseline threats every voice agent carries. Select capabilities above to expand the model.
Audio prompt-injection / jailbreak
- highSpoken prompt injection overrides the agent’s instructions
A caller (or audio played down the line) issues instructions that hijack the agent — "ignore your rules and…". With a speech-to-speech model there may be no text transcript to filter before the model acts.
Applies because: Baseline (any voice agent)Mitigations- Keep system instructions and tool-authorization logic out of the model’s controllable context; enforce them in code, not in the prompt.
- Treat all caller speech as untrusted input — validate and constrain what it can trigger, never let it change the agent’s role or scope.
- Add guardrail / content checks on the recognised intent (and on the transcript where a cascade exposes one) before any sensitive action.
Transcript / data retention & logging
- mediumLogs and transcripts become a sensitive-data liability
Transcripts, recordings and tool-call logs accumulate sensitive data; over-retention or weak access control turns the audit trail into a breach target.
Applies because: Baseline (any voice agent)Mitigations- Log enough for security and audit, but redact secrets and minimise PII in logs.
- Access-control and encrypt logs/recordings; apply a retention-and-deletion schedule.
- Separate security logging (who did what) from content capture (what was said), and justify each.
Everything runs in your browser — nothing is uploaded. This is a modelling aid that lists threats and defensive mitigations from the capabilities you select; it reaches no system, captures no audio and contains no attack or exploitation tooling.
What this lab is
- An interactive threat-model builder for a deployed voice AI agent: pick the capabilities your agent has and it surfaces the relevant threats and defensive mitigations.
- Capabilities you can toggle: takes actions / makes tool calls, handles PII, authenticates callers, processes payments, is internet-reachable, and uses cloud inference.
- Threats are organised into categories — audio prompt-injection / jailbreak, speaker-spoofing / authentication bypass, PII leakage & recording consent, tool/function-call abuse & over-scoped actions, toll/usage fraud & denial-of-service, and transcript/data retention & logging — each with concrete mitigations.
- Produces a prioritized threat list with a weighted risk index and an exportable model you can copy or download. Defensive and educational — it is a modelling aid, not a scanner.
- Everything runs client-side: it reaches no system, captures no audio and contains no attack tooling.
Why this matters
Organisations are putting voice AI agents in front of real callers — support lines, booking, triage, even account changes — faster than the security review is catching up. The new speech-to-speech models make the interaction fluent and interruptible, which is exactly what makes a hijacked agent dangerous: a spoken injection can steer it in real time, and if the agent can take actions, that steering becomes a real tool call. A threat model is the cheapest control you have: it tells you, before deployment, which risks your specific agent actually carries and what to put in place first.
This lab keeps the model honest by tying every threat to a capability you selected, so the output reflects your agent rather than a generic list. Use it to frame a design review or a tabletop, hand the exported model to the engineering and risk teams, and then validate the real controls with authorized testing. It is defensive guidance only — it contains no attack tooling and is not security or legal advice.
Frequently asked questions
What is a voice AI agent threat model?
A threat model is a structured way to reason about what could go wrong with a system and how to defend it. For a voice AI agent — a system that talks with callers and may take actions on their behalf — the threat model depends heavily on what the agent can actually do. An agent that only answers questions has a very different risk profile from one that authenticates callers and moves money. This tool builds a capability-driven model: you select what your agent does, and it surfaces the threats that those capabilities introduce, each with defensive mitigations, so you can prioritise where to put controls.
What are the main threats to a voice AI agent?
The big categories are: audio prompt-injection and jailbreak, where spoken (or played-in) instructions hijack the agent — especially dangerous when there is no text transcript to filter and when the agent can take actions; speaker-spoofing and authentication bypass, where a cloned or replayed voice defeats identity checks; PII leakage and recording consent, including disclosing data to the wrong party and processing audio without a lawful basis; tool/function-call abuse and over-scoped actions, where a hijack triggers real, high-impact operations; toll/usage fraud and denial-of-service against an internet-reachable endpoint; and transcript/data retention risks, where logs and recordings become a sensitive-data liability. Which apply to you depends on your agent’s capabilities — that is what this lab models.
How do you defend against audio prompt injection?
Treat all caller speech as untrusted input and never let it change the agent’s role, scope or authorization. Keep system instructions and tool-authorization logic in code, not in a prompt the model can be talked out of. Gate every sensitive tool call behind an independent authorization check that caller speech cannot influence, and require explicit confirmation or human-in-the-loop for high-impact actions. Where a cascade exposes a transcript, add content/guardrail checks on the recognised intent before acting. And design tools to be least-privilege and reversible so that even a successful injection has a small, recoverable blast radius.
Why does "authenticates callers" raise the risk so much?
Because the tempting shortcut — treating a recognised or "verified-sounding" voice as proof of identity — is exactly the control that modern voice cloning defeats. If an agent authenticates from voice characteristics alone, a synthetic or replayed voice bypasses it outright. The defense is to never use voice as an identity factor: require a real authentication factor (knowledge plus possession, an OTP to an enrolled device, step-up on risk), use liveness/challenge-response that a static recording cannot satisfy, and fall back to out-of-band verification for high-risk requests regardless of how the voice sounds.
Is this a scanner? Does it connect to my agent?
No. It is an educational, defensive modelling aid that runs entirely in your browser. It does not connect to, probe, or test any system; it captures no audio and contains no attack or exploitation tooling. It simply maps the capabilities you select to a list of relevant threats and mitigations and lets you export that model. Use it to structure a design review or a tabletop, then validate your real controls through authorized testing. Treat the output as general guidance, not security advice.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.