Here’s exactly whathappens to their data.
Their number, their address, what they paid. Taking orders means holding real information about real people. Here is exactly how it is kept: every mechanism, and the three things we refuse to claim.
- Email and phone never reach the AIStripped and replaced before any model call
- Card numbers never touch usStripe Hosted Checkout, straight to your account
- One shop can’t see another’sEnforced at the database, checked at build
The AI, specifically
What reaches the assistant, and what never does.
Every message is cleaned before the model sees it. Watch one go through. This is the mechanism that runs on every DM, not a diagram of an intention.
hi! it’s Maya, can you text me at [PHONE_1] or email [EMAIL_1] when the bouquet’s ready? 🌸
hi! it’s Maya, can you text me at [PHONE_1] or email [EMAIL_1] when the bouquet’s ready? 🌸
NAME AND HANDLE STAY, SO IT CAN ADDRESS THEM. THE NUMBER AND EMAIL DO NOT.
THE ONE THING WE CANNOT STRIP OUT
Typed messages are cleaned. Photos and voice notes are not.
An inspiration shot, a screenshot of a conversation, a picture of a document, a voice note recorded in the car: those go through in full, because there is no reliable way to redact an image or a recording.
If a customer sends a screenshot with their phone number visible in it, the assistant sees the phone number. We would rather you knew that from us than found it out later.
It reads the same way in the privacy policyWhat is true
Eight things that are already true of your data.
Plain version first. The technical line underneath is for the buyer who wants it.
One shop can never see another shop’s customers
Your customer list, your orders, your numbers: walled off from every other business on WavyOS. Not a rule we follow carefully. Something the system will not let happen.
Enforced at the database · a query that could reach across two businesses fails our build
Your customers’ email and phone never reach the AI
Before a message reaches the assistant, email addresses and phone numbers are pulled out, stored on our side, and swapped for placeholders. It can still send the receipt; it just never holds the address it went to. What it keeps is what it needs to do the job: your customer’s name, their Instagram handle, and, if you deliver, the delivery address.
Emails and phone numbers extracted and replaced with status codes before the model is called · name, handle and delivery address deliberately retained
Card numbers never touch WavyOS
Checkout happens on Stripe’s own hosted page. The card number goes from your customer to Stripe; it is never typed into anything we run, and the money lands in your Stripe account, not ours.
Stripe Hosted Checkout · connected accounts · no card data in our database, ever
A link we send your customer is useless to us afterwards
Deposit links, order links, booking links. We keep a fingerprint of each one, enough to recognise it when it comes back, not enough to rebuild it. The working link only ever exists in the message that went out.
Access tokens stored as SHA-256 hashes only · never kept in readable form
Documents with your details on them are encrypted, and tamper-evident
If setup needs a filing or an ID with a date of birth or an SSN on it, it is encrypted before it is stored, with a kind of encryption that notices if the file has been altered. Anything touching a government ID also refuses to run unless it has been switched on deliberately. The default is no.
AES-256-GCM authenticated encryption · live in production · government-ID features fail closed
Nothing gets into your account by pretending to be Stripe
Every payment confirmation, every Instagram message, every text arriving at WavyOS is checked against a cryptographic signature before it is believed. Unsigned or replayed, it is dropped.
Instagram HMAC · Stripe signatures · Telnyx Ed25519 with a five-minute replay window · timing-safe comparison throughout
Internal access is locked down hard
The tools we'd use to help you require more than something that can be guessed or reused, and every door on that side is checked before it ships. Sessions expire on their own, and repeated wrong attempts get slowed down.
Hardware-backed authentication · every internal route gated, checked at build
Old data gets deleted on a schedule, and on request
Retention purges run on their own: old logs, expired documents, stale drafts. A customer who asks to be erased is erased from every table that holds them, and an invoice keeps only what the tax rules require it to keep.
Scheduled retention purges, watchdog-monitored · erasure request covers every registered table · SMS opt-out records are kept on purpose, so STOP stays STOP
Underneath all of it: everything is stored on managed infrastructure with encryption at rest and TLS in transit, and payments run through Stripe into your own account, so card details are never ours to hold.
The systems
How it stays that way when nobody is looking.
Rules people follow drift. These are the parts that do not depend on anyone remembering.
Redaction chokepoints
Inbound history, the assistant’s own output before re-entry, tool results, memory extraction, and embeddings all pass through the same redactor. If it is unavailable, the AI call is skipped rather than sent raw.
Row-level tenant isolation
Every table that holds customer data carries a database policy keyed to the business. The public key cannot read any customer row, tested live.
Build-time guards
Checks in our pipeline fail the build on a cross-tenant query, an ungated admin route, a leaked secret in a page, or an unguarded AI client.
Scrubbed logs and error reports
Emails, phones, addresses and message bodies are redacted before a log line or crash report leaves the server, so they never sit in a monitoring tool.
Fail closed by default
Missing key, missing config, missing redactor: the feature refuses to run. Nothing on this platform quietly downgrades to a less safe path.
No data sales, no ad networks
We do not sell customer data and there is no advertising pixel on the storefront or the portal. The subprocessors we do use are listed by name in the privacy policy.
What we don’t claim
The three things we are not going to tell you.
A security page that only says flattering things is the exact signal a careful buyer is scanning for.
We are not SOC 2 certified.
That is a formal audit large enterprises ask for. We have not done one, and we will not word this page to suggest otherwise.
We have not been through an outside penetration test.
Everything above is our own engineering, verified in our own code. When that changes, it will be said here with a date on it.
Nobody can promise nothing will ever go wrong.
What we can do is build the parts we control to fail shut instead of failing open, which is why the defaults on this page are all refusals.
Still want to ask something a page can’t answer?
Email us. It goes to the person who wrote the code this page describes.