Trust and privacy
Most shopping bots are tuned to close a sale. This one is tuned to be trustworthy first. A short set of honesty rules is appended to every prompt last, after the merchant's own instructions, so the rules hold no matter how the store is configured. Personal data stays behind a login gate, and the plugin keeps customer details out of the model where it can.
The rules are absolute and appended last
The system prompt is assembled in layers: a base persona, then a bounded slot where the merchant can set tone, off-limits topics and per-category guidance, then any context a feature pack adds through a filter. The trust rules are added after all of that. Because they come last, a merchant preference, a custom prompt, or a third-party filter can shape the assistant's voice but cannot weaken or remove the policy. This is structural, not a matter of phrasing the merchant just happens to respect.
The merchant slot says so in plain language. The preferences a store sets are introduced as advisory, with a note that the honesty rules below always take precedence.
What the guardrails actually say
There are six rules, and they read the way a careful salesperson would behave:
- No fake urgency or scarcity. The assistant never invents "only N left", countdowns, "selling fast" or "limited time". Stock and low-availability claims appear only when a tool result actually reports them, and then it states the real number.
- Respect a stated budget. If a shopper gives a budget, the assistant does not push past it. When nothing fits, it says so plainly instead of steering them higher.
- Be honest about extras. Recommendations and cross-sells are framed as optional suggestions, never as required or pressured. Coupons, discount codes and wallet bonuses are mentioned only when they are real and currently applicable, from a tool result, never implied.
- Ground every product fact. Details, prices, stock, reviews and ratings come from tools like
search_products,get_product_detailsandget_product_reviews. The assistant summarises only what those tools return. - Abstain over guessing. When the assistant does not know, or a tool returns nothing, it says it could not find the answer and offers a real next step rather than fabricating one.
- Never block human support. For order status, account issues, refunds or returns, it points the shopper to the store's support team or to sign in for their own data, and it always allows reaching a human.
These are not aspirations. The test suite pins the exact policy text so it cannot quietly drift, and a set of deterministic eval checkers measures the behaviour: scarcity violations, budget violations, grounding violations, whether an escalation path is present, and whether the assistant abstains when it should.
Grounding: state facts from tools, or abstain
The honesty rules are only credible because the assistant cannot answer about your store from memory. Every product, price, stock figure, review and order detail is read live through a tool call, and the assistant is told to summarise only what the tool returns. When a tool returns nothing, the correct move is to abstain.
Money actions hold the same line. A reorder reads the current price from the live product rather than echoing an old number, a verified variation must still belong to its parent, and the checkout tools report the real cart, shipping and total with an explicit null where there is no coupon, never an invented code or figure.
Personal data sits behind a login gate
The public chat endpoint is open to guests on purpose, so anyone can browse and ask product questions. The nonce and rate limit on that endpoint are there for abuse protection, not as an authorization boundary. The real boundary is two layers deep, applied only to tools that touch personal data such as orders and the wallet:
- Central login gate. A personal tool declares
'personal' => true. The tool registry checks login before the tool's callback runs, so a guest is blocked centrally and a personal tool cannot leak by forgetting to check. - Per-record ownership. Being logged in is not enough. Each personal tool compares the record's owner against the current user before returning anything, so one signed-in shopper can never read another shopper's order or balance.
A blocked guest gets a clear, grounded result rather than a dead end:
{
"error": "Please log in to access your account information.",
"requires_login": true
}
The requires_login flag lets the widget steer the shopper to sign in instead of treating it as a generic failure, which keeps the human path open while keeping data private.
Keeping PII out of model context and logs
Where personal data has to be handled, the plugin minimises what leaves the boundary. Tool results carry only the fields an answer needs, for example an order's number, status, date and total rather than a full customer record. Email addresses are masked before they go anywhere near model context or logs, keeping the first character and the full domain and hiding the rest:
jane@example.com -> j***@example.com
A value that is not a clean local@domain shape is masked to *** rather than echoed back, so a malformed input cannot leak verbatim. No personal customer data is sent to the AI provider unless the customer types it into the chat themselves.
Your catalogue and chats are not resold
Conversation history and the product data relevant to a session are sent only to the single AI provider you select and configure with a key, and nothing is sent until you choose one. You pay that provider directly; the plugin does not proxy your key or route your data through a third party of its own. There is no analytics product underneath this that resells your catalogue or your customers' chats.
Two optional features extend where data can go, and both are off until you turn them on. Semantic search sends product text, never prices, stock or customer data, to an embeddings provider you choose. An optional external Qdrant store holds only vectors and product IDs. In every case you pick the provider and review its privacy policy before enabling it.