Privacy by architecture, not by policy.
Anyone can promise to protect your data. HOLLOU is built so the protections that matter most don’t rest on a promise — every merchant runs on their own server, and our central reporting receives counts, never conversations. Here’s exactly how, in plain language, including the places where you still have to trust us.
What HOLLOU can’t do.
The most useful thing we can show you isn’t a list of promises — it’s the things the system is built to make impossible.
Put your conversations into central reporting
Central reporting receives only aggregate counts — sessions, cost, health — and rejects any payload that carries message content. Your transcripts are stored in your own database; the copies we keep elsewhere are listed in the answers below. The message being answered does go to a model provider to generate the reply — that is how the agent writes anything at all: Anthropic or Microsoft’s Azure OpenAI Service, whichever is primary for your instance, and the other one if the primary is unavailable. The shopper’s question also goes to NVIDIA, to search your catalog. None of it passes through our central reporting.
Mix your data with anyone else’s
There is no shared database to mix it in. Each merchant runs on their own separate server.
Sell or repurpose your data
Your data is processed by our sub-processors (AWS, Anthropic, NVIDIA, and Microsoft Azure OpenAI Service, as the primary or the backup answer provider) purely to run the service, and by no one else. It is never sold, and never shared for anyone else’s purposes.
Work on any site but yours
Your key is locked to your domain. A copied install snippet is rejected on any other website.
Open a dashboard with the public key
The embedded widget key runs the assistant and nothing more. Your console is a separate, real login.
Six commitments, each with the mechanism that makes it true.
Your own server
Your own database, your own disk, your own login. Your data never shares a database with another merchant's — that separation is structural, not a filter we remember to apply.
In transit, on every connection
Every connection is HTTPS/TLS, under a certificate issued for your own instance. Disk encryption at rest is not switched on yet — we'd rather say so than imply it.
Only what a lead needs, never sold
A shopper's name, email or phone is captured only when they choose to share it. Never sold, never shared with third parties.
You own your data
Export it, delete it, or rotate your key anytime. Your key is bound to your domain, so a leaked snippet is rejected on any other website.
Answers from your catalog
The assistant answers from your own products and pages, not from the model's general knowledge. When they don't cover a question, it is built to say so rather than guess.
Central reporting sees counts, not chats
Central reporting receives only aggregate metrics, and rejects any payload that carries message content. Your transcripts are stored on your own server; on Pro and above you read them in your console, masked by default. The copies we keep elsewhere, and the ways our staff can still reach them, are spelled out below.
Where your data lives — and what actually crosses the line.
Your shoppers’ conversations are stored inside your instance, and only anonymous counts cross to central reporting. That boundary is the core of the design; the answers further down cover the copies we keep beyond it.
Inside your instance
Your shopper opens the assistant on your site over TLS. The conversation, your catalog, and any leads live on your own server — a separate database and disk, not a shared table.
What crosses to central reporting
Only aggregate counts — sessions, cost and health — for reliability and billing. The ingestion endpoint rejects any payload that contains message content, so even by mistake a transcript can’t reach reporting.
What stays in your console
Your transcripts are stored on your own server. On Pro and above you read them in your console, masked by default, with every reveal audit-logged. They are never sent to central reporting; the copies we keep elsewhere, and the ways our staff could still reach them, are named in the answers below.
Questions we’d rather answer before you ask.
What do you collect from my shoppers?
Only what a lead chooses to share — typically name, email or phone — and only at an explicit lead step, after they acknowledge it. We don’t build hidden profiles of your visitors.
Do you sell or share my data?
Never. No third-party sharing, no ad networks, no data brokers, and no using your shoppers’ data to train models for anyone else.
Can HOLLOU staff read my conversations?
Not through our reporting: central reporting only ever receives aggregate counts, and it rejects any payload carrying message content. But staff can reach them in the ways below, and we’d rather list them than let “your own server” imply a door we don’t have a key to. Your transcripts are stored on your store’s own server, which we run for you on AWS. Its database holds them as written; the transcript view in your console, on Pro and above, masks personal details by default, and every reveal there is audit-logged. Our engineers can reach that server and its database directly, because they run it — that access is what keeps your agent up, and today it is not audit-logged. We keep copies off the server in two cases: nightly database backups, where off-server backup is switched on for your store, are kept in our own storage in your store’s region; and if your store is deleted, we archive a full export of its leads and conversations in our own storage, and keep a snapshot of its disk, before the server is destroyed. And today we issue your first console login ourselves: a platform administrator retrieves it once to hand it to you. That retrieval is audit-logged and removes our copy, but until self-serve password setup is switched on, the person who handed it over could use it to sign in to your console.
Is it encrypted?
In transit, yes — HTTPS/TLS on every connection, under a certificate issued for your own instance, and served pages carry standard security headers, including a content-security policy that limits where scripts, connections and forms can load from or go to. That policy still allows inline scripts today; tightening it is on the list. At rest, not yet: the instance disk isn’t encrypted today. It’s a small change and it’s on the list. We’d rather you heard that from us than found it in a security review.
Is it “unhackable”?
No credible company claims that, and we won’t either. What we run is defense-in-depth: per-merchant isolation, least-privilege access, encryption in transit, input validation, security headers, and regular internal review. We’d rather tell you exactly what we do than make a promise no one can keep.
What if my install snippet leaks?
A copied snippet is rejected on any other website — the browser sends its origin and we check it against your domain. A caller scripting our API directly, with no browser origin, isn’t stopped by that check today; it is on the same list as disk encryption. You can rotate or revoke the key at any time.
Can I get my data out, or delete it?
Yes — a full export is available on request, and so is erasure of your store's live database. Erasure does not yet reach the copies described above: nightly backups, where switched on, expire after 30 days, and the export archive and disk snapshot kept when a store is deleted have no set expiry today. You can rotate your key whenever you like. Your data is yours.
The concrete measures protecting your data today.
Encryption in transit, per-instance certificate
Encryption at rest on the instance disk
Not switched on today. Listed here because a control we don't have belongs on the same page as the ones we do.
Audit logging of operator server access
Our engineers can reach your instance to run it. Today that access is not audit-logged.
Console password you set yourself
Today we issue your first console login and a platform administrator hands it to you. A set-your-own-password email link replaces that once our outbound email is switched on.
Content-security policy with no inline scripts
The policy we serve today still allows inline scripts, so it is not as strict as it should be.
Per-merchant isolation
PII masking with reveal audit
Domain-locked keys & least-privilege access
Aggregates-only telemetry & provisioning audit log
AWS · NVIDIA · Anthropic Claude · Azure OpenAI
Enterprise infrastructure and models you already trust.
Bring your hardest question. We’d rather earn trust than claim it.
A straight answer from a real person beats a glossy claim. And if you’d like to verify any of the above yourself, we’ll show you how.