Recording a checkout is a bigger promise than storing a chat log.
So this page says exactly what leaves the browser, what never does, where it lands and when it disappears. Including the certifications we do not have.
Recording
- Inputs masked at source
- Field values are replaced before the event leaves the browser. There is no configuration where raw keystrokes are uploaded.
- Payment frames unreachable
- Card entry lives in a cross-origin iframe belonging to your processor. Nothing in the recorder can read it.
- Opt-out attribute
- Mark any element and its subtree is skipped at capture time, not filtered afterwards.
- Consent aware
- Recording can be gated on your existing consent state, so one banner governs both.
Storage and retention
- Encrypted in transit and at rest
- TLS on every connection, server-side encryption on the object store.
- Retention you set
- Recordings age out on a policy per site and are deleted from the bucket, not just hidden.
- Deletion means deletion
- Removing a visitor removes their transcripts, recordings and analytics rows together.
- Export on any plan
- Conversations and contacts as JSON, recordings as raw rrweb events. Leaving is not a support ticket.
Access
- Roles enforced server side
- Owner, admin and agent permissions are checked on the API, not hidden in the interface.
- Per-site scoping
- An agent invited to one site cannot read another, including through search.
- SSO on self-hosted
- SAML or OIDC against your directory, with an append-only audit trail of operator actions.
- Keys stay server side
- Business API endpoints and tokens are never exposed to the model or to the browser.
Masking is not a setting you can get wrong.
Every input is masked by default. There is no switch that turns it off, because the only reason to want that switch is a reason we would rather not enable.
If a whole region of the page should never be recorded at all, mark it and the recorder skips the subtree before serialising anything.
<!-- excluded from capture entirely -->
<div data-hepo-mask>
<input name="tax_id" />
</div>What we have not done yet
Every vendor page lists what it has. This is the other half, so nothing surprises you during review.
No SOC 2 or ISO 27001
Neither is in progress. If your buyer requires one, the honest answer is that self-hosting is the path, or that we are the wrong vendor this year.
No single region choice on hosted plans
Hosted data lives in the EU. Region selection exists for self-hosted deployments only, where the region is wherever you put the machine.
No bug bounty programme
We answer researchers quickly and credit them, but there is no cash pool yet. Saying otherwise would waste your time and theirs.
What review boards ask
Are you SOC 2 certified?
Not today, and we will not imply otherwise. We are a small team selling to small merchants, and an audit that costs more than our first year of revenue would be theatre. If your procurement requires it, self-hosting removes the question instead of answering it.
Where is hosted data stored?
European Union by default, on encrypted object storage with a zero-egress provider. Ask before you sign if you need a different region and we will tell you honestly whether we can do it.
Do you train models on our conversations?
No. Conversation content is not used to train anything, ours or anyone else. Translation runs on a model we host, so message bodies are not sent to a third-party API on hosted plans either.
What is your sub-processor list?
Object storage and, for hosted plans, the model provider serving your chosen agent model. Both are named in the DPA. Self-hosted installs have no sub-processors at all.
How do I report a vulnerability?
Mail support@hepo.ai with the details. We answer within two working days, we do not threaten researchers, and we say so publicly unless you would rather we did not.
Send us the questionnaire.
If your buyer has a security review form, mail it over. We fill them in ourselves and we do not leave boxes optimistically ticked.
Vulnerability reports go to the same address and get answered first.