Know who is chatting before anything changes
A visitor proves they own their e-mail with a code, right in the chat. Only then can your team or your AI agent change an order, an address or an account for them.
Anyone can type your customer's e-mail in a support chat.
A stranger types a customer's name and e-mail into your chat, asks where the order is, then asks to send it to another address. If your team or your AI agent looks things up by e-mail and acts, the parcel is gone. No password was guessed. Support chat was simply the easiest door.
An AI agent makes this worse, because it follows the conversation. A prompt that says "check identity first" is a request. Verification has to be a fact the server knows. Read the longer story inLive chat is an account takeover door.
How it works in three steps.
- 1
Someone asks for a change
A visitor wants a new shipping address, a cancelled order or account details. An agent clicks "Ask to verify", or the AI agent asks by itself, or an AI app calls request_verification over MCP.
- 2
A card appears in the chat
The visitor gets a 6-digit code by e-mail, in your widget's look and with a one-click confirm link. They type it into the card.
- 3
The team sees it, the server enforces it
The inbox shows a "Verified" badge with the time. The AI and your actions check the status on the server, so "I already verified" gets nobody anywhere.
Hard to get around by design.
Short-lived codes
A code is valid for 10 minutes and allows 5 attempts. Then it is gone.
No mail-bombing
Resends are limited per visitor and per e-mail address, so the chat can't be used to flood someone else's inbox.
Stored hashed
Only a hash of the code is kept. Agents never see it and it never enters the transcript.
Status is server-side
The AI can't be talked into "I already verified". Whether a visitor is verified is a fact the server holds, not something said in the chat.
Changing the e-mail cancels it
A visitor who verifies one address and then claims another is unverified again.
It expires
A verification holds for 24 hours for that visitor in that browser. A signed identify re-verifies on every page view.
Logged-in customers, never asked for a code.
Sign the customer's lowercased e-mail with your widget's identity secret on your server. You find the secret in the widget's settings, under Security. The visitor counts as verified without a code, on every plan. An identify without a signature still works, and stays unverified.
// On your server, for the logged-in customer
const signature = createHmac("sha256", process.env.LUXIVO_IDENTITY_SECRET)
.update(user.email.toLowerCase())
.digest("hex")
// In the page
Luxivo("identify", { email: user.email, name: user.name, signature })Actions that run only for verified visitors.
On Pro and Business you define actions such as "Change shipping address" or "Cancel order": a name, what it does for the AI, its fields and a webhook URL. The AI agent and your agents can run one only for a visitor verified in the last 30 minutes. The server enforces it, not the prompt. Luxivo posts signed JSON, and your shop answers with an optional message that is passed on to the customer.
POST https://shop.example.com/hooks/luxivo
X-Luxivo-Signature: ...
{
"action": "change_shipping_address",
"fields": { "order": "1042", "address": "Main Street 5, Warsaw" },
"visitor": { "email": "anna@example.com", "verifiedAt": "...", "method": "code" },
"conversationId": "..."
}
200 { "message": "Done. The parcel will go to Main Street 5." }The setting "Orders need a verified e-mail" also keeps the cart and orders your page reports away from the AI until the visitor is verified.
Verifying a chat visitor, compared.
| Tool | Signed identity for logged-in users | E-mail code in the chat | Bot or AI after verification |
|---|---|---|---|
| Luxivo | HMAC-SHA256 of the e-mail, every plan | In chat, every plan, started by an agent, the AI or an AI app | Orders hidden from the AI until verified. Actions run only after a verification in the last 30 minutes (Pro) |
| Intercom | JWT for logged-in users | Yes, in beta: before a data connector or as a workflow step, 3 attempts | The code gates data connectors Fin or workflows call. Their docs don't say it covers every Fin action |
| Zendesk | JWT for the Web Widget and mobile SDK | Not described in their docs | By default only verified e-mails become identities. Not described for bots running actions |
| Crisp | HMAC-SHA256 of the e-mail, from Mini | A workflow can request verification by e-mail | Not described in their docs |
| tawk.to | Secure Mode: a server-side hash for visitor details | Not described in their docs | Not described in their docs |
| Tidio | None. Identify sets e-mail and name without a signature | Not described in their docs | Shopify order status asks for e-mail, order ID and optionally a zip code |
| Chatwoot | HMAC of the identifier with the widget's token | Not described in their docs | Not described in their docs |
From each vendor's documentation on Oct 27, 2026. "Not described" means we found nothing in their docs, not that it can't be built with their APIs. LiveChat's customer identity provider only links a customer's chats to your login, and its docs describe no e-mail verification.
Questions about verification.
What is identity verification in live chat?
Proof that the person chatting controls the e-mail address they claim, before the team or the AI agent changes something for them. In practice it is either a signature from your server for logged-in users, or a one-time code sent to the visitor's e-mail.
Why isn't asking for an e-mail address enough?
Anyone can type anyone's e-mail address into a chat window. If your team or AI agent looks up orders or changes an address based on that, a stranger can read someone's order or redirect a parcel. A code sent to the address, or a signature from your own login, shows control of the mailbox or the account.
Do I need to write code?
Not for the e-mail code. It is on for every plan and works on any website. For logged-in customers you can add a signed identify, which is a few lines on your server. Verified actions need a webhook on your side that does the actual change.
Does it cost extra?
No. E-mail verification and signed identify are included on every plan, including Free (Free). Verified actions, where the AI agent or the team runs a change on your shop, are on Pro and Business.
Can the AI agent be tricked into skipping verification?
Not by what is said in the chat. Verification status is held on the server. The setting "Orders need a verified e-mail" keeps the cart and orders from the AI until the visitor is verified, and a verified action only runs for a visitor verified in the last 30 minutes. The check is in code, not in the prompt.
What does my shop receive when an action runs?
Luxivo posts signed JSON to your webhook, with the header X-Luxivo-Signature. It contains the action, the fields, the visitor's e-mail with the time and method of verification, and the conversation ID. Your shop answers 2xx with an optional message, which the AI or the agent passes on. Check the signature, and still check in your own system that the e-mail owns the order.
What if the visitor is already logged in on my site?
Use signed identify. Sign the lowercased e-mail with the widget's identity secret on your server and pass it to the widget. The visitor counts as verified without a code. An identify without a signature still works for filling in a name and e-mail, but stays unverified.
Is it GDPR-friendly?
Luxivo acts as your processor. The code is sent only to the address the visitor gives, and only a hash and timestamps are stored. See the privacy policy for what a verified action sends to your webhook.