How do you stop an AI agent giving out the wrong account details?

This is the first question any serious support team asks, and it is the right one. An agent that will read a balance, an address or an order history to whoever happens to be on the line is not a support agent, it is a data breach with a friendly tone.

The rule that does the work

Nothing account-specific is said before verification passes. Not partially, not with the digits obscured, not as a hint. The agent can discuss your published policies, your opening hours and your returns window with anybody, because that information is already public. Everything tied to a specific customer sits behind the check.

What counts as passing is your decision, not ours. Common choices are a one-time code to the number or address already on file, a match against details the customer should know, or an existing session in your own product. The important property is that the answer comes from something the real customer has rather than something a caller can guess.

What happens when verification fails

The agent offers a callback from your team and stops. It does not offer an alternative question, it does not accept a different detail as a substitute, and it does not let the caller talk it into a compromise. This is the behavior that matters most, because a system that can be negotiated with is a system that will be negotiated with.

Some legitimate customers will fail verification. That is a real cost and worth naming honestly. The alternative, a check loose enough that nobody fails it, is not actually a check. The right response is to make the fallback fast and pleasant rather than to weaken the rule.

Read access and write access are different decisions

Verifying somebody well enough to tell them their order status is not the same as verifying them well enough to change the delivery address. Most teams start by allowing the agent to read a fairly wide set of things and to change almost nothing, then widen the write permissions slowly as they build confidence.

• Read, after verification: order status, balance, plan, appointment times, ticket history.
• Write, once you switch it on: password reset, address update, resend a receipt, start a return, reschedule an appointment.
• Never without a person: anything that moves money above your threshold, anything that closes an account, anything contested.

Log what was verified, not just what was said

The transcript alone is not enough. The record should show which verification method was used and whether it passed, so that if a question ever arises about a disclosure you can answer it from the log rather than from memory. This is cheap to do at the start and impossible to reconstruct later.

The failure mode to design against

It is not a caller who tries to break the rules directly. It is the gradual erosion where somebody adds an exception for a common frustrating case, then another, and six months later the check has holes nobody can see from any single change. The defense is to keep the verification rule in one place, review it as a whole, and treat every exception as a change to the rule rather than a special case.

An agent is easier to hold to this than a person is, which is the genuine advantage here. A human under pressure from a frustrated customer will sometimes bend. The agent applies the same rule at 3 AM on a bank holiday as it does on a quiet Tuesday, and it writes down that it did.