Here is a question worth asking every vendor who stores something important for you: what happens to my data on the day you get breached? Most answers are a tour of certifications. Ours is shorter: an attacker who fully compromised Wytness would find pseudonymised tokens they cannot reverse and signatures they cannot forge — because the keys that matter were never ours to lose.
Two keys, both born in your browser
When you set up Wytness, you generate two keypairs. Both are created in your browser, on your machine. The private halves go into your own secrets manager and are never transmitted to us; only the public halves are registered with your account. There is no "upload your key" step anywhere in the product, and that's not an oversight — it's the design working. A key we never receive is a key we cannot leak, mishandle, or be compelled to misuse.
- The signing key puts your signature on every event your agents emit. It is what makes the record evidence rather than a claim: anyone with the public key can verify that this exact action was attested by your environment, and nobody — including us — can fabricate an event in your name.
- The sealing key protects personal data. The fields you tell the SDK to seal are replaced with tokens before the event ever leaves your environment. What crosses the wire, and what we store, is the token — not the name, not the email, not the account number.
Who holds what — the whole picture
It's worth seeing the full division of custody, because it's unusual. Your environment holds the signing private key and the sealing private key. The AGT runtime inside your agents holds the identity keys that say who ran this. Wytness holds the public halves — enough to verify, never enough to forge or reveal. Four cryptographic layers, and on every one of them, the private material sits on your side of the fence. When our Security page says "keys we never hold," that's a complete inventory, not a slogan.
What we can and cannot see
The honest way to describe any data platform is two lists. What Wytness can see: pseudonymised events with personal fields replaced by your tokens; event metadata — timestamps, agent identifiers, tool names, outcomes; the public keys you registered; and the anomaly results computed from all of that. What Wytness cannot see: raw personal data, because sealing happens in your environment before anything is sent; your private keys, because they never leave your side; and the meaning behind any token, because re-identification requires your key and runs on your copy. In Bring Your Own Storage mode the raw events themselves sit in your storage — we hold a metadata index only.
Notice what this design removes: the need to trust our intentions. The interesting property is not that we promise not to look. It is that looking would not show us anything.
The part most vendors keep quiet
A model like this has a cost, and you should hear it from us. Sealing applies to the fields you declare to the SDK — it is deliberate, not magical. If personal data is buried in free text you never told the SDK about, it arrives as-is, so declaring your fields is part of the setup, not an optional extra. And if you lose your sealing key, we cannot recover what it protected — not as a punishment, but as the proof that the boundary is real. A vendor who can rescue you from a lost key is a vendor who could read your data all along.
Treat the private halves the way you treat your production database credentials: a real secrets manager, an owner, a rotation habit. The dashboard's Keys page is built for that discipline — multiple keys can be active during a rotation, and every key action lands in its own audit history. The operational details are a post of their own; the principle belongs here: custody you hold is custody you have to manage, and the product is designed to make that manageable rather than heroic.
Why this matters beyond security
The key model started as a security decision, but its real value shows up in ordinary business conversations. Your compliance team can answer "where does customer PII go?" with "it doesn't leave us." Your auditor can verify the record without asking us to vouch for it — the check runs against your public key, not our say-so. And when an agent's action is disputed months later, the signature settles who attested to what — no reconstruction from memory, no vendor in the middle of the argument.
There's a procurement version of this too. The hardest questions on any vendor security review — "who at the vendor can access our data?", "what happens if the vendor is breached?", "can the vendor be compelled to hand over our content?" — usually take a meeting and a lawyer. With customer-held keys, the answers are one sentence each: nobody can read it, a breach yields tokens, and there is nothing readable to hand over. Questions that dissolve are cheaper than questions you answer well.
The full security architecture — threat model, encryption layers, who holds which key — is laid out on the Security page. Questions about the key model? Ask us.