Knowledge-based authentication for voice agents

What knowledge-based authentication is

Knowledge-based authentication asks a person to prove identity by answering questions about information they should know. A voice agent can conduct the exchange, but the security decision belongs to a separate, deterministic policy service.

The first design choice is the source of the challenge:

Dynamic KBA and voice biometrics are different. KBA evaluates the content of an answer. Voice biometrics evaluates characteristics of the speaker's voice. A voice agent asking questions does not turn KBA into biometrics, and an ordinary recording is not automatically a voiceprint.

Two correct KBA answers also remain one knowledge factor. They do not create multi-factor authentication. Current digital identity guidance from the U.S. National Institute of Standards and Technology (NIST) says KBA does not constitute an acceptable secret for digital authentication. It also treats a biometric characteristic as unsuitable for single-factor authentication. NIST's federal identity-proofing requirements go further and prohibit KBA or knowledge-based verification for identity verification in that framework.

For a production voice workflow, the safe interpretation is direct: KBA can supply a risk signal or unlock a narrowly scoped, low-risk action. It should not establish a durable authenticated session or authorize a consequential change by itself.

Place KBA inside a defined threat model

Dynamic questions are harder to prepare for than a fixed question. They still fail when an attacker already has the relevant data. The design has to assume that personal information may have leaked through breaches, social media, intercepted calls, insiders, previous support interactions, or compromised customer systems.

Map each attacker to a control before writing prompts:

The protected action sets the assurance requirement. Reading a shipping estimate, changing a payout destination, resetting account credentials, and disclosing medical data should not share one KBA policy. Define allowed actions, required factors, session lifetime, and escalation behavior for each risk tier.

Reference architecture for dynamic KBA in a voice agent

A robust flow has separate conversation, policy, data, and authorization layers.

1. Capture the claimed identity. Collect a non-secret account reference, such as a customer number or phone number already associated with the incoming session. Finding a record is identification, not authentication.
2. Calculate the action risk. A policy service considers the requested action, account state, prior attempts, channel, fraud signals, and any existing authenticated session.
3. Build an eligible challenge set. A server-side service retrieves current first-party facts through a least-privilege identity. It rejects facts that are old, ambiguous, publicly visible, shared by a household, or likely to appear in the caller's wallet.
4. Give notice before collection. The agent explains the purpose, any recording or transcription that applies, and the alternate route when the caller cannot or does not want to answer by voice.
5. Ask one challenge at a time. The agent receives question text and an opaque question ID. It never receives the expected answer in its prompt or conversation context.
6. Validate outside the model. A dedicated service normalizes allowed formats, compares the response, updates attempt state, and returns an outcome. The language model can manage the dialogue, but it cannot make a fuzzy identity decision.
7. Issue scoped session state. On success, the policy service returns a short-lived result that names the assurance level, permitted actions, tenant, account, expiry, and policy version. Business tools validate that state again when an action runs.
8. Close, step up, or transfer. The flow completes the permitted task, requests another factor, or hands the caller to a trained operator without exposing answers.

An opaque result can look like this:

{
  "status": "step_up_required",
  "assurance": "kba_partial",
  "allowed_actions": ["read_order_status"],
  "expires_at": "2026-09-25T14:05:00Z",
  "policy_version": "customer-support-v7",
  "reason_code": "risk_tier_requires_possession"
}

The response contains what the agent needs to continue. It does not contain the expected answer, the underlying customer record, or an explanation an attacker could use to tune another attempt.

Obtain the right consent and minimize spoken data

Authentication, recording, transcription, and biometric enrollment are separate data-processing decisions. A caller who agrees to answer a question has not automatically agreed to call recording, secondary analytics, or creation of a voiceprint.

Build notice and choice into the flow:

• identify the service and the purpose of the questions before collecting an answer;
• disclose recording or transcription according to the applicable policy before it starts;
• offer a non-voice path when the caller is in a public place, needs an accessible modality, or declines the voice flow;
• avoid asking the caller to say a full government identifier, payment credential, password, or one-time code aloud;
• pause or disable recording around sensitive input when the channel and policy support it; and
• treat dual-tone multi-frequency (DTMF) input as sensitive data too, since tones and decoded digits can appear in media, traces, or downstream logs.

The European Union's General Data Protection Regulation (GDPR) requires purpose limitation, data minimization, and storage limitation for personal data within its scope. Those principles are useful engineering constraints in any region. Fetch only the fields needed for the current challenge, keep expected answers out of the model, and retain the smallest audit record that can explain the outcome.

Recording, biometric, and communications rules vary by jurisdiction and context. Production systems need a jurisdiction-aware policy owned by the organization's privacy and legal teams. The agent should execute that policy consistently rather than improvise a disclosure.

Design questions and matching rules for real calls

Good dynamic challenges come from authoritative, recent events that a legitimate caller can recall and an attacker is less likely to possess. Examples include the category of a recent support case, the month of a service change, or a range around a recent first-party transaction. Avoid questions whose answers appear on identity documents, social profiles, mail, or a compromised account profile.

Each challenge needs metadata beyond its text:

• source system and record version;
• eligible account and tenant;
• freshness window;
• sensitivity and action-risk ceiling;
• accepted format and normalization rule;
• ambiguity and accessibility flags;
• reuse cooldown; and
• expiry for the current attempt.

Normalize representation, not meaning. It is reasonable to treat "September" and "09" as the same month when the challenge defines a month. It is unsafe to let a language model decide that a semantically similar answer is close enough. If the authoritative record has two plausible values, discard the challenge or use an alternate factor.

