Before you let AI touch a customer account, check these five things

There is a line most AI support tools never cross. On one side the assistant answers questions from your documentation. On the other it looks up a specific customer, and then changes something for them.

Crossing that line is where the value is. It is also where a support tool stops being a widget and starts being a system that can cause real damage: a domain pointed at the wrong servers, a subscription cancelled by accident, a booking moved for the wrong person.

These five checks are the ones worth insisting on, whoever you buy from.

1. How does it know who it is talking to?

A chat window knows nothing about the person typing. If the assistant asks for an email address and looks up whatever matches, then anyone who knows a customer's email can read that customer's data. People reuse email addresses in support chats all day, so this failure is not theoretical.

The fix is a signed identity. Your own backend, the one that already authenticated the user, creates a short lived signed token and passes it to the chat. The assistant reads who the visitor is from that token instead of from what they typed.

Ask the vendor: what proves identity, and what happens when nothing does. The correct answer to the second half is that account actions are refused and the visitor is asked to sign in.

2. Is every lookup scoped to that person?

Verified identity is not enough on its own. The lookup itself has to be scoped.

Concretely: when a signed in customer asks about a domain, the system should fetch domains belonging to that customer and check the one they named is in the list. Not fetch the domain and then decide.

There is a small detail that says a lot about how carefully a system was built. Ask what happens when a customer asks about something that exists but is not theirs. The right answer is that it looks exactly like something that does not exist. Different answers to those two cases let anyone map your customer base one guess at a time.

3. Can a mistake be undone, and does anything stop one?

Reads are recoverable. Writes are the ones that wake you up.

Two controls handle most of the risk.

Confirmation for anything that changes. The assistant says exactly what it is about to do, the customer confirms with a one time code, and only then does it run with the arguments captured at the moment of the proposal. That last part matters: if the system re-reads the conversation after confirmation, a later message can change what happens.

Freshness. A sign in from this morning is not proof that the same person is at the keyboard now. Requiring a recent session for changes costs a refresh and prevents the shared computer problem.

Then there are the actions you simply do not automate. In our WHMCS module, domain transfer codes are emailed to the address on the account and never shown in chat, and cancellations are switched off unless the owner turns them on.

4. What is written down afterwards?

If you cannot answer "who changed this and why" a week later, you do not have a system you can defend to a customer.

A good setup writes three records. One in the tool, one in the system that was changed, and one email to the customer telling them what happened. That last one is not decoration. It is how a wrong change gets caught in an hour instead of at renewal.

Ask to see a real log line from a real change during the demo.

5. What does it refuse to do?

Every vendor lists capabilities. Ask instead for the refusals.

A grown up answer sounds like this: it refuses for visitors who are not signed in, refuses changes without a confirmation code, refuses when the sign in is stale, refuses to show secrets, refuses actions the administrator has switched off, and refuses again at the last step even when the request came from inside the system.

The last one matters more than it sounds. Controls placed only in the conversation layer can be bypassed by anything else that calls the same connector: an automation, a misconfigured skill, a future feature. The check belongs next to the action, not only next to the chat.

A practical starting order

1. Turn on lookups only. Let it read, not write.
2. Read a week of real conversations.
3. Switch on one change, the one your team repeats most.
4. Watch the audit log for a week.
5. Add the next one.

Nobody regrets this order. Plenty of teams regret the opposite.

Why we built it this way

MagizAI runs account actions through the same set of gates every time: signed identity from your own backend, lookups scoped to the verified person, a confirmation code that releases exactly one run, a freshness rule for changes, an audit trail in both systems, and a final check at the connector that no other code path can skip.

You can read how that works for hosting in the WHMCS module, or see the wider picture on our security page.