Security

1. Nobody reads a stranger's order

A storefront chat is anonymous — nothing about a browser proves who is typing. So BuzzDesk treats every conversation as unauthenticated until the shopper supplies both the email used at checkout and the order number, and they match that exact order.

• Exact match only. The platform's order search is deliberately loose; BuzzDesk re-compares the order number exactly and compares the email with a constant-time check, so a near-miss is never accepted.
• One indistinguishable failure. "No such order", "wrong email" and "order has no email" all return the identical answer. The widget can never be used to test whether an order number is real.
• Pinned after verification. A verified conversation is locked to that single order. There is no parameter — not even an internal one — that lets the assistant fetch a different order in that session.
• Rate limited. Failed attempts are counted per browser session and across the whole store on a rolling window, so guessing is throttled rather than merely slowed. Attempts are stored as a one-way hash of the email and expire after 24 hours.

2. The AI cannot write to an order

There is no tool in the assistant's tool set that reaches an order write. The strongest thing it can do is create a pending request. Applying it is gated four ways:

• You must be a signed-in merchant of that store, and the request must belong to it.
• The pending→approved transition is a single atomic claim, so a double-tap or a replay can't apply a change twice.
• The order is re-read from OpoShop at the moment you approve. If it has shipped or changed since the draft, the write is refused — not applied to stale facts.
• Item swaps are never machine-applied at all; pricing and variant choices stay with you.

If a write fails, the request is marked failed with the real reason — never silently "approved".

3. Your API key

• Encrypted at rest with AES-256-GCM (authenticated, so tampering fails closed) under a key derived with scrypt from a server secret.
• Stored in a field excluded from every ordinary database read, and fetched explicitly only when calling your provider.
• No API response can return it. The UI only ever shows the last four characters.
• Never written to logs, never included in analytics, never sent anywhere but the provider you chose.
• Fail-closed: in production there is no platform key to fall back on, so a store without a key cannot spend anyone else's budget — the chat simply hands off to a human.

4. One store can never see another's data

Every record BuzzDesk stores — conversations, messages, change requests, settings, knowledge — is scoped to a store, and every query filters on the store from your session, never from a URL or request body. A user is unique per (owner, store), so the same person installing on two stores gets two independent identities and two independent datasets. A boot-time audit verifies this and reports any residual sharing.

5. The embedded session

BuzzDesk mints an admin session only when store ownership is proven with the caller's own credential — either a verified identity check using their token, or OpoShop's own validation of it during an authorization exchange. "This store is already connected" is never accepted as evidence. A regression probe fires forged-token attacks at the live deployment after any change to that code path.

6. On your storefront

The widget lives in its own fixed layer appended to the page. It does not read, restyle or move any theme element — with the widget present and absent, every element on the page measures to the same pixel. It never renders on checkout, never renders in your theme editor, and renders nothing at all if it cannot load. The resting state is a small corner launcher; the larger panel appears only after a shopper taps it, and closes in one tap.

Reporting an issue

Found something? Email brandon@tryfound.io with the details and we'll respond quickly. Please don't test the identity check against a real merchant's live store.