Multiple-choice questions can leak data. If they are required, construct decoys without revealing unrelated real customer facts, rotate position, and never announce the correct option after failure. Free-form responses avoid that disclosure, though they place more pressure on speech recognition and normalization.

Set retry, fallback, and human-handoff policy

Retries have two competing jobs. They recover from channel errors, and they limit an attacker's opportunities. Classify the failure before choosing the next step.

A conservative starting policy might allow one acoustic reprompt, one alternate challenge, and no more than two failed answers across the active attempt. The final limits belong to the risk policy for the action. Higher retry counts improve completion while also giving attackers more guesses and increasing personal-data exposure.

Human handoff is a new trust boundary. A warm transfer can carry safe context, but the operator should not inherit an unrestricted verified status. Pass an opaque assurance result and its expiry. Keep the underlying answers out of screen-pop notes, transfer summaries, and transcripts.

Log decisions without logging secrets

Authentication logs should let an investigator reconstruct policy execution without reconstructing the customer's answers.

Record:

• correlation, call, tenant, account-reference, and attempt IDs;
• agent version, policy version, risk tier, requested action, and allowed action;
• opaque question ID and challenge class;
• source-system version or timestamp, without the source value;
• recognition-confidence bucket and input modality;
• normalized outcome such as match, no match, no input, dependency error, or step-up;
• retry, cooldown, fallback, and handoff events;
• tool-call ID, latency, operator access, and final disposition; and
• creation, expiry, and revocation of scoped authentication state.

Do not put raw answers, expected answers, full challenge payloads, one-time codes, complete identifiers, or sensitive transcript slices in general application logs. Hashing a low-entropy security answer does not make it safe against guessing. Keep conversational diagnostics and the security audit trail separate, then restrict access to each for its own purpose.

Retention should be set by artifact and purpose:

Our voice AI data security guide covers the broader lifecycle for recordings, transcripts, model context, tools, logs, exports, and backups.

Enforce controls outside the conversation prompt

Prompts can tell the agent how to behave. Security controls still need independent enforcement.

• Policy isolation: The KBA service owns challenge eligibility, matching, attempt limits, assurance, expiry, and allowed actions.
• Least-privilege access: The challenge service can read only necessary identity fields. Business tools authorize the caller, tenant, record, and exact action again.
• Session binding: Bind each challenge and outcome to the call, account claim, tenant, requested action, nonce, and short expiry.
• Rate limiting: Count attempts by account, caller, device or channel signal, and organization. Use cooldowns that resist guessing without letting an attacker permanently lock out a victim.
• Anti-replay: Generate fresh challenges, reject reused challenge IDs, and prevent a prior success token from crossing calls or action scopes.
• Tool safety: Validate schemas and business rules, authenticate webhooks, use idempotency keys, constrain retries, and return minimal results to the model.
• Secret handling: Store service credentials in a secrets manager, rotate them, and never place them in prompts, URLs, or logs.
• Tenant isolation: Enforce tenant context in the policy service, data store, tool, log, and operator console. A tenant label in a prompt is not an access boundary.
• Monitoring: Alert on distributed failures, unusual challenge reuse, step-up spikes, policy bypass attempts, cross-tenant denials, and changes to challenge or retention policy.

The same pattern applies to other agent actions. Treat model-selected tool calls as untrusted proposals, as described in our AI agent security controls guide.

Evaluate security, reliability, and caller experience

Overall KBA pass rate hides the errors that matter. Measure the system by risk tier, action, channel, challenge class, language, noise condition, and caller cohort.

Security and privacy measures

• false acceptance rate on ordinary and adversarial attempts;
• attack success rate with public, breached, replayed, or socially engineered data;
• successful attempts after the configured retry boundary;
• high-risk actions authorized with KBA alone;
• cross-account and cross-tenant challenge or session leakage;
• raw-answer, expected-answer, or secret exposure in prompts, recordings, transcripts, logs, and handoff summaries;
• rate-limit, cooldown, expiry, and revocation effectiveness; and
• deletion and retention-policy completion.

Reliability and experience measures

• false rejection rate;
• completion, fallback, handoff, and abandonment rates;
• median and tail time to an authentication outcome;
• number of questions, reprompts, and total turns;
• speech-recognition no-input and no-match rates;
• dependency errors and safe-retry success;
• completion through DTMF, secure link, or assisted path; and
• differences across accents, languages, line quality, speech disabilities, and noisy environments.

Build a fixed regression set that includes legitimate answers, near matches, wrong answers, silence, interruption, background speech, stale records, duplicate calls, tool timeouts, malformed responses, prompt-injection attempts, replayed audio, synthetic voices, cross-tenant identifiers, transfer failures, and a caller who requests a human immediately.

Block release when a tested path can skip policy, expose an answer, exceed the attempt budget, carry assurance into the wrong action, or perform a high-risk change with KBA alone. Our voice-agent testing and evaluation metrics guides show how to turn these cases into repeatable scenarios and release evidence.

What we provide, and what stays in your identity stack

The architecture above is general guidance. We supply the managed voice-agent runtime and operational surfaces around the conversation. Your identity system remains authoritative for customer records, challenge generation, risk policy, matching, stronger factors, and action authorization.

We are not presenting KBA, voice biometrics, liveness detection, fraud scoring, or an identity provider as built-in Dasha features. With our managed runtime, expose the policy service as a narrow server-side tool. Return only the scoped outcome. Make every sensitive business tool validate that outcome independently, then use our transfer and inspection capabilities to handle and diagnose the cases the automated path cannot resolve.

If you are building a production caller-verification flow, evaluate Dasha with your real policy service, failure cases, and human fallback before enabling live traffic.