Revolut confirmed this week that it sent customer passport scans and transaction records to attackers who impersonated a government agency with a forged legal request (Reuters, Sept 12). No server was hacked. No password was cracked. A human on the compliance side looked at a request that read like it came from law enforcement, and handed over the file.
This is the failure mode that's easy to miss when we talk about "data breaches." We spend enormous engineering effort on encryption at rest, encryption in transit, access logging, and SOC 2 audits, and then the actual leak happens because someone approved a request that looked legitimate enough. The data was sitting there, complete and exportable, waiting for exactly the right piece of social engineering.
The root problem isn't the process failure. It's that the data existed to be exported at all.
Most identity verification today follows the same shape: a site asks for a passport or ID scan, stores it (or a vendor stores it on the site's behalf), and keeps it indefinitely "in case we need it again" (for compliance, for support disputes, for re-verification). Every one of those stores is a future Revolut. The attacker doesn't need a zero-day; they need one convincing forged letter and one tired employee on a Friday.
We built ClientN around a different assumption: verification and storage don't have to be the same step.
When someone verifies as a real, unique human on ClientN, the ID/passport check and the face match happen once, and the raw documents aren't retained afterward: what persists is a cryptographic attestation, not the image. Each site the person then connects to gets a different anonymous ID (a CN- handle), scoped to that site, with no shared identifier a second party could correlate across services or exfiltrate in one shot. There's no central vault of passport scans sitting behind a support ticket queue for someone to social-engineer their way into, because the vault doesn't exist after the initial check is done.
This is a trade-off, not a magic fix. A site that genuinely needs an auditable copy of your ID for its own regulatory reasons (say, a bank) still needs to hold that copy. ClientN doesn't solve that problem, and it's not trying to be a KYC vendor for regulated finance. What it solves is the far more common case: sites that ask for identity verification purely to prove "this is one real human, not a bot or a Sybil farm," and then hold onto sensitive documents they never technically needed to keep. Passkey login for session security, a one-time Sybil-resistance check, an anonymous per-site ID, and nothing left over that a forged government letter could unlock.
If you're building anything that needs "prove you're a real, unique person" without needing "collect and retain their government ID forever," the demo is at clientn.com/demo and integration docs are at clientn.com/dev. Verified Human accounts start at $1/year during the launch window: clientn.com/signup.
Verified Human. Still Anonymous.
Top comments (0)