A note on funding: CypherpunkGuide carries no surveillance advertising — no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate later. We answer to our readers, not to advertisers.
You can delete a social media account. You cannot delete yourself from the tax authority, the health service, or the national ID database. The data you hand to a government is not a choice you get to reconsider — it is the price of existing as a citizen. That asymmetry is the whole problem. When a company loses your data you can, at least in principle, leave. When the state loses it, you are still required to keep handing over more.
And in 2026, the state is losing it at scale. In a single span of weeks this spring, a contractor to CISA, the United States’ own cyber-defense agency, left administrative keys to government cloud systems sitting in a public code repository for six months; a federal health agency published doctors’ Social Security numbers in an online directory; and Britain’s National Health Service (the NHS) confirmed that a private analytics company’s staff could reach identifiable patient records. None of these were sophisticated nation-state attacks. They were ordinary institutional failures — the kind that recur because the incentives that produce them never change.
So if you cannot prevent the leak and cannot withhold the data, what can you actually do? This is not a guide to trusting better institutions. I wrote it as a playbook built on a clear threat model — a plain account of what you are protecting, from whom, and what happens when it leaks — and on one assumption: every database holding your data will eventually be breached, so your defense has to live in layers you control, not in the institution’s promises.
The Three Failures of 2026#
Start with the evidence, because the pattern only becomes actionable once you see it repeat. Three documented 2026 incidents, across two governments and the public-private boundary, show the same structural weakness from three angles. A breach here means sensitive data became reachable by someone who should not have had it — whether through error, exposure, or over-broad access.
| Incident | What was exposed | Root cause | Status |
|---|---|---|---|
| CISA contractor GitHub leak | Admin keys to 3 government cloud accounts + plaintext passwords (844 MB) | Contractor synced work files via a public repo, with secret-scanning disabled | Repo removed; agency review ongoing |
| CMS Medicare directory | Medical providers’ Social Security numbers | SSNs typed into the wrong field of a public database | Portal taken offline |
| Palantir × NHS access | Identifiable patient records reachable by a vendor’s staff | Contractual admin access, not a hack | Contract active; access ongoing |
The CISA leak is the clearest case. A contractor to the Cybersecurity and Infrastructure Security Agency — the very body charged with defending American networks — maintained a public repository on GitHub (a popular code-hosting site) containing administrator credentials for three government cloud accounts, plaintext password files, signing certificates, and access tokens: roughly 844 megabytes of internal material. According to KrebsOnSecurity, the employee was using the repo to sync files between work and home machines and had deliberately turned off the platform’s built-in protection that blocks secrets from being uploaded. The exposure ran roughly six months before the security firm GitGuardian discovered it; the cloud keys reportedly stayed valid for about 48 hours after the repo came down.
The CMS leak shows the same carelessness with the one identifier you can never replace. The Centers for Medicare and Medicaid Services (CMS — the U.S. agency that runs public health insurance for older and lower-income Americans) published a new public directory of Medicare providers — and, as The Hill reported after the Washington Post first surfaced it, at least dozens of those providers’ Social Security numbers — later reported as more than a hundred — were exposed because the numbers had been entered into the wrong field. The agency pulled the portal offline. A Social Security number is the closest thing Americans have to a permanent skeleton key for identity; once it is public, it stays compromised for life.
The Palantir–NHS case is different in kind, and the distinction matters. This was not a hack. As The Register reported, NHS England confirmed that staff at Palantir — the U.S. data-analytics company running its £330 million Federated Data Platform (the NHS’s central patient-data system) — could hold administrative access to identifiable patient information. No attacker was needed; the access was written into how the system works. The civil-society group Medact documented the resulting concern, and Greater Manchester remained the one regional body refusing to join. The lesson is not “a villain broke in.” It is that concentrating a nation’s health records under a single vendor is itself the exposure, before anyone misuses it.
These are not the only ones. Step back a year and the same shape appears again: beginning in late 2024 and discovered in early 2025, the government contractor Conduent — which runs Medicaid, child-support, and food-assistance systems for multiple states — was breached, exposing the Social Security and health data of more than 25 million Americans. Its systems were restored, though litigation continues and the leaked identifiers do not expire. Several incidents this spring, one the year before, two countries, public and private: the actors change and the failure does not.
Why Governments Leak Structurally#
The comfortable explanation is bad luck — a careless employee, a typo, a bad vendor. The useful explanation is that these are not accidents but outputs of how the systems are built. Four structural forces make government data leakage close to inevitable, and naming them is what lets you defend against the category rather than chasing each headline.
| Structural force | Mechanism | Seen in |
|---|---|---|
| Contractor dependence | Responsibility diffuses with every handoff to an outside vendor | CISA keys held by a contractor; NHS data held by Palantir |
| Shadow IT | Unsanctioned tools route secrets around the safeguards | The contractor’s public GitHub repo |
| Aggregation | One error exposes millions once records are centralised | NHS platform; Conduent’s 25M records |
| Asymmetric accountability | The institution pays a fine; you inherit the permanent risk | All three 2026 cases |
Contractor dependence diffuses responsibility. Modern states do not run most of their own technology; they hire it out. The CISA keys sat with a contractor; the NHS records sit with Palantir; the 25 million records sat with Conduent. Each handoff adds an organisation whose security you cannot see and whose incentives are not yours. The agency owns the consequence; the contractor owns the laptop.
Shadow IT — the tools people use without approval — routes secrets around the safeguards. The CISA employee’s public repo was shadow IT: an unsanctioned convenience that bypassed every control the agency thought it had. Whenever a process is too slow, humans build a faster path beside it, and the faster path rarely has the guardrails.
Aggregation turns a small mistake into a catastrophe. When records are scattered, an error exposes a few. When a federated platform or a national directory concentrates them, the same error exposes millions. Centralisation is sold as efficiency; it is also a single point of catastrophic failure.
Accountability is asymmetric. When a breach happens, the institution issues a statement, perhaps pays a fine, and continues. You inherit the permanent risk. This imbalance is the deepest reason to assume breach: the party that loses your data does not carry the cost of losing it, so it never has enough reason to stop.
Put these together and the conclusion is not cynicism — it is design guidance. You cannot reform four structural forces from the outside. You can build a personal architecture that expects them to fail.
The Defense Architecture: Assume 100% Breach#
Here is the part no breach-response checklist gives you, because it cannot be sold as a one-time fix: a standing architecture that assumes every institution holding your data will eventually lose it. Think of it as five layers, ordered from mindset to mechanics. You will not complete all five at once; you build them the way you build any defense, one layer at a time, strongest where your exposure is greatest.
Layer 1 — Adopt the assume-breach mindset. A threat model is simply a clear answer to “what am I protecting, from whom, and what happens if it leaks?” The shift here is to stop modelling institutions as safe and start modelling them as temporary custodians of data that will eventually escape. This is not paranoia; it is what the 2026 record shows. Once you assume the database will leak, every later decision — what you submit, under which identity, with what fallback — gets easier.
Layer 2 — Minimise what you hand over. You cannot refuse the tax authority, but most data extraction is not legally mandatory. The loyalty programme, the optional profile field, the “verify with your ID” prompt on a service that does not need it — each is a reservoir that can leak later. Treat every optional disclosure as a future breach notification with your name on it. The single most effective privacy control is the data that was never collected. For a practical audit of what has already escaped from years of social media use — and why deletion rarely erases it — see how permanent your social media footprint really is.
Layer 3 — Compartmentalise your identity. I keep a different email address for each major context — finance, health, public life — so that one leaked database cannot be joined to the others. A password manager such as the open-source Bitwarden makes unique credentials per site practical, and a provider like Proton Mail supports per-service aliases that you can burn if they leak. Compartmentalisation does not stop a breach; it stops one breach from becoming all of them. (For the deeper version of this — pseudonyms and jurisdictional separation — see Cora’s work on self-sovereign identity.)
Layer 4 — Lock down the identifiers you cannot change. Some data is permanent: your Social Security number, your date of birth, your biometrics. Because you cannot rotate them, you defend them at the point of use. In the United States, freeze your credit at all three major credit bureaus — the firms that hold your borrowing history: Equifax, Experian, and TransUnion — which blocks new accounts being opened in your name; it is free and reversible. Add fraud alerts. And move your important logins to hardware-based multi-factor authentication (a physical security key, the strongest second factor), so a stolen number alone cannot open the door. This is the one layer where the breach-response checklists and this architecture agree — the difference is that here it is permanent hygiene, not a panic reaction.
Layer 5 — Separate your tools and jurisdictions. Spread your trust across providers and legal regimes that are not all reachable by the same actor. Encrypted messaging for sensitive conversation, a no-logs VPN (Virtual Private Network) such as Mullvad to break the link between your network and your activity, and storage that is not concentrated under one company or one government. The goal is that no single breach, subpoena, or vendor relationship exposes the whole picture.
Notice what this architecture does not require: it does not require the institution to be trustworthy. That is the point. Each layer is a control you hold, not a promise you are given.
If You’re Already Exposed#
If your data is in one of these breaches — and statistically, it already is — the immediate steps are narrow but worth doing today, before the standing architecture above. These are the steps I treat as non-negotiable; treat this as triage, not the whole treatment.
- Freeze your credit at all three bureaus (free, online, reversible). This is the highest-leverage single action.
- Set fraud alerts on your financial accounts and turn on transaction notifications.
- Assume permanent identifiers stay compromised. A leaked Social Security number does not expire; rotate everything you can (passwords, account numbers) and defend the rest at the point of use.
- Move to hardware MFA on email and finance first — email is the recovery path for everything else.
- Watch for targeted phishing. Breached data makes scams personal; a caller who knows your real details is using leaked data, not proof of legitimacy.
These steps close the immediate window. The layered architecture is what keeps the next breach — and there will be a next one — from costing you the same way twice.
Frequently Asked Questions#
Can I sue the government for leaking my data?#
Sometimes, but it is rarely a remedy you can count on. Sovereign-immunity rules, caps on damages, and the difficulty of proving specific harm make government breach litigation slow and uncertain. Treat legal action as a possible afterthought, not a defense — your layered architecture is what actually reduces your exposure.
Is freezing my credit enough?#
No, but it is the best single action. A credit freeze blocks most new-account fraud, yet it does nothing for medical-identity theft, tax fraud, or the misuse of a leaked Social Security number outside credit applications. Pair it with fraud alerts, hardware MFA, and identity compartmentalisation.
If the data is already leaked, isn’t defense pointless?#
No. Most harm from a breach happens after exposure, when leaked data is used to open accounts, impersonate you, or craft targeted scams. Freezing credit and hardening your logins blocks the exploitation step even when the underlying data is already out.
Does this only apply to the United States?#
The specifics differ — credit freezes are a U.S. mechanism, and the NHS case is British — but the architecture is universal. Every country aggregates citizen data and outsources its handling. Minimisation, compartmentalisation, and protecting permanent identifiers apply wherever you live.