Sign in with the account you already have — Kav never holds the password

"Where's my order?" is a question that only means something once the assistant knows whose order it is — and how it learns that is the part most chat integrations get wrong, either by trusting whatever account number the customer types or by building a second, parallel login just for the bot.

Federated, not duplicated

Kav doesn't hold a password for the store's customers, and it doesn't ask for one. Identity federates to the account the store already runs — the same login a customer already uses on the website — so there is no second credential to manage, phish, or leak, and no separate "chatbot account" for a customer to set up.

What arrives on screen

Once signed in, the order card — status, order number, expected arrival — comes from the store's own order system through the exact same typed contract every other capability on this platform uses. It's the identical mechanism that renders a municipal resident's property-tax balance: a template fed by the connector's typed output, never a sentence the model composed from a number it saw once.

The part that never happens

There is no code path in this platform where an account number typed into a chat window is trusted as someone's identity. A capability that needs to know who's asking has no input field for an identity value at all — it resolves the session's own token, server-side, every time. An id that arrives from the caller and gets trusted is treated as a defect, not an edge case to handle gracefully.

Why that discipline outlasts the demo

A chatbot that trusts a typed account number works fine until someone types a number that isn't theirs. The failure isn't rare because it's unlikely — it's rare because the platform never built the path that would make it possible in the first place.