The boldest claim Wytness makes is that personal data in your events never reaches us. Not "encrypted on our servers" — it never arrives. This post explains how that works, in plain language, including the two clever tricks that make an audit trail useful even when the platform running it is blind.
Sealed before it leaves home
When your agent records an event, the SDK transforms the fields you've declared as personal — the customer email, the account number — inside your own process, before anything is sent. What crosses the wire is the transformed version. There is no configuration on our side that could turn this off, because the sealing happens where we aren't.
Follow one field through the journey and the model becomes concrete. Your agent records a refund for alice@example.com. Inside your process, the SDK replaces the address with a token before the event leaves. The event that travels, and the event we store, carries the token. On the Events page, your team sees the token with a short hint. And on the day someone authorised actually needs the address — a dispute, a subject-access request — the reveal runs in their browser, against your key, locally. At no point in that journey did the address exist anywhere we could see it.
Trick one: tokens that stay consistent
Simply deleting the email would gut the trail — an audit constantly asks "was this the same customer across these five sessions?" So instead of deleting, the SDK computes a pseudonym: the same input always produces the same token, but the computation is keyed with a secret only you hold (HMAC-SHA256, for the technically minded). The result keeps the analytical shape of the data — same customer, same token, correlations intact — while removing the identity.
That determinism is what keeps the blind platform useful. Search still works: compute the token for the value you're looking for — on your side, with your key — and match it across the whole trail. Anomaly rules still work: "same actor, unusual hour" doesn't need to know who the actor is. And because the keyed computation needs your secret, nobody can play guessing games against the tokens: without the key, checking "is this token alice@example.com?" is computationally off the table.
Trick two: a sealed envelope only you can open
Sometimes someone on your side legitimately needs the real value — a dispute, a subject-access request. For that, the SDK also packs the original into an encrypted token map, sealed to your public key (X25519 with ChaCha20-Poly1305). We store that sealed blob next to the event without being able to open it. When an authorised person on your team clicks reveal, the decryption runs in their browser, against your private key, locally. The plaintext exists on their screen and nowhere else — our servers never see it, at rest or in transit.
What actually sits in our database
For a sealed field: the token, the sealed map, and a short hint for the UI. That's the complete list. Server-side decryption isn't forbidden by policy — it's impossible by construction, because the material needed to decrypt was never sent. This is the difference between a privacy promise and a privacy architecture.
It also rewrites your breach maths. If Wytness were fully compromised, the attacker's haul from your sealed fields would be keyed tokens they cannot reverse and encrypted blobs they cannot open. Your incident-response conversation changes shape accordingly — and so does the vendor-risk assessment your customers run on you, because "our audit vendor never holds readable PII" is a sentence their security team can verify rather than take on faith.
The boundary, honestly drawn
Sealing applies to the fields you declare. It is deterministic engineering, not magic: personal data buried in free text the SDK wasn't told about arrives as-is. Declaring your PII fields is part of a serious setup — our PII protection docs walk through exactly how, and the right habit is to treat the declaration list as part of your schema: when a tool gains a field that carries personal data, the declaration ships in the same change. We'd rather you know the boundary than believe a vaguer, nicer-sounding claim.
Why this design and not just encryption?
"Encrypt everything, hold the keys yourself" sounds simpler, but a fully encrypted trail is an unusable one — no search, no correlation, no anomaly detection, no evidence packs. The pseudonym layer is what lets the recorder do its whole job — queries, baselines, auditor sampling — on data that identifies no one. Blind, but still useful: that's the actual engineering problem, and this is the shape that solves it.
The keys behind all of this live on the Keys page. Questions about declaring fields in your schema? Ask us.