For as long as the internet has asked us to prove things about ourselves, it has asked us to do it the same way: hand over the evidence and hope. To show you are old enough, you upload your passport. To show you live where you say you do, you send a utility bill. To sign in, you let a platform that already knows too much vouch for you to everyone else. Each of these is a small surrender, and we have made so many of them that the surrender now feels like the natural order of things. It is not. It is a design choice, and it was the wrong one.
We built Privasys to make the other choice possible. Today we are releasing the first piece of it that an ordinary person can hold in their hand: Privasys ID, a way to prove who you are, that you are a real human, that you hold a valid government document, or that you are over a certain age, without giving any of it away. Your identity lives on your phone. It stays there. When a website needs an answer, it gets exactly the answer it asked for and nothing more, backed by cryptography and hardware it can verify for itself.
This is a long post, because this is the thing we care about most, and we want to explain not just what we shipped but why it matters, what is wrong with the alternatives, and what it makes possible.
The bargain we should never have accepted
The uncomfortable truth about most identity systems is that they work by accumulation. To be useful, the verifier keeps a copy. The age-check vendor keeps your passport scan. The data broker keeps your address. The identity provider keeps a log of every site you visit, because being in the middle of every login is precisely how it makes money. Every one of these copies is a liability that grows quietly until the day it leaks, and they all leak eventually.
We have normalised this because the alternative seemed impossible. How can a website trust that you are over eighteen unless someone it trusts has seen your date of birth? How can it trust that your document is genuine unless someone has inspected it? For decades the only answer was a trusted third party that sees everything, and so we accepted a world of trusted third parties that see everything.
The premise was always false. You do not need to reveal a fact to prove a fact. You need a way to make a claim that a relying party can check without taking the claim, or you, on faith. That is a cryptography problem and a hardware problem, and both of those have quietly been solved well enough to change the bargain. We have spent the last years assembling the pieces. Privasys ID is where they come together for people, not just for engineers.
But before we describe what we built, it is worth looking honestly at what the two obvious alternatives actually cost. One is the model almost every platform uses today. The other is the model that well-meaning privacy projects keep reaching for and that keeps failing. Understanding why both fall short is the clearest way to see why the enclave approach is not a detail of our architecture but the whole point.
What "verified" costs you today
Consider the small blue verification badge on a professional network. It looks like a courtesy, a tick that says a human checked you are real. Getting it takes about three minutes. You scan your passport, take a selfie, and a moment later the badge appears. Nothing about the experience suggests you have just made a consequential decision about your most sensitive data.
The reality is different, and you do not need a leak or a whistleblower to see it. Everything that follows comes from the companies' own published documents. Start with who does the checking, because it is not the platform you trust. LinkedIn's help pages explain that verification is performed by Persona, a San Francisco company most people have never heard of, operating invisibly in the middle of the flow. LinkedIn itself receives little more than your verified name, the document type and issuer, and a hashed identifier. Persona receives everything else, and Persona's own privacy policy spells out what everything else can mean, depending on the checks a client requests: the images of your government document and the data on its NFC chip; a real-time selfie and a scan of your facial geometry as biometric data; government identifiers up to and including national identity and social security numbers; your contact details, device identifiers and location inferred from your IP address; account information your mobile carrier is authorised to disclose about you; and usage signals as fine-grained as whether you paste text instead of typing it. The same policy explains that you may then be cross-referenced against a "network of trusted third-party data sources": government and national ID registries, consumer credit bureaus, utility companies, mobile network providers and postal address databases. The three minutes you experience are a scan and a selfie. The machinery underneath is closer to a background check.
Then follow the data. Persona publishes its subprocessor list, the companies that may process your personal data on its behalf. At the time of writing it names seventeen: sixteen in the United States, one in Canada, none in the European Union. Three of the seventeen are AI companies, Anthropic, OpenAI and Groq, engaged for "data extraction and analysis"; another is a device-fingerprinting specialist. The privacy policy notes that data centres are located in the United States and Germany, but Persona is a Californian company, and under the CLOUD Act United States law reaches data held by American companies wherever the server sits, so a Frankfurt rack is a mailing address, not a jurisdiction. Retention is framed as delete-by-default, yet clients can direct otherwise, facial scan data may persist for up to three years after your last interaction, and everything carries the standing exception of legal process. And if any of this ever goes wrong, Persona's terms of service cap its total liability to you, for your passport, your face and the geometry of your features, at fifty US dollars.
We should be fair here, because fairness sharpens the point. Persona's current policy states plainly that it does not use personal data, including biometric data, for AI or model training. It did not always say that. The version in force in mid-2025 told users that "we use uploaded images of identity documents to train the Service", resting not on consent but on the company's legitimate interests. The change is real, and welcome. But notice what kind of thing changed: a paragraph. Nobody outside the company observed a data flow start or stop. When privacy is a promise rather than a property of the system, a rewritten paragraph is the only evidence you will ever get, and nothing prevents the next revision from moving the other way.
And where nothing can be checked, suspicion fills the space. Earlier this year, security researchers published a two-part investigation into Persona (part one, part two) after finding publicly exposed source code for its government-facing platform. What they described was unsettling: a dedicated watchlist-screening deployment for a large AI company, live long before that company announced identity verification at all; code for matching selfies against public figures; machinery for filing suspicious-activity reports to financial intelligence agencies. Persona's chief executive engaged in writing, to his credit, and disputed the darkest readings: that deployment, he said, screens only names, birthdates and countries, touches no biometrics and stores nothing. He may be entirely truthful. The researchers could only note that his answers were consistent with what they had seen and impossible to verify from the outside, and that most of their questions remained open. That is the finding that matters more than any single allegation. When a system's behaviour cannot be inspected, its operator's reassurances are worth exactly your willingness to believe them, and every gap in the story is filled by the worst scenario anyone can imagine. The company may be honest. The architecture makes honesty unverifiable.
We are not singling out one company. Persona is, if anything, more forthcoming with its documentation than most of its industry, and this is simply what "get verified" means almost everywhere today, made visible. Nor is the pattern receding. Anthropic has announced that Claude users will verify their identity through Persona as well, accompanied by the now-familiar reassurances that the ID and selfie are held by Persona rather than Anthropic and that identity data is not used to train models. We have no reason to doubt those words, and every reason to point out that they are words, of exactly the kind that was quietly rewritten above. The circle is worth a moment's pause: Persona will verify Anthropic's users, and Anthropic sits on Persona's subprocessor list for data extraction and analysis. Wherever you look the shape is the same: a cosmetic outcome, a three-minute flow, and underneath it a permanent transfer of your most identifying information to parties you did not choose, on terms you did not negotiate, revisable at any time and verifiable never. The badge is the part you see. The trade is the part you do not.
This is the bargain we should never have accepted, and the reason it persists is that the architecture leaves no other option. If the only way to be trusted is to let someone see everything, then someone will always end up holding everything.
The on-device mirage
Faced with that, the natural reaction of a privacy-minded engineer is to swing to the opposite extreme: do everything on the phone. Read the passport chip on the device, match the face on the device, run the liveness check on the device, and then tell the website only the answer. The data never leaves. Problem solved.
It is a beautiful idea, and it does not work. Not because the cryptography is wrong, but because of where the computation happens and who controls that place.
A security analysis of the EU's age-verification approach, by the team behind the Yivi wallet, lays out the flaw with unusual clarity. The EU design performs all of its checks, passport scanning, face matching, liveness detection, on the user's own device, and then sends only the result onward to be trusted. As the analysis puts it, "the verification happens in an environment the user controls (their phone), but the result is trusted by a system that the user shouldn't be able to manipulate." Those two requirements cannot both hold. The issuer, it concludes, has no way to confirm independently that the passport verification ever happened.
The analysis does not stop at theory. It walks through three practical ways to defeat such a system: modify the app by decompiling it, stripping out the verification logic, and recompiling; hook the running app at runtime to bypass the checks; or ignore the app entirely and craft the network requests by hand. In every case the system downstream simply accepts the birth date it is handed and issues the credential, because it has no independent way to know better. Anyone determined to lie about their age, which is precisely the population an age check exists to stop, is the population most motivated to do exactly this.
The tempting fix is platform attestation: have Apple or Google vouch that the app is genuine. The analysis dismantles this too. Play Integrity and App Attest can tell you "the app is authentic." They cannot tell you "the app did its job." They cannot confirm that a passport was actually scanned, that a face was actually matched, that liveness actually passed, or that the birth date is genuine rather than typed in by a modified client behind an otherwise legitimate binary. The phone can prove it is running real software. It cannot prove that the real software was allowed to do real work, because the person holding the phone is the very person with the motive to interfere.
There is a second, quieter reason the all-on-device dream fails, and it is one we run into constantly in practice. Verifying an identity document properly is not a small computation. It means validating a chain of cryptographic signatures against a master list of several hundred country signing certificates, kept current as countries rotate keys. It means reading the machine-readable zone reliably across the lighting, glare and angles of a real phone photo, which in our experience needs a heavyweight optical-character-recognition stack and trained models, not a few hundred lines of on-device code. It means running face-detection and face-recognition neural networks to match the live capture against the chip portrait, and a liveness model to resist a photograph held up to the camera. These are large libraries and sizeable models. Shipping all of them to every phone, keeping them updated, and then trusting each phone's self-reported verdict would be both a maintenance burden and, per the analysis above, a security non-answer.
So the two honest options on the table are bad in opposite directions. The platform model is trustworthy to the relying party and catastrophic for your privacy, because someone keeps everything. The on-device model is good for your privacy and untrustworthy to the relying party, because no one can confirm the work was done. For years these were presented as the only choices. They are not.
The third way: verifiable code in hardware that keeps nothing
Privasys is built on a different primitive, and it resolves the dilemma directly. The verification runs in a confidential enclave: a piece of code running inside hardware that proves, cryptographically, exactly which code is running, and inside which no operator, not even us, can look. Before your wallet sends a single byte, it checks that attestation and pins the exact published build of the verifier. Rather than being asked to trust the verifier, you are shown, in cryptography, precisely what it is and what it will do.
Read what that gives you against the two failures above. Unlike the on-device model, the relying party gets a real guarantee, because the work was done by named, published, attested code, and the result is signed by that code. The objection that "platform attestation proves the app is authentic but not that it did its job" disappears, because here the job itself is the attested artefact. Instead of vouching that a binary on a phone behaved, we run the verification inside hardware that proves which verification ran. And unlike the platform model, the enclave keeps nothing. It receives your document data for a single encrypted moment, does its work, returns a signed receipt to your device, and forgets you existed. There is no copy, no subprocessor chain, no training corpus, no fifty-dollar liability cap, because there is nothing retained to leak.
This is also the natural home for the heavy machinery that the on-device approach cannot carry. The several-hundred-certificate master list, the optical-character-recognition models, the face-matching and liveness networks: they live in the enclave, run once per verification, attested and current, and never touch your phone's storage or its trust. You get the accuracy of a serious verification stack and the assurance of attested code, without the device becoming a place that has to be believed.
One subtlety is worth making explicit, because it is where the design earns its keep. Your phone still reads the passport chip over NFC, the same way a border gate does. Could a tampered app simply fabricate that chip data on the way to the enclave? No, and this is the crucial point the Yivi analysis itself reaches for in its recommended fix. The chip is signed by the issuing country. The enclave performs Passive Authentication on those signatures: it checks the document signer certificate, chains it to a trusted country signing certificate, and verifies every data-group hash. A forged or altered chip does not carry a valid national signature, so it does not pass, no matter how the app behaves. The trust does not rest on the device doing the right thing. It rests on a national cryptographic signature checked by attested code. The device is free to be untrusted, because nothing important depends on trusting it.
How it actually works
With the principle in place, the experience is simple. You open the wallet and choose to verify an identity document. You photograph the data page; the image is cropped to the document on the device, so your surroundings never leave your phone, and sent to the enclave, which reads the machine-readable zone accurately and hands back the key needed to unlock the chip. You hold your passport to the phone and it reads the chip over NFC. You take a quick selfie.
Inside the enclave, the Identity Verifier does the work a trusted authority would do. It runs Passive Authentication so it knows the document is genuine and unaltered. It matches your live photo against the portrait on the chip so it knows the document is yours, and runs a liveness model to resist a photograph held up to the camera. It cross-references what it read on the page against the chip to catch tampering. Then it returns a signed Identity Verification Receipt: a set of cryptographic commitments to your verified attributes, bound to a key that only your phone holds, with the raw data handed back to your wallet and nothing kept behind. Every step is performed by the published build your wallet pinned before it trusted anything.
A word on standards, because we would rather be precise than impressive. We designed these checks to line up with what the United Kingdom's Digital Identity and Attributes Trust Framework expects of an identity check at a medium level of confidence, and that framework is the right bar to aim at. But designed against is not certified against. Privasys ID has not yet been through that certification, and our liveness detection has not yet had the independent presentation-attack testing that ISO/IEC 30107-3 describes. That testing and certification work is our next step over the coming months, and we will publish the results as they come. In the meantime we can offer something certification alone does not: cryptographic proof of exactly which code performed your check. A certificate tells you a process was audited once. An attestation tells you what ran, this time, on your data. We intend to have both, and to be plain at every stage about which we hold.
Your wallet, your data
The result lands in the Privasys wallet as a set of attributes you own, and our latest release adds a clean flow for importing and validating them. After a verification you are shown precisely what was read, your name, your date of birth, your nationality, your document details, even the official photo from the chip, and you choose what to keep. Nothing is added behind your back. If your everyday name differs from the legal name on your passport, we ask rather than overwrite. You can also import softer attributes from accounts you already have (Google, LinkedIn), and the wallet records the assurance of each one, so a government-verified fact and a self-entered one are never confused.
What you end up with is something most people have never had: a personal, portable, verifiable record of who you are, held on your device, sourced from authorities you already trust, and disclosed only with your consent. It is the difference between carrying your identity and renting it from a platform that quietly keeps a copy.
Proofs, not copies
Holding your identity privately would be a half-measure if proving things still meant surrendering it. So the wallet does not hand over your attributes. It produces proofs.
Through a software development kit that any website can embed, a relying party can ask a Privasys user for exactly the claim it needs. Not "send me your passport", but "prove you are over eighteen". The wallet answers with a short-lived, audience-bound, cryptographically signed token that says yes or no, derived from the government-verified date of birth that never leaves your phone. The site learns that you are old enough. It does not learn your birthday, your name, or your document number. It cannot use the answer to track you across other sites, because each proof is scoped to that site alone.
The same mechanism proves a single field when one is genuinely needed, proves an age band rather than an exact age, or simply proves that a real, valid, government-issued document was verified without disclosing anything about it at all. Raw attributes when the law truly requires them, derived proofs when it does not, and the default leaning always towards revealing less. A relying party verifies a proof the same way your wallet verified the enclave: by checking the signature against the attested, published code, with no need to phone home to us and nothing for us to sit in the middle of.
Consider what this does for one problem everyone agrees on and no one has solved well: keeping children away from content that is not for them. Today, online age verification is a choice between two bad options. Either it is trivial to bypass, a checkbox that protects no one and which, as the security analysis above shows, falls to a modified app in an afternoon. Or it is invasive, demanding that adults upload identity documents to a patchwork of sites and vendors that then hold them, recreating the very harvesting we began with. A cryptographic proof of "over eighteen" or "over sixteen", backed by a genuine document and a check that demonstrably happened, but revealing none of the underlying data, breaks that false choice. Children are better protected because the proof is sound and hard to forge. Adults keep their privacy because nothing is handed over or retained. Both at once. That is what a good design looks like, and it is only possible because the proof and the data have finally been separated, and because the check runs somewhere that can be trusted without being given everything.
This is a platform, and identity is the beginning
It would be easy to read all of this as a clever identity app. It is something more: the first citizen of a platform.
The pattern underneath Privasys ID generalises. A person, or a company, holds their own data. When a computation needs that data, the data is not copied out to whoever wants it. Instead the computation comes to a confidential enclave, the owner consents to that specific use, and the enclave runs published, attested code that proves what it did and keeps nothing it should not. Identity is simply the first valuable thing we have taught the platform to handle this way. The same machinery applies to financial records, to health data, to documents, and to the messy private information that every business holds about its customers and is, quite rightly, terrified of losing.
And because these enclaves can run real workloads, including AI inference over confidential data, the range of what becomes possible is genuinely open ended. A model can reason over your records to give you an answer without anyone, including the model's operator, seeing those records. A company can let a third party process its most sensitive data and get back a result together with a proof of how it was produced, rather than a breach waiting to happen. We have written before about making that inference itself reproducible and accountable, about bringing attestation all the way into the browser so a web app can check the enclave it talks to, and about upgrading an enclave without handing it your data. Privasys ID is what those foundations were for. The unit of trust stops being "an organisation we hope is careful" and becomes "code we can verify, running where no one can peek." Owning your data and still being able to use it have always been in tension. This is how that tension dissolves.
Why we are doing this
Steve Jobs once said that marketing is really about values, that the noise of features and specifications matters far less than what a company believes and stands for. We have spent most of our public writing on the engineering, on measurements and attestation and the careful mechanics of trust, and that work matters. But the engineering is in service of something: we believe your data is yours. Not yours to be harvested in exchange for a badge, not yours until a breach makes it everyone's, but yours in the full sense: held by you, used only with your consent, and provable without being surrendered.
We believe privacy is not a luxury for the technically sophisticated but a default that ordinary people deserve and almost never get. These are European values, written into law in the General Data Protection Regulation and too often honoured only on paper, while the actual flows of data run through subprocessor chains that end up, as the documents above show, outside your country and outside meaningful consent. We would rather honour those values in working software than in a privacy policy nobody reads.
We also believe the ground is not level. The ability to do trustworthy computation on sensitive data has, until now, belonged to the largest companies, the ones who could build the infrastructure, employ the verification vendors, and absorb the risk. That concentration is bad for competition and worse for people, because it means the same handful of giants sit at the centre of every interaction, accumulating the data that makes them harder to challenge. Confidential computing, made open and made simple, changes who gets to play. A small team with a good idea can now offer a privacy-preserving service that a person can actually trust, and prove it, without first becoming a giant themselves and without renting a verification pipeline that quietly trains someone else's models on its users. We want to put that capability in everyone's hands and let new players compete on merit rather than on how much of your data they have managed to amass.
That is the world Privasys is built for. One where you prove you are human without becoming a product. One where a child is protected without an adult being surveilled. One where a company can use the best tool for the job without handing over the crown jewels. One where the verification that protects everyone is itself something you can inspect, rather than a black box run by a vendor you were never introduced to. One where trust is something you can check, not something you are asked to assume.
Privasys ID is the first time we can hand a piece of that world to an ordinary person and say: this is yours now. Try it. Prove something. Notice that you gave nothing away, that no third party kept a copy, that the check that vouched for you is one you could read for yourself. Then imagine everything else that becomes possible once that is the default, rather than the exception we had to build from scratch.
We are only at the beginning.