AI and tools
Visitor verification
Before the AI can tell someone about their order, it has to know who they are. Verification is how a visitor proves an email address belongs to them.
How it works#
- The visitor asks something that needs their data.
- The AI asks for their email address.
- AskVoro emails them a code.
- They type it into the chat.
- For the next hour, that conversation is associated with a verified email.
Tools that require verification become available on their next message.
What the cookies do and don't mean#
A visitor carries two cookies, and neither one is identity:
| Cookie | Lifetime | Means |
|---|---|---|
askvoro_visitor | 30 days | Which anonymous browser this is |
askvoro_chat | 12 hours | Access to one specific conversation |
They keep a conversation attached to a browser across a refresh. They prove nothing about who the person is.
Only the verified email session is identity, it lives server-side, and it lasts one hour. A cookie can be copied; the session can't be forged from the browser.
Setting it up#
Verification tools only exist when your workspace has both a site URL and a signing secret configured. Without them the AI has no way to ask your systems about anyone, so it won't offer.
Once configured, AskVoro sends your backend a signed user.lookup event to ask
whether an address is a known customer, and identity.verified once the code is
confirmed. Both use the same signed envelope as everything else — see
The webhook contract.
Where the security boundary actually is#
This is worth being precise about, because getting it wrong is expensive.
Requiring verification on a tool controls exposure: whether the AI can see and call it at all. That is not the same as enforcement.
Your backend is the enforcement boundary. When AskVoro calls a POST tool, it injects the verified email server-side — the model cannot omit it, change it, or invent one. Your handler must scope its query to that email and return only that customer's data.
Treat every request as though the email is the only thing you can trust, because it is the only thing that has been verified. Never let a parameter the model supplied — an order number, a customer id — widen what a request can reach.
What visitors experience#
They type an email, get a code, type the code. It's ordinary, and it's worth the friction: it's what makes "where's my order?" answerable instead of "please email support".
In development the code is printed to your dev server terminal instead of being emailed, so you can test the whole flow without a mailbox.