Yes, if the agent runs the check rather than judges it. An AI agent can ask the standard questions, send a one-time code or push an in-app approval, and compare the answers with records on file. It must not hint at answers, accept "close enough", or treat a familiar-sounding voice as proof. Partial passes and third-party callers go to people.
What makes caller verification different from other support tasks?
The caller is trying to convince the agent of something, and some callers are lying. Most support tasks reward helpfulness. Verification rewards stubbornness. A model that is tuned to be agreeable will, if allowed, give the benefit of the doubt to a caller who gets the postcode almost right and sounds stressed. That is exactly the caller a fraudster pretends to be.
So the decision should not sit inside the model at all. The agent collects answers and passes them to a verification service or rule set, which returns pass or fail. The agent reports the result and acts on it. The steps for wiring that up are in how to connect an AI agent to your identity verification service.
Which checks can the agent run?
Strongest to weakest:
- Possession of a trusted device. A push approval in the customer's app or a code sent to a number already on file. The agent triggers it; the customer approves.
- Knowledge checks against sealed records. Recent transaction amounts, date of birth, account details. The agent asks, the rule set compares.
- Caller line identity. Useful as a signal, never as proof, because numbers can be spoofed.
- Voice. Not a proof of identity on its own. Cloned voices are cheap, and a voice agent should not be the one deciding that a voice "matches".
Which combination opens which conversation is a policy decision, not the agent's. Checking a balance may need one factor; changing contact details may need two. The order of questions and the wording are set out in an identity verification script template for support agents.
Checking a customer's passport or driving licence for onboarding is a different job again, covered in whether an AI agent can verify a customer's identity documents.
What may the agent say, and when must it stop?
| Situation | The agent | Stays with a person |
|---|---|---|
| Caller passes | Proceeds to the contact reason within the access the pass grants | Nothing routine |
| Caller fails one question | Moves on or offers the device factor; never says which answer was wrong | Nothing yet |
| Caller fails the check | Says it cannot discuss the account; offers a secure route, such as the app | Overrides of any kind |
| Caller partly passes and pushes | Holds; offers a callback to the number on file | The decision to proceed |
| Caller says they are calling for someone else | Takes details only | Checking authority, such as a power of attorney |
| Caller is distressed or says it is urgent | Keeps the rules; transfers if needed | Any judgement on urgency |
The second row matters. "That date of birth doesn't match" tells a fraudster which piece of stolen data is wrong. The agent says only that verification was not completed.
An illustrative example
Take a building society's voice agent. A caller asks about a recent withdrawal and gives the right name and postcode but the wrong date of birth, then says they are a relative helping an elderly member.
The agent does not treat the right postcode as partial credit. It says it cannot discuss the account without completing verification and offers to send a code to the phone on file. The caller declines, saying the member is unwell. The agent explains that a relative needs recorded authority, takes the caller's details and a callback number, and holds the case for the team that handles third-party access. The record shows each question asked, each result returned by the rule set, and the reason the call did not proceed.
What controls make it safe?
- Decision outside the model. The pass or fail comes from a rule set; the agent cannot change it.
- No answer leakage. Fixed responses after each failed answer, with no hints.
- Attempt limits. A set number of failures ends verification for that session and flags the account.
- Codes only to details on file. Never to a number the caller gives during the call.
- Full record. Questions, results and outcome are filed, so a disputed call can be reconstructed.
The agent has an identity of its own too. It acts under credentials that identify it as an agent, which is the idea behind a non-human identity.
Where Pryme fits
In Pryme, verification results arrive from the system of record as sealed facts, and what the caller says is stamped as declared. A declared answer can be compared, never accepted on its own. Access to the account is bound to the verification result for that session. See the AI support agent that knows when to say no.
Questions people ask
Should a voice agent use voice biometrics?
Only as one factor among others, and the match decision should sit with the biometric service, not the agent. Treat voice alone as insufficient.
Can the agent re-verify mid-call?
Yes. If the caller moves from a low-risk question to a high-risk request, such as changing contact details, the agent should ask for the stronger check before continuing.
What should the agent do if it suspects the caller is a fraudster?
Keep to the script, refuse the request in neutral words, and flag the account. It should not accuse the caller or reveal its suspicion.