Security
Recording people is a responsibility.
A session replay tool is, by construction, pointed at your users. The only version of that worth shipping is one where the safe configuration is the default and the dangerous ones are things you must deliberately choose.
Consent gating is total
With the gate on and consent withheld, the SDK records nothing, stores nothing on the device and sends nothing about the visit — not a reduced payload, not a heartbeat. Its one request is an anonymous fetch of your masking config, carrying your public site key and nothing else. The gate is on by default for visitors who look European by timezone; one flag turns it on for everyone.
SDK reference → ConsentGPC and DNT always win
Global Privacy Control and Do Not Track force recording off no matter how you have configured the SDK. There is no option to override them, because a privacy signal you can override is not a privacy signal.
Privacy & data → ConsentDeletion is real
Deleting sessions removes the rows and sweeps the object-storage prefix. Replay blobs are namespaced by tenant, so a subject-access deletion is a prefix operation rather than a hunt.
Privacy & data → Deleting dataRedacted before it ever leaves the page.
Everything in this section is a default, not a capability. The distinction matters: “can be masked” describes a checkbox somebody has to find, and “masked unless you opt out” describes what actually happens on the day you ship.
Inputs are masked before the batch exists
Masking happens at capture time, in the page. The values never enter the payload, so they are not in transit, not in our storage, and not something you have to trust us to have deleted. Password fields stay masked even if you disable masking everywhere else.
Privacy & data → Input maskingRequest and response bodies are off
Body capture is opt-in, per site. When you do turn it on, bodies run through a PII-masking pipeline — email addresses, card-length digit runs, US Social Security numbers, any run of nine digits or more — and are size-capped. It is pattern matching, not a checksum: it over-redacts rather than under-redacts.
SDK reference → Capture optionsSensitive headers are redacted by default
Authorization, Cookie and Set-Cookie are stripped out of the box, and every captured URL has its query string replaced — magic-link and reset tokens never leave the page. The header list is yours to extend; shrinking it is a deliberate change in your own init code.
SDK reference → Capture optionsYour own key list, masked on the device
Name the JSON keys you consider sensitive and the tracker masks them in bodies, WebSocket frames, console arguments and custom event properties before sending — on top of a built-in list (password, token, cookie, cvv and their relatives) that applies with no configuration at all. Your list is fetched at init and applied again at send time, so anything captured in that window cannot leak.
A last-chance hook
A beforeSend callback runs on every batch, so you can drop or rewrite anything on the way out with your own code.
Isolated, scoped, least-privilege.
Tenant isolation, blobs included
Every site belongs to exactly one tenant, and the API derives the tenant from your credential rather than from anything the request asks for. Replay data is read back through that same check, out of a private bucket — no signed URLs, no public objects.
Two key types, and only one of them is dangerous
Publishable pk_ ingest keys are site-scoped, rate-limited and cannot read a thing. A secret sk_ key is admin-equivalent across your workspace — treat it as one. Both are stored only as a SHA-256 hash, so we cannot show you a key again; we do not have it.
Settings → Install & keysRole-based access
Owner, admin, member and viewer, with per-site grants so a contractor can be given one site and nothing else. Not a paid add-on — it is on every plan, including the free one.
Team → Roles & per-site accessEncrypted in transit and at rest
TLS on every public endpoint and on the database connection. Objects are written with AES-256 at rest requested explicitly rather than left to a provider default, and monitor credentials get their own AES-256-GCM envelope.
Staff access is on the record
When someone here reaches your workspace for support, the database writes it to an append-only log at the one place every administrative route passes through. It is not a policy we follow; it is a row we cannot skip.
AI is off until you switch it on
No prompt built from your data reaches OpenAI or Anthropic until an admin enables AI analysis for the workspace — the check sits on the one function that can make the call. Even then the model gets figures from parameterised queries we wrote, never database access and never SQL.
What we do not claim.
A security page that only lists strengths is a sales page. These are the gaps you would find anyway — better here, while it is still cheap to know.
No SOC 2, no ISO 27001
There is no audit report to send you, and we will not imply one is in progress to buy time in a review.
No MFA, no SSO
Console sign-in is a password and a session token that expires in seven days. Both are on the roadmap; neither is here.
No EU processing region
We can tell you where your data sits and the DPA carries the transfer terms, but you cannot pin processing to Europe.
Outside the EEA, the default records
The consent gate turns itself on for visitors who look European by timezone. Everywhere else it is off until you set requireConsent — your lawful basis, your switch.
Workspaces that predate the AI switch were carried over with it on
AI analysis is opt-in now, but turning it off for existing customers overnight would have broken pages nobody asked us to change. Their setting says so, and switching it off is one click.
Masking is a good default, not a guarantee
The patterns catch what patterns catch. If a field must never be recorded, name it in your mask list or block the element — do not assume the heuristics found it.
Several of these are being worked on rather than ruled out. If one of them is the difference between using us and not, say so — that is the kind of thing that moves a roadmap.
Reporting a vulnerability.
We would rather hear it from you than from a customer. Good-faith research under this policy is welcome and will not be treated as a breach of our terms.
Where to send it
Email [email protected] with enough detail to reproduce it — affected URL or package, the steps, and what an attacker could reach. Our security.txt carries the same address in machine-readable form.
What we commit to
We acknowledge within 3 working days, tell you our assessment and expected fix timeline within 10, and let you know when it ships. If we disagree that it is a vulnerability we will explain why rather than going quiet.
What we ask
Give us reasonable time to fix it before publishing. Do not access, modify or delete data that is not yours, do not degrade the service for others, and stop as soon as you have demonstrated the issue. Use your own account and test data.
Scope
The service, the console, and everything we publish: the browser tracker, the React Native SDK, the host agent, and the embeddable player and widgets. Findings in our third-party providers should go to them; tell us too if it affects your data with us.
Actively exploited vulnerabilities
If you have evidence something is being exploited in the wild, say so in the subject line. That changes our clock: the EU Cyber Resilience Act's reporting duty has applied since 11 September 2026, and an actively exploited vulnerability in our SDKs or agent means an early warning to ENISA and the national CSIRT within 24 hours of us becoming aware.
No bounty, and we will say so honestly
We do not currently run a paid bug-bounty programme. We will credit you publicly if you want that, and we will not pretend a reward exists to get a report in.
Questions we have not
answered here?
Security review questions get a real answer from someone who has read the code, not a form letter.
answered by an engineer · not a form letter