Security and data handling

This page is the mechanism behind the Privacy Policy. Where the policy states an obligation, this page links to it rather than restating it — two public pages wording one promise differently are two promises.

Two structural rules

The part that reads a message cannot act. Interpretation sees the untrusted material — the new text, the quoted history, attachment text, the subject, filenames — and can neither send nor write anything. The parts that act see only typed, verified facts: which company, which location, which variant, which quantity, with a span pointing at the words each one came from. And no model writes a sentence a retailer reads: every reply is one of the desk’s templates with slots filled from your own records. This is a property of how the pieces are wired together, not a setting, and it cannot be turned off.

Every action needs a sender that verifies. That means DMARC passing, or an aligned DKIM signature passing, or a verified chain from the forwarder that handed us the message. A pass merely claimed by a header we cannot check counts as unverified. No setting weakens this, informational replies included.

On top of that, the sender has to be a contact on one of your companies — synced from your records, or one you attached yourself. An unknown sender gets no reply of any kind: what your wholesale prices are is not a question a stranger gets to ask. The reply goes to the address that authenticated and never to a “reply-to” pointing somewhere else; a reply-to outside that company does not redirect the answer, it stops it. Anyone copied in is narrowed to that retailer’s own addresses and domains, and a free consumer mailbox domain never counts as a company’s domain.

The gate that attacks it

A structural claim is worth what the attempt to break it is worth, so there is a gate that attempts it and it runs before anything ships. The corpus is 59 adversarial cases and 10 ordinary ones, run once against each of the 2 systems of record — 138 cases a run, through the same entry points the product uses, driving the shipped desk.

What was tried:

• Instructions hidden in the message body
• …in quoted history further down the thread
• …in the text of an attachment
• …in an attachment's filename
• …in the subject line
• A Reply-To pointing somewhere else
• A rival retailer added to Cc
• A ship-to address swapped at the last moment
• A lookalike domain, a free-mail address, our own mail replayed
• A purchase order replayed to order twice
• A price moved while the action was still held
• A draft edited in the Shopify admin mid-hold

The interpreter is hostile in every injection case. It is scripted to say exactly what the injected text demanded, so no case can pass because a model happened to behave well. What refuses has to be the structure.

The 10 ordinary messages are half the claim. A desk that never acts is trivially safe. Each of them must cause exactly the effect it declared — including the 2 whose correct answer is to do nothing at all — and the gate fails if one does not.

11 of the 59 still ended in an action. A reply went out, and in 8 of them an order was created and committed. Those are not failures: the attack was ignored and the honest request underneath it was answered. The number the gate holds to zero is the one it defines as consequential — effects beyond the ones a case declared correct — and what none of them got was the thing the injected text demanded.

Three things it is not. It is not an outside audit — it is our own gate, which is precisely why it is run before every release rather than once a year. It does not run against a real store: the desk and the kernel are the shipped ones, and the system of record is a stand-in. And it is not a percentage of anything: these are counts of a fixed set of cases.

What the model sees, and what happens to it

Only what interpretation needs: the new text of a message, its labelled quoted and forwarded parts, text extracted from attachments, the subject and filenames, and a structured snapshot of the last quote. Never a credential, and never the raw prior thread beyond the last two quote-stripped turns. What comes back is typed claims with spans, stored as claims.

The calls go to Anthropic through Vercel’s AI Gateway; both are named as sub-processors in the Privacy Policy and in the DPA, so a merchant can object to either. Both providers publish that API inputs and outputs are not used to train models and that the gateway does not retain request bodies. That is their published position, and it is stated here as their position rather than as something we have verified.

Where it lives, and for how long

• Storage and encryption. Where data rests, and what is encrypted, is set out in privacy §5. Your system of record is never moved: a Shopify store stays on Shopify and a Zoho organisation stays in its own data centre.
• Tokens. A system-of-record or mailbox token is sealed under a key held only in the hosting secret store and bound to its own row, so a copied value cannot be opened anywhere else — privacy §5.
• Retention. Audit records 90 days, the event feed behind a receipt 180 days, and the TEXT of a message 180 days after it arrived — the receipt outlives it, because it names a job and an order rather than a person’s prose. These are product-wide and enforced by a job that runs hourly, not a setting a merchant sets; there is no such setting. privacy §6.
• Tracking. The product itself carries no analytics or measurement script of any kind, because its URLs identify exceptions and conversations. This marketing site runs no analytics at all: no measurement tag is built into it. privacy §8.
• Who can reach production. Access is limited to the operator and is logged; sign-in for your own staff is email and password with a 15-character minimum and rejection of known-compromised passwords. privacy §5.

Erasure

Shopify. The three mandatory requests are carried out inside the request that makes them, not queued: a data request assembles what this tenant holds about that contact into the merchant’s own audit record; a redaction erases that contact’s identities and addresses and the text of every message they wrote, including text extracted from their attachments, leaving the receipts. Uninstalling discards the store’s credentials and stops every sync at once. About 48 hours later Shopify sends the third request, and that one erases everything the store backs. An installation uninstalled for more than 30 days is erased by a nightly backstop whether or not that request arrived.

Zoho. There is no automatic path, and no honest way to claim one: Zoho sends no uninstall or redaction signal for us to act on. Erasure on request is done by hand, within the 10 business days the DPA commits to. Both legal documents say this in words rather than describing a mechanism that does not exist.

The public surface

Every public intake route — the webhooks, the install handshake, the invite link — is rate limited before it reaches the database. Webhook routes verify their signature against the raw body before anything else happens, and a webhook is treated as a hint: it is de-duplicated, the record is re-read from the source, and it is applied only if it is newer than what we already had. A retry can never produce a second order or a second email.