The following is an AI model depiction based on a true story. Names, timelines, and identifying details have been changed. If you lead security, IT, HR, or a startup — this one is for you.

When Daniel took the security job at the AI startup, he thought he knew what he was walking into. He’d spent a decade in cybersecurity — incident response, compliance audits, the unglamorous plumbing of keeping companies out of the news. A startup building on AI wanting someone to think seriously about security? That sounded like a company that had its priorities straight.

His first assignment landed on his desk before his laptop finished enrolling in MDM: review the AI policy.

The document was a time capsule. Outside counsel had drafted it back when Google’s AI was recommending a daily serving of small rocks and the internet’s idea of state-of-the-art was Will Smith fighting a bowl of spaghetti — the era when “hallucination” stopped being a medical term and became a line item on every legal team’s risk register. Some of it was common sense that would survive any era. Verify anything an AI produces before it ships. Disclose when work is entirely machine-generated. And the load-bearing rule, the one that actually mattered: never share business documents with an AI service that doesn’t have a zero-data-retention agreement in place.

Reasonable. Defensible. Also, in places, obsolete on arrival — written for a threat landscape that had already moved, by people whose job was to imagine liability, not workflow.

Here’s the detail that matters for everything that follows: the policy was never released. Never published, never signed, never acknowledged by a single employee. It existed the way a ghost exists — officially nowhere, effectively everywhere.

Testing the fence

Daniel did what any good security professional does with a control: he tested it. Not to break it — to understand it. Where were the edges? What did the policy actually permit, and did the organization’s behavior match?

So he worked at the boundary, deliberately and carefully, never once crossing the lines the document drew. He verified everything. He disclosed what needed disclosing. When he finally used an AI tool with an internal document, he did it by the book — a service with zero data retention, exactly the configuration the policy blessed. If the policy had been real, he was its model citizen. He was doing, in miniature, what a security team is supposed to do at the organizational level: red-team the rules before reality does.

What he hadn’t modeled was the environment the rules lived in.

The startup’s IT department had practices of its own — monitoring that was never disclosed, visibility that no one had consented to, an ethics posture best described as don’t ask. Somebody saw the document go into an AI tool. Nobody checked the retention settings, or the policy, or asked him a single question. The story that traveled was simpler and stickier: the new security guy is feeding company documents to AI.

In a startup, a story like that doesn’t spread at the speed of email. It spreads at the speed of lunch.

Governance by rumor

Within weeks, Daniel was the cautionary tale. The guy who “used AI inappropriately.” The guy who got caught. The jokes wrote themselves and kept getting told, and there was no forum to correct the record — because correcting it would have required someone to produce the policy he’d supposedly violated, and the policy didn’t officially exist. You cannot appeal a verdict issued by a whisper network. There’s no inbox for that.

And here’s the perverse part: it worked. Not for Daniel — for the company. Or so it seemed.

Watching what happened to him, people drew the rational conclusion: AI is radioactive here. Developers — the people with the most to gain — quietly stopped experimenting. The AI enthusiasts kept evangelizing, but enthusiasts don’t set culture; consequences do, and everyone had watched the consequences eat a security professional who’d followed rules more carefully than anyone else in the building.

The company had achieved perfect AI governance without ever publishing a policy. No slop shipped, because almost nothing AI-touched shipped at all. Leadership got containment for free, paid for entirely in one employee’s reputation.

What they’d actually built was a chilling effect wearing a compliance costume. And a chilling effect doesn’t invoice you monthly — it collects at the end.

Forty days in the desert

What followed was the long dry season. Months of it. No policy, no guidance, no water — just the memory of what had happened to the last person who drank.

Most people dried out. Developers above all. They hand-wrote what the rest of the industry was generating, reviewing, and shipping; they watched competitors compress weeks into days and told themselves it was discipline. Skills that should have been compounding sat idle. An AI startup was falling behind on AI, and the people falling behind fastest were the ones following the unwritten rules most faithfully.

But deserts are never as empty as they look. A few people thrived out there — quietly. They’d watched Daniel’s story closely enough to learn the real lesson, which was never don’t use AI. It was don’t be seen. So they used it on personal machines, on personal accounts, off the network, with none of the safeguards Daniel had bothered with — no zero-data-retention agreements, no verification discipline, no disclosure. Their output got faster and cleaner, and nobody asked why, because asking would have meant knowing. The company’s actual AI exposure didn’t drop during the drought. It went underground, where no control could reach it.

That’s the part leadership never saw on any dashboard: the crackdown-by-rumor hadn’t eliminated risky AI use. It had eliminated visible, compliant AI use — and selected for the invisible, uncontrolled kind. The desert didn’t kill the appetite. It just taught everyone left standing to hide the canteen.

Then a new model dropped — one of the mythic ones, the kind whose demos stop being funny and start being résumé-threatening. It didn’t eat rocks. It didn’t mangle spaghetti. It did in minutes what the naysayers had spent months insisting it never could. And just like that, the loudest voices in the desert went silent — because you can mock a machine that hallucinates, but not one that ships.

The reveal

Then one day, with no ceremony, a policy appeared. A watered-down descendant of the lawyer’s original — shorter, softer, strikingly permissive.

The reaction across the company was a collective wait, what? We can use AI with business documents? We can use it for code? Since when? The loudest internal critics of AI — people who had built minor identities around abstaining — were stunned into silence. The rules they’d been enforcing socially for years had never actually existed, and the rules that now existed permitted almost everything they’d been policing.

But the new policy carried a rider, and this is where the story stops being a comedy of errors and becomes something colder: everything done with AI would be monitored, logged, and analyzed. The same undisclosed surveillance apparatus that had produced Daniel’s trial-by-rumor was now official, formalized, and pointed at everyone. Adoption was permitted. It was also, from that moment, evidence — a record that could be read charitably or uncharitably depending on who was reading, and why, and what they needed it to say.

Which completes the trap. Don’t use AI, and you fall behind — measurably, visibly, in an industry that has stopped waiting. Use it, and you generate a perfect, permanent log of every judgment call you made, held by people who have already demonstrated exactly what they’ll do with ambiguous information about you.

Daniel followed the rules and lost. His colleagues avoided the rules and lost slower.

What actually failed

It’s tempting to file this as an AI story. It isn’t. Every failure in it is an old-fashioned security failure wearing new clothes.

An unpublished policy is not a policy — it’s a liability shield for the company and a landmine for employees, because people are accountable to rules they can see. Undisclosed monitoring isn’t a control either; it’s an insider threat run by the IT department, and the trust it burns never comes back at par. When an organization enforces norms through reputation instead of process, it hasn’t avoided governance — it has outsourced it to gossip, the least accurate audit mechanism ever devised. And a chilling effect will always look like successful risk management right up until the moment you check the scoreboard.

The moral Daniel’s friends took away was you can’t win. Understandable — from inside that company, you couldn’t.

But if you’re the one writing the policy, running IT, or leading the startup, the moral is different, and it’s actionable: your people are already operating under some AI policy — the only question is whether you wrote it, or the rumor mill did. Publish the real one. Disclose the monitoring. Say what’s allowed as loudly as what isn’t. Because the alternative isn’t control.

The alternative is Daniel — and a company that laughed at the one person who read the rules.

In 2025, “prove you’re an adult” stopped being a checkbox and started becoming a protocol. The UK’s Online Safety Act crossed into hard enforcement on 25 July. Australia switched on a nationwide under-16 social-media ban on 10 December. Roughly half of US states now gate adult content behind ID checks. The EU is piloting an age-verification app, France has been pushing the issue for years, and Canada is working through its own cluster of bills. The framing is consistent everywhere: this is about protecting children.

The framing is also, on the evidence accumulated over the first year of real-world deployment, wrong about its central promise. The children these laws target are largely routing around them. The adults who were never the target are handing government IDs and biometric scans to third-party vendors with track records that range from mediocre to catastrophic. And underneath both failures, something more durable is being assembled: a general-purpose age-and-identity layer for the internet, normalized in the name of safety, that no one will dismantle once the moral urgency fades.

This is the argument I want to make as plainly as the evidence allows. Not that child safety is unimportant — it is the most important thing here — but that mandatory age verification is the wrong tool, that it fails on its own terms, that it imposes serious and asymmetric costs on the general population, and that better, less destructive alternatives already exist and are mostly being ignored.

What the laws actually require

A quick map of the landscape, because the specifics matter and the rhetoric tends to flatten them.

United Kingdom — Online Safety Act 2023. The Act received Royal Assent in October 2023. Services publishing their own pornographic content (Part 5) had to begin implementing “highly effective age assurance” from January 2025; user-to-user services hosting such content (Part 3) had to comply by 25 July 2025, with no grace period and no phased rollout. Acceptable methods include government-ID upload, credit-card checks, and AI facial age estimation. Penalties run to £18 million or 10% of global turnover, whichever is higher, plus business-disruption measures up to and including ISP-level blocking. The Act is explicitly extraterritorial — it binds any service with UK links regardless of where it is registered, which is why Ofcom’s enforcement action against 4chan is in scope at all. By February 2026, Ofcom had opened investigations into more than 90 services and issued its first half-dozen fines.

Australia — Online Safety Amendment (Social Media Minimum Age) Act 2024. From 10 December 2025, platforms including Facebook, Instagram, TikTok, YouTube, Snapchat, Reddit, X, Threads, Twitch, and Kick must take “reasonable steps” to keep under-16s from holding accounts, on pain of fines up to AUD 49.5 million. Notably, the law bars parents from consenting their children back in, and imposes no penalty on the children or families themselves — the entire compliance burden sits on platforms.

Canada — Safe Social Media Act. First stab was Bill S-210, the original “Act to restrict young persons’ online access to sexually explicit material,” which passed the Senate in 2023 and then stalled; Bill S-209, its reintroduced 2025 successor, now folding in age-estimation technologies and a narrower definition of explicit content, under Senate consideration into 2026; Bill C-63, the Online Harms Act, which died on the order paper at prorogation ahead of the 2025 election; and most recently Bill C-34 (June 2026), which pairs a kids’ social-media ban with mandated age verification and new AI-chatbot rules. Whichever of these the original question meant, the analysis below applies — they share the same architecture and the same failure modes.

United States. No federal mandate, but roughly half the states have enacted ID-based checks for adult content, which is why Pornhub now geoblocks several states outright rather than comply. California’s Digital Age Assurance Act (AB 1043) takes a different route — device-level signals — with a 2027 deadline that is already shaping Apple’s and Google’s roadmaps.

The throughline: a patchwork of overlapping, often extraterritorial mandates, converging on the same handful of verification techniques, with early-2027 deadlines acting as a forcing function for the whole industry to lock in technical approaches now.

Argument one: children will not be safer

The promise is prevention. The evidence, one year in, is circumvention.

The instant, visible workaround

When the UK switched on enforcement, the response was immediate and measurable. Proton reported sustained daily VPN sign-up increases of 1,400–1,800% from UK users — levels the company said it normally associates with civil unrest. NordVPN reported a 1,000% spike. On enforcement day, half of the top ten free apps in the UK App Store were VPNs or identity tools. A VPN relocates your apparent location outside UK jurisdiction in about thirty seconds, and the technique is neither obscure nor expensive. By December 2025, the House of Lords was openly debating VPN circumvention — and, more damningly, child-safety group Childnet reported increased VPN use among children in the months after enforcement. The precise population the law was written to protect learned the workaround fastest.

The “it’s working” numbers don’t show what they claim

Australia’s government announced that platforms had removed roughly 4.7 million under-16 accounts within the first month and declared the policy a success. Account removal is not the same as access prevention, and the regulator’s own follow-up makes the gap explicit. The eSafety Commissioner’s first compliance report flagged “poor practices,” including platforms letting minors retry the same age-assurance method until they passed, and “insufficient measures” to stop new under-16 accounts from being created at all. Reporting three months in found that a large majority of children with pre-ban accounts still had access to at least one platform, with no discernible drop in harm complaints. Removing five million accounts is impressive theatre. It is not evidence that five million children lost access.

The bypass toolkit is mature

The 438-strong coalition of security and privacy researchers who signed the February 2026 open letter calling for a moratorium catalogued the bypass methods bluntly, because they aren’t speculative. Borrowed or purchased credentials — an older sibling’s verified account is the canonical example. Bought identities from the black markets that reliably spring up the moment age-gating creates demand. Props and AI tools, including deepfakes and AI-generated faces that defeat facial age estimation. And, repeatedly documented, parents themselves helping children circumvent the checks. The letter’s summary judgment is that lying about your age online is, and will remain, easy.

Deplatforming pushes kids somewhere worse

This is the part that should worry child-safety advocates most, and it is the part the laws ignore.

Deplatforming doesn’t dissolve demand; it redirects it. When access to a mainstream, moderated, heavily-resourced platform is gated, determined users — including minors — migrate. They don’t migrate up to safer ground. They migrate to fringe sites, offshore services, and unregulated corners that escape the mandate precisely because they’re too small, too foreign, or too deliberately evasive to be in scope. Those are the environments with the weakest moderation, the worst CSAM controls, the most aggressive malware, and the most scams. A regime that successfully nudges a fourteen-year-old off a major platform’s age-gated front door and onto an unmoderated Telegram channel or a malware-laden free-porn mirror has not protected that child. It has degraded their safety while generating a compliance metric that says the opposite.

A countermeasure that the target population defeats in thirty seconds, that the regulator’s own audits show leaking, and that displaces risk toward less-safe venues is not a child-protection measure. It is a child-protection gesture — and gestures that feel like action are how genuinely harder problems get to be ignored.

Argument two: everyone else loses privacy

Here is the asymmetry at the core of the design. The children mostly route around the wall. The adults — the entire non-target population — walk up to it and hand over identity documents. That trade would be questionable even if the verification infrastructure were secure. It is not.

The honeypot problem is not hypothetical

Every site that verifies age has to either collect sensitive data (an ID image, a biometric scan, a credit-card record) or trust a third party to do it. Either way, the mandate manufactures honeypots: concentrated stores of exactly the data identity thieves, stalkers, and extortionists want most, distributed across thousands of operators of wildly varying competence. You don’t get to choose the security posture of every adult site, dating app, and forum you’re now required to verify against. You just get to absorb the breach when one of them fails. And at internet scale, one of them always fails.

Two case studies from 2025 make the point concretely.

Discord (October 2025). Discord disclosed that attackers had compromised a third-party customer-service vendor (5CA, based in the Netherlands) and exposed sensitive data for affected users — including roughly 70,000 government-ID images that users had submitted for age-related appeals. The attackers, a group identifying as the Scattered Lapsus$ Hunters, claimed a far larger haul (on the order of 1.5 TB) and used the access in an extortion attempt. The critical detail for policy: Discord itself wasn’t breached. Its vendor was. Mandatory verification doesn’t just expand the attack surface of the platforms you trust; it extends it through every subprocessor, support contractor, and “trusted” age-assurance partner those platforms quietly rely on — exactly the layer users can’t see and can’t audit.

Tea (July 2025). Worth scoping precisely: Tea was an identity-verification case, not strictly age verification — a women’s dating-safety app that had required selfies and government IDs to register (a requirement it had already phased out). But it is the cleanest available illustration of where verification data ends up. An unsecured Firebase storage bucket exposed roughly 72,000 images, including about 13,000 selfies and photo IDs. The cache was discovered and dumped on 4chan, and within hours the leaked driver’s licenses and image metadata were being assembled into a searchable map of users’ locations. An app sold as a safety tool became a doxxing engine. The lesson transfers directly: the data you surrender to prove who you are becomes, at the moment of breach, a precision instrument for harming you.

The pattern beneath both: the verification step doesn’t merely risk a breach, it changes the character of breaches. A leaked password is a nuisance you can rotate. A leaked passport, bound to your face and your home location, is permanent and unrotatable. Age-mandate breaches convert recoverable incidents into irreversible ones.

“We don’t retain the data” is a promise, not a control

Vendors and platforms routinely assure users that IDs aren’t stored or linked to accounts — Discord and others say exactly this. Those commitments may be sincere. But users have no independent visibility into whether they hold, no way to verify deletion, and no recourse when a subprocessor two hops down the chain logs what it promised to discard. “Trust us, it’s ephemeral” is not a security architecture. It’s a marketing claim with the durability of the next breach disclosure.

The experts are not equivocating

The February 2026 moratorium letter — 438 researchers across 32 countries — did not hedge. Its core finding is that no existing age-verification system can reliably confirm a user’s age without simultaneously collecting sensitive data that becomes a liability, and that there is no scientific evidence these controls improve child safety. NIST’s repeated documentation of demographic bias in facial-recognition and age-estimation systems — worse error rates for people of color and for transgender individuals — sits underneath the privacy objection as a second, independent failure: the “privacy-preserving” biometric option is also the discriminatory one.

The unintended side effects, catalogued

Even granting good intentions, a policy should be judged by its full consequence set. Here is the ledger that the “protect the children” framing tends to leave off the page.

That last cluster deserves emphasis. “You must show ID to enter” changes behaviour around lawful content the same way it does in physical space — people self-censor, avoid, and stay away from things they have every right to access, because the act of proving identity to reach them feels like surveillance. It is surveillance. The chilling effect isn’t a bug to be tuned out; it’s an inherent property of putting an identity checkpoint in front of speech.

What actually works better

The strongest objection to critics of age verification is fair: fine, but children really are encountering harmful content, so what’s your alternative? The honest answer is that better tools exist, several are already deployed, and most have a fraction of the privacy cost. None is perfect. All are less destructive than per-site ID collection.

1. Device- and OS-level age signals

Instead of every website running its own ID check, the age determination happens once, at the device or operating-system layer, and is passed downstream as a coarse, bracketed signal. Apple’s Declared Age Range API and Google’s Play Age Signals API return ranges (e.g., “under 13,” “13–15,” “16–17,” “18+”) rather than birthdates or documents. California’s AB 1043 codifies this approach. A parent sets the child’s age band at device setup; apps query the signal in real time and make access decisions without ever seeing — or storing — an identity document.

Why it’s better: It collapses thousands of honeypots into one decision point, shares the minimum necessary information (a band, not a passport), and prohibits long-term retention of age data. The friction is paid once.

Honest tradeoffs: It is still fundamentally a declared or parental-set signal — it attests to a setting, not to who is physically holding the phone right now, so it’s defeatable by a determined teen with access to an adult’s device. And it deepens Apple’s and Google’s control over the stack, a real competition and centralization concern. It’s a mitigation, not a magic fix. But “one privacy-preserving signal, set once, retained never” beats “an ID upload to every adult site you visit” on every axis that matters.

2. DNS-level filtering — the most underrated tool in the box

This is the alternative that gets the least airtime and arguably delivers the most protection per unit of privacy cost. The Domain Name System resolves the names you type into the addresses your device connects to. Point your home network at a filtering resolver and inappropriate domains simply never resolve — network-wide, for every device, with nothing installed and no data handed to anyone.

Set it on the router and it covers the whole house in about five minutes. It’s free, it leaks nothing about your identity to any site, and it’s trivially reversible by the adult who controls the network. Its limits are honest ones — a tech-literate teen can change a device’s DNS, use DoH to bypass it, or tether to mobile data — which is exactly why it belongs in a layered approach rather than being sold as a silver bullet. But as a default first line of defence in the home, it does most of what parents actually want, with none of the surveillance.

3. Real parental controls and on-device tooling

The mature parental-control ecosystem — built into iOS Screen Time and Android Family Link, extended by tools like Qustodio for time limits, app blocking, and activity reporting — keeps decisions where developmental context lives: with the parent who knows whether a given child is ready for a given thing. A blanket legal age line treats a 10-year-old and a 15-year-old identically, ignoring exactly the judgment that good parenting supplies. On-device controls are granular, they’re already shipped on the devices children use, and they don’t require anyone to build a national ID database.

4. Attack the root cause: data minimization and a real privacy baseline

The deepest fix is the least discussed. A large share of the harm that age verification is meant to address — manipulative engagement-maximizing design, predatory data collection from minors, addictive feeds — flows from a surveillance-advertising business model that current law permits. Comprehensive data-minimization rules that restrict what platforms may collect and exploit, especially from children, reduce those harms without requiring anyone to prove who they are. Strong privacy legislation should be the prerequisite, not an afterthought: without it, an “age signal” is just one more data point to monetize. Regulating platform design — duties to act responsibly, transparency obligations, researcher data access, real penalties for engagement dark patterns — targets how these services actually cause harm, instead of erecting an identity checkpoint and calling it safety.

Steelmanning the other side

Intellectual honesty requires engaging the strongest version of the case for mandatory verification, not the weakest.

“Some friction is better than none.” True, and the strongest point the proponents have. Even a leaky gate deters the casual, accidental encounter — the curious twelve-year-old who stumbles onto something, rather than the determined fifteen-year-old hunting for it. Reducing accidental exposure has real value. The rebuttal is one of proportionality: you can capture most of that deterrence with DNS filtering and device-level controls — which raise the same casual-encounter friction — without building a national identity-collection apparatus and without the breach, exclusion, and chilling costs. If the goal is friction against accidents, the cheapest, least invasive tool that produces friction wins. Per-site ID collection is the most invasive tool that produces it.

“The offline world already does this.” We card people at liquor stores and casinos, the argument goes, so why not online? Because the offline check is ephemeral and local — a bouncer glances at a license and forgets it. The online equivalent uploads a permanent, copyable, breachable digital image of that license to a remote server and a chain of subprocessors. The analogy holds for the intent and breaks completely on the mechanics — and the mechanics are where all the harm lives.

“Platforms have failed to self-police, so the state must act.” Also largely true — voluntary moderation has been inadequate. But the conclusion doesn’t follow. The choice isn’t “ID mandates or nothing.” Design regulation, data-minimization law, mandatory parental tooling, and default-on network filtering are all forms of the state acting, none of which require turning the internet into a checkpoint.

The proponents are right that the harm is real and that doing nothing is not acceptable. They are wrong that this specific instrument addresses it. Caring about the problem and opposing this solution are fully compatible positions — indeed, taking child safety seriously is a reason to reject a measure that fails children while costing everyone else their privacy.

The part that outlives the panic

Strip away the specifics and here’s what the first year of deployment demonstrates. The targets evade the controls — visibly, immediately, and in growing numbers. The non-targets pay with their most sensitive data, into systems that are already breaching at scale. The infrastructure being built to enforce all this — device-bound identity signals, biometric estimation, ID-collection pipelines, the apparatus for jurisdictional website blocking — is general-purpose, and it doesn’t get uninstalled when the headlines move on. As the EFF observed, age is simply the first identity attribute being wired into the operating architecture of the internet. Once that architecture exists and everyone is conditioned to authenticate identity to access content, the marginal cost of extending it — to other attributes, other content, other reasons — drops toward zero. There is no putting that toothpaste back in the tube.

Children deserve a safer internet. They will not get one from a system they defeat in thirty seconds, that leaks their parents’ passports onto 4chan, and that quietly builds the most consequential surveillance infrastructure of the decade while everyone is looking at the children. The better tools are unglamorous: a DNS setting changed on a router, a device age band set at setup, a parental-control app, a privacy law with teeth. They are also the ones that actually trade off correctly — more protection, less surveillance — which is presumably why they keep losing to the version that photographs well in a press release.

A sentence that gave away the plot

On March 31, 2024, millions of people tried to launch a video game they had bought — some of them ten years earlier, at full price, on physical discs in shrink-wrapped boxes — and discovered it no longer existed.

The game was Ubisoft’s The Crew. It was a commercial hit; over two million copies sold in its first month, successful enough to spawn two sequels. Ubisoft stopped selling it in late 2023, then switched off the servers it required on March 31, 2024. Because the game checked in with those servers to run, every copy — online, offline, purchased, preordered, collector’s edition — became a small, polite error message.

When two Californians sued in late 2024, arguing that “bought” is supposed to mean bought, Ubisoft’s legal response contained a sentence that belongs carved above the entrance of every digital storefront on Earth. According to reporting on the filings, Ubisoft’s lawyers argued that the plaintiffs never actually purchased the game. What they had acquired was a limited license to access it. The game’s packaging, they pointed out, said so — in capital letters.

When France’s largest consumer protection organization, UFC-Que Choisir, filed its own suit in March 2026, its position was that revoking “licenses” this way violates consumer rights. In the interim, a grassroots movement called Stop Killing Games had collected over 1.2 million verified EU signatures and reached the European Parliament. California passed a law requiring digital storefronts to state clearly, before checkout, that “buy” means “license.” Shortly afterward, Steam began displaying exactly that disclaimer.

One small game. One sentence in a legal filing. And suddenly a decade’s worth of quiet inversion was visible in broad daylight.

We are, slowly and then all at once, being evicted from the ownership economy into the license economy. And the most remarkable thing about this transition is how neatly it inverts the most-repeated promise of the AI era — that abundant machine intelligence would liberate us from toil, not rent us back the conditions of our own lives.

The pattern you’ve been trained not to see

Once you notice it, the pattern is everywhere:

Your tractor. John Deere, the single largest maker of farm equipment in North America, has spent years locking farmers out of their own machines through software. The full diagnostic tool needed to repair a modern Deere tractor is available only to authorized dealers. A stripped-down version for farmers costs about $3,000 per year and still redacts the key functions. In January 2025, the FTC and several states sued Deere over these practices. In April 2026, Deere settled a parallel class action for $99 million and agreed to make diagnostic tools available for at least a decade. Public Interest Research Group estimates that repair restrictions across all manufacturers cost U.S. farmers about $4.2 billion a year.

Your car. In 2022, BMW began charging owners roughly $18 a month to activate heated seats — hardware physically installed in every car the moment it left the factory. The backlash was severe enough that BMW dropped that particular subscription in 2023. But the broader model didn’t go away; it retreated upmarket. Tesla now sells Full Self-Driving only as a monthly subscription. Mercedes charges annual fees to unlock acceleration in EQ electric cars. Volkswagen sells horsepower by the month. The car you paid $60,000 for is, increasingly, a device that has to phone home to deliver the performance you thought you bought.

Your printer. HP pushes firmware updates that disable third-party ink cartridges and, by some accounts, even expired first-party ones — a practice so extensively litigated it has its own Wikipedia entry.

Your books. In 2009, in a moment that should be taught in every business school as an omen, Amazon remotely deleted copies of George Orwell’s 1984 from Kindle devices over a licensing dispute. Customers woke up to find pages they’d highlighted the night before no longer existed.

Your software. Adobe killed perpetual Photoshop licenses in 2013. Microsoft Office became Microsoft 365. Autodesk, Jetbrains, 1Password — all of it moved from one-time purchase to perpetual rent, often alongside genuine product improvements that made the rental feel briefly reasonable.

Your music and movies. The “Buy” button on most streaming platforms is doing heroic work of imagination. Songs and films vanish from personal libraries when label contracts change. Movies you “own” on iTunes disappear when regional rights expire.

Your smart home. Revolv, a popular home-automation hub Google acquired through Nest, was simply bricked in 2016 when Google decided to stop running the servers. Every device turned into a paperweight. This happens quietly and routinely — it is now a risk category for any internet-connected appliance.

This isn’t a conspiracy. It’s a business model, compounded by network effects, venture-scale return expectations, and the quiet architectural fact that almost everything now needs a server somewhere to work. The software industry learned that recurring revenue is worth roughly five to ten times transactional revenue in enterprise valuations. Then every other industry noticed.

What we are watching is the financialization of possession. Things that used to be capital — tractors, cars, books, tools — are being refactored into services. This is wonderful for the balance sheets of a small number of platforms. It is, for everyone else, the slow disappearance of a form of wealth they may not realize they had.

What we traded away

The old ownership economy was never perfect, and it certainly wasn’t equally distributed. But it had a load-bearing property that is easy to miss when you have it and brutal to notice when it’s gone: owned things compound into stability.

A house you own is a hedge against rent increases. A car you own is a hedge against subscription fees. A library of books, records, tools, and skills you own is a hedge against a vendor you will never meet deciding the server isn’t worth running anymore. Ownership is, among other things, a form of insurance against the future’s moods.

The twentieth-century political project in most democracies — whatever you think of its execution — was broadly about spreading ownership. Homesteading. Public libraries that lent genuine copies of genuine books. GI Bills and mortgage guarantees. Pensions that were actual funds, not just promises. Small business formation as an ordinary, expected life path. The cultural default was that your work produced accumulating artifacts: a house, tools, savings, a trade, a business, a deed.

The twenty-first-century version is different. You don’t own the music you listen to, the shows you watch, the software you write in, the car you drive, increasingly the tractor you farm with, and almost none of the platforms you rely on to make a living. Much of this is fine in isolation — who really wants to rack their own servers for Netflix. It becomes strange when you add it up. Most of the financial flows that used to build household balance sheets now flow laterally into platform balance sheets as rent. The median American household pays more per month in subscriptions than at any point in history, and that figure continues climbing.

This is the decor of the room. Now look at the wallpaper.

The inversion: what AI was supposed to be, and what it is becoming

The pitch for artificial intelligence — the real pitch, the one in the blog posts and keynotes, not the carefully hedged ones in the 10-Ks — was abundance.

In 2016, Sam Altman wrote on the Y Combinator blog about funding a basic-income experiment because he thought technology might eliminate enough “traditional jobs” that societies would need to rethink how people receive income at all. Elon Musk has said repeatedly that in a benign AI future, “probably none of us will have a job” and that there would be “universal high income.” Even corporate communications from the major labs lean on the same frame: AI will produce so much economic output, so cheaply, that humanity’s relationship to scarcity itself will change.

The implicit deal was this: yes, the transition will be disruptive, possibly brutal for particular workers and industries, but on the other side lies something like a utopia of near-free cognition. UBI, in this framing, is a bridge to that utopia — a cash transfer to keep people whole while the economy reorganizes around machines.

The OpenAI-backed basic-income study, run by OpenResearch, released its findings in July 2024. Three thousand low-income participants received $1,000 per month for three years. The results were interesting but not euphoric: recipients worked about 1.3 hours less per week, spent more on food, rent, transportation, and helping family members, used a bit more healthcare, and made more entrepreneurial moves. They did not, contrary to fears, stop working. They also did not, contrary to hopes, find dramatically better jobs. Short-term mental-health gains faded after the first year.

UBI, it turns out, helps. It is not magic.

Meanwhile the labor market numbers have started to turn. Anthropic’s CEO Dario Amodei predicted in 2025 that AI could eliminate roughly half of entry-level white-collar positions within five years. Cornell University research found U.S. companies adopting AI have reduced junior hiring by about 13 percent. A Stanford study in 2025 provided early large-scale evidence that the effect lands hardest on workers in early-career cognitive roles. Employment of software developers aged 22 to 25 has fallen roughly 20 percent from its late-pandemic peak. In the first six months of 2025 alone, roughly 78,000 tech layoffs were attributed to AI; modeling estimates for the full year suggest the real, unreported number is several times higher.

Now sit with the pieces next to each other:

1. The productive capital of the coming economy — training compute, model weights, inference capacity, proprietary data — is being concentrated into a handful of companies, more concentrated than any industrial revolution that preceded it.
2. That same handful of companies owns, or is rapidly acquiring, the platforms on which the rest of us rent access to everything: documents, storage, software, media, communication, search, and now thinking.
3. The compensation framework being proposed for the disrupted majority is a subsidy — potentially funded by taxing the AI companies themselves — that would flow through to them again anyway, because we rent our lives from them.

A sharp 2025 paper in Frontiers in Artificial Intelligence by Jean-Christophe Bélisle-Pipon frames this as a form of “symbolic violence” — a UBI advocated by AI elites risks legitimizing, rather than challenging, a world divided between AI owners, a narrow class of AI-capable workers, and a vast population of recipients. Whatever you think of the framing, the structural observation is hard to argue with. A basic income that keeps you housed and fed while the tools of production are owned elsewhere is not emancipation. It is a subscription to existence, paid by the very platforms that collect rent on everything else you do.

This is the inversion. The promise was that abundant intelligence would free us from toil. What is actually being built is a world in which even the refusal to pay rent — on your software, your car, your data, your tractor, your attention — becomes progressively more difficult.

The good news is that this is not a law of physics. It’s a set of choices. Which means there are counter-choices.

Why the arithmetic gets worse the longer you wait

Three dynamics make the license economy compound against you over time.

Rents are multiplicative, not additive. Every subscription is forever, and every forever is priced into the NPV of every platform that adds one. A $15 monthly subscription is a $1,800 ten-year commitment at zero inflation — and none of these prices stay flat. Netflix, Adobe, Microsoft 365, YouTube Premium, Spotify, ChatGPT Plus: every one of them has raised prices at or above inflation since launch. Meanwhile, the transaction costs of canceling are engineered upward.

Skills and knowledge atrophy in a rented world. When nobody owns, nobody maintains. When nobody maintains, nobody learns. Repair knowledge, sysadmin knowledge, the quiet competence of running your own things — these were dense commons fifty years ago. They are thinning now. The license economy is, among other things, a deskilling engine, because the incentive structure rewards platforms that keep complexity on their side of the API. This is especially true with AI tools: a generation of developers who only know how to call cloud APIs are, in an important sense, not portable across the end of a vendor relationship.

Political leverage follows ownership. Renters, historically, have less political voice than owners. The patient constituency for interoperability, repair, portability, and competition is built out of people who have something concrete to defend. Every subscription is a small vote for the current arrangement. Every piece of local infrastructure — a laptop you can repair, a server in your closet, a backup in a drawer, a skill in your head — is a small vote for the next one.

Fighting back: the personal level

The goal at the personal level isn’t to exit the modern economy. It’s to be strategically ownership-heavy on the things that matter to you, so that no single vendor decision can wipe out a meaningful part of your life.

Own your data. Pick a local-first architecture and stick with it. Practical stack: a NAS or small server running Nextcloud for files, Immich for photos (a genuinely compelling replacement for Google Photos), Paperless-ngx for documents, Jellyfin for media. Syncthing for device-to-device sync without a central server. Back up with the 3-2-1 rule: three copies, two media, one offsite. None of this is as convenient as the cloud. All of it is permanent in a way the cloud is not.

Own your devices. Prefer repairable hardware. Framework laptops are the cleanest expression of this ethic. Phones are harder, but a Pixel running GrapheneOS remains the best combination of privacy, security, and longevity. Run Linux where you can — Fedora, NixOS, or Ubuntu — not because Windows is bad but because the day Microsoft decides Windows is a service, you want other options.

Own your compute. This is newly important. Local LLMs have crossed the threshold from curiosity to workhorse. Ollama and LM Studio make it trivial to run capable models — Llama 3, Qwen, Mistral, Gemma — on an M-series Mac or a modest GPU. For the majority of day-to-day tasks (drafting, summarization, code assistance, research synthesis), a good local model is sufficient, free, private, and immune to service outages or policy changes. Pay for frontier models when the task genuinely demands it, but stop letting every keystroke flow through a third party’s context window.

Own your media. Buy DRM-free where possible: ebooks from Kobo or Standard Ebooks, audiobooks from Libro.fm, music from Bandcamp or as actual FLAC files. Keep a local library. Streaming is fine for discovery; the things you’ll still want in a decade deserve to live on your drive.

Own your information diet. RSS readers (try Miniflux or FreshRSS) instead of algorithmic feeds. Download the PDF, don’t just bookmark the article. Snapshot what matters with a tool like ArchiveBox.

Own your skills. The single highest-leverage personal investment in an ownership-hostile world is literacy in the tools that let you route around vendor decisions: shell, git, Docker, a scripting language, basic networking, basic electronics. You don’t have to become an engineer. You have to become hard to hold hostage.

Use AI as your leverage, not your landlord. The irony worth naming out loud: the same technology reshaping the labor market is also the single biggest boost to the ownership path that has ever existed. Every obstacle that kept self-hosting niche — cryptic config files, opaque error messages, the sysadmin tax of running your own things — is exactly the kind of friction LLMs dissolve. A local model on your laptop is a patient, always-available tutor that will write your Nextcloud docker-compose.yml, debug a failing Jellyfin transcode, explain what that nginx log line means, and script your Google Takeout into Immich. The historical asymmetry — “proprietary is easier because somebody else absorbs the complexity” — is inverting. With AI on your side of the fence, the complexity gets absorbed there instead. The license economy handed you a weapon; pick it up.

Fighting back: the SMB level

Small and medium businesses are where the license economy extracts the most, per capita, and where the freedom to leave is most valuable — and most neglected.

Own your customer relationships. The email list is the single most important business asset most founders under-invest in. Not your Instagram followers, not your TikTok reach, not your Shopify traffic — an owned list of customers and their consent, in a format you can export and re-import anywhere. Platforms are weather; an email list is climate.

Own your operational core. Self-host the handful of systems that would hurt most to lose. Practical picks: PostgreSQL (the most undervalued piece of software of the last two decades), Supabase self-hosted as a Firebase replacement, Mailcow or Mail-in-a-Box for email, Plausible or Umami instead of Google Analytics, n8n or Activepieces instead of Zapier for automation. An open-source CRM like EspoCRM or SuiteCRM will outlast any startup.

Use open formats religiously. CSV for tabular data, Parquet for analytics, Markdown for documents, plain SQL for queries, open API standards for everything. The test is simple: if this vendor disappeared tomorrow, could you read your data? If not, you don’t own it.

Contract for portability. Write data-export clauses and reasonable exit-assistance clauses into every vendor relationship. For critical software, ask about source code escrow. This sounds like enterprise paranoia; it is practical hygiene.

Host your own AI. For internal workflows — customer support triage, document processing, code assistance, internal search — a self-hosted model on your own hardware is frequently sufficient and keeps your operational data out of someone else’s training set. vLLM or Ollama on a single well-specced GPU server handles enormous volume. The break-even against API costs usually arrives faster than people expect.

Consider a homelab. A used 1U server from an off-lease liquidator, Proxmox on top, and a handful of containers can replace a surprising amount of SaaS for a small business. The skill involved is a moat, not a cost.

Let AI finally make “build” competitive with “buy.” For a generation, the default answer for a small business was rent the SaaS — because the developer needed to build a custom equivalent was too expensive, and the open-source alternatives lost on polish. AI collapses both sides of that equation. A founder or operations lead with a capable coding assistant can stand up a focused internal tool over a weekend that replaces two or three per-seat subscriptions, and maintain it without a full-time engineer. Open-source projects that used to lose on documentation and UX become usable because an LLM fills the gap in real time. Migration projects that used to take a quarter — exporting from one vendor, transforming the data, loading into a self-hosted replacement — take a week. The break-even between renting and owning has moved significantly in favor of ownership, if you use AI as a force multiplier for your own infrastructure rather than as another monthly bill.

Fighting back: the corporate level

Large enterprises have the buying power to bend markets, and the organizational depth to build their own alternatives. Most squander both.

Procurement as policy. Write real terms into SaaS contracts: data portability on demand, source-code escrow for anything mission-critical, SLA-backed API stability, open-standard interoperability (OIDC, SCIM, OpenTelemetry, OCI, ODBC, standard SQL dialects). Refuse contracts that penalize leaving. A hundred enterprise buyers doing this changes vendor behavior in a way a hundred consumer complaints never will.

Build what differentiates; rent what doesn’t. The classic framing, now more important than ever. If a capability is core to your strategic advantage — your models, your pricing engine, your customer intelligence — owning it outright is worth substantial overhead. If it isn’t, fine, rent it, but rent interchangeably. Multi-cloud by architecture, not by slogan.

On-prem and hybrid AI for anything sensitive. The large open-weight model families — Llama, Qwen, Mistral, DeepSeek — are good enough for the overwhelming majority of enterprise tasks when deployed with proper retrieval and guardrails. The capex to run them on your own iron is a rounding error compared to the annual contract spend most large firms now allocate to AI APIs. The returning benefit — your data does not leave your premises, ever — is increasingly a regulatory and strategic necessity.

Fund the commons. Large enterprises are the largest beneficiaries of open-source infrastructure (Linux, Postgres, Kubernetes, Python, Go, the HTTP stack) and the least proportionate contributors. Allocate engineers and dollars, systematically, to the projects you depend on. This is not philanthropy; it is securing the supply chain for your own foundation.

Cultivate depth, not just breadth. Specialists who understand how systems actually work — who can read Postgres query plans, debug network stacks, run their own Kubernetes, tune their own models — are the people who make an organization ownership-capable. A staff of vendor-certified specialists is an organization that has outsourced its capacity to leave.

Back the policy fights. Right to repair, digital markets regulation, interoperability mandates, open-model-weights policy, data-portability standards — these fights determine the shape of the next decade’s commercial terrain. Corporate policy teams that quietly support them buy their employers optionality; corporate teams that quietly oppose them are engineering their employers’ dependence.

Treat AI as an asset, not a service. The difference between AI that compounds your position and AI that erodes it comes down to a single question: at the end of the contract term, do you own more, or less? A frontier API call produces an answer and a line item. A fine-tuned open-weight model, trained on years of your proprietary data, retrieval-grounded in your own documents, deployed on infrastructure you control, produces a durable capability your competitors cannot rent from the same shelf. AI-assisted code modernization has quietly transformed the economics of paying down technical debt — the legacy systems that used to lock you into a vendor can actually get refactored now, at a tenth of the historical cost. Internal agents running against your own data, on your own infrastructure, with your own models, are strategic leverage. The same agents running against a third-party API are a forecast line item with usage-based pricing and a renegotiation date. The question for any serious enterprise is no longer whether to use AI, but whether the AI they use compounds into assets they own or costs they pay forever.

Ownership, deliberately

Here is the uncomfortable summary. Ownership used to be the default outcome of working, saving, and buying. In 2026, ownership is a deliberate, slightly effortful act. You have to notice it. You have to choose it. You have to maintain it. The frictionless default is to rent everything from a platform, including, eventually, your own cognition.

But the arithmetic still works. Every subscription canceled is a rent not paid forever. Every self-hosted service is a middleman subtracted. Every owned device, skill, model, dataset, relationship, and habit is a piece of the next economy that somebody — you, your business, your community — actually controls.

The abundance promise of AI could still be real; the only live question is whose balance sheet it lands on. Abundance built on top of a stack owned by five trillion-dollar companies, paid for by a universal subsidy routed through their balance sheets, is not abundance. It is a company town with a better marketing budget.

But abundance can also go the other way. AI is, at the same moment the license economy is using it to dismantle ownership, the single largest force multiplier for ownership that any individual, small business, or enterprise has ever had access to. The friction that used to keep self-hosting a hobby dissolves in seconds under a local model. The custom tool a small business couldn’t afford to build now takes a weekend. The vendor-locked legacy system a corporation resigned itself to paying rent on can actually be refactored, at a fraction of the historical cost. The same technology being used to dismantle the ownership economy is, on the other side of the fence, the most effective tool yet invented for reclaiming it.

The alternative to the license economy is not austerity or nostalgia. It is a deliberate ownership posture — layered into personal habits, small-business architecture, and corporate procurement — with an occasional, well-placed lawsuit at the top, for tone. Ubisoft’s engineers flipping off a switch in March 2024 was a gift. For the first time in a long time, millions of people saw, plainly, that the thing they thought they owned had been on loan the whole time.

That clarity is the beginning of the counter-move. The license economy is legible now. And the tools to build something different — cheap hardware, capable open-weight models, mature open-source stacks, a whole generation fed up enough to start caring, and, improbably, an AI that will patiently explain any of it to you at two in the morning — are sitting right there, on your desk, waiting for someone to take them seriously.

You’ll own nothing and you’ll be miserable — if you let someone else decide that for you. You don’t need permission to start owning things again. You just need to notice that it’s a choice, and that for the first time in a long time, the asymmetry runs in your favor.

Every website you visit. Every app you open. Every domain you touch. Before a single byte of content reaches you, a request goes out into the open — and someone is almost certainly watching.

Preface: The Protocol That Forgot Privacy

When the Domain Name System was designed in 1983 by Paul Mockapetris, the internet was a collegial academic network of a few hundred machines. Privacy wasn’t an afterthought — it wasn’t a thought at all. DNS was built to be fast, distributed, and resilient. It was built for a world that no longer exists.

Forty years later, DNS remains the foundational directory of the internet, handling over 620 billion queries per day globally. And for most of those queries, the privacy model is essentially unchanged from 1983: requests travel in plaintext, unencrypted, unauthenticated, and fully visible to anyone positioned between you and the resolver.

This is the story of DNS leakage — what it is, why it has gotten significantly worse as ISPs have adopted “transparency” programs, what it means for your security and privacy, and what you can actually do about it.

Part I: Understanding DNS — The Phone Book You Can’t Opt Out Of

How DNS Actually Works

When you type example.com into your browser, your computer doesn’t know where to find it. IP addresses are what machines route; domain names are what humans remember. DNS is the translation layer.

The resolution process unfolds in a chain:

1. Stub Resolver — Your OS checks its local cache. If it has a recent answer, done. If not, it forwards the query to a recursive resolver — typically one configured automatically by your ISP via DHCP.

2. Recursive Resolver — This server (usually operated by your ISP, or a public provider like 8.8.8.8) does the heavy lifting. It queries root nameservers, then Top-Level Domain (TLD) nameservers (e.g., .com), then the authoritative nameserver for the specific domain.

3. Authoritative Nameserver — Returns the actual IP address. The recursive resolver caches it and sends it back to your machine.

4. Your Browser Connects — Only now does your browser open a TCP/TLS connection to the destination.

The critical point: steps 1 through 3 are, by default, entirely unencrypted and unprotected. The query for example.com travels over UDP port 53 in plaintext.

What a DNS Query Reveals

A single DNS query contains:

• The full domain name being resolved (e.g., mail.proton.me, careers.competitor.com, therapy-finder.health)
• Your source IP address
• A transaction ID (trivially forgeable, but tracked)
• A timestamp (when correlated with resolver logs)

Your DNS history is, in many ways, more revealing than your browsing history. Browsers increasingly send HTTPS traffic everywhere, obscuring page-level content. But DNS happens before HTTPS. It reveals not just what you visited, but that you intended to visit it — even if you never completed the connection.

A week of DNS logs from a typical user can reveal:

• Medical conditions (resolving health portal domains, telehealth services)
• Financial behavior (brokerage platforms, loan services, debt management)
• Political and religious affiliations (news sources, community organizations)
• Relationship status and personal struggles (dating apps, counseling platforms)
• Professional activities (competitor research, job boards, recruiter communications)

Part II: DNS Leakage — Definitions and Mechanics

What Is a DNS Leak?

The term “DNS leak” has both a narrow technical definition and a broader practical meaning that is increasingly important.

Narrow definition: A DNS leak occurs when a device configured to use a VPN or privacy-enhancing tool continues to send DNS queries outside that protected tunnel — typically to the ISP’s default resolver — exposing browsing activity despite the user’s belief that it is protected.

Broader definition (and the one that matters more today): Any scenario in which DNS queries reach an unintended or untrusted resolver, or are logged by an intermediary without the user’s knowledge or meaningful consent.

Mechanisms of DNS Leakage

DNS leaks occur through several distinct technical pathways:

1. VPN Split-Tunneling Misconfiguration

Many VPN clients route only certain traffic through the tunnel while leaving the default route — including DNS — on the physical interface. Unless the VPN client explicitly forces DNS traffic through the tunnel and overrides the system resolver, queries escape to the ISP resolver.

2. WebRTC and Browser-Level Leaks

WebRTC, the protocol powering browser-based video and audio, can trigger DNS resolution via the operating system’s stub resolver rather than the browser’s configured resolver. Even with a VPN active, WebRTC STUN requests can leak the real local IP and trigger DNS queries on the unprotected interface.

3. IPv6 Leakage

Many VPN implementations tunnel IPv4 traffic while leaving IPv6 unprotected. If a domain resolves to an AAAA (IPv6) record and the system has IPv6 connectivity outside the tunnel, the DNS query and subsequent traffic bypass the VPN entirely. This affects a surprising number of consumer-grade VPN products.

4. NXDOMAIN Hijacking and Transparent Proxying

Some ISPs intercept all outbound UDP port 53 traffic via transparent DNS proxies — regardless of what resolver the user has configured. A user who sets their DNS to 1.1.1.1 may find their queries are silently redirected to the ISP’s own resolver without any indication that this is occurring. This is both a privacy violation and a form of DNS leak by redirection.

5. Operating System Fallback Behavior

Windows, in particular, implements a feature called “Smart Multi-Homed Name Resolution” (SMHNR), which sends DNS queries to all configured resolvers simultaneously and accepts whichever responds first. This means queries can leak to interfaces and resolvers the user has not prioritized — including ISP resolvers — even when a privacy-conscious resolver is configured.

6. Search Domain Poisoning

Corporate and home routers frequently push search domain suffixes (e.g., corp.internal) via DHCP. Poorly scoped search domain configurations can cause unqualified hostnames to be appended with unexpected suffixes and resolved externally, leaking internal naming structure to upstream resolvers.

Part III: The Rise of DNS Transparency — ISPs as Surveillance Infrastructure

From Passive Logging to Active Programs

For much of the internet’s history, ISP DNS logging was a passive, incidental byproduct of infrastructure operation. Logs were retained for short periods for debugging and abuse response. The idea of systematically using DNS data for commercial or government purposes existed, but was not widely practiced.

That has changed dramatically.

Commercial DNS Monetization

Beginning in the early 2010s — and accelerating significantly after the FCC’s 2017 rollback of broadband privacy rules in the United States — ISPs have increasingly treated DNS query data as a revenue stream.

The model works as follows:

1. Collection — All DNS queries from customers are logged at the recursive resolver level. At scale, a major ISP like Comcast, AT&T, or Verizon handles hundreds of millions of queries per day.

2. Profiling — Queries are correlated with subscriber accounts (tied to billing address, real identity) and analyzed to build behavioral profiles: interest categories, lifestyle segments, purchase intent signals.

3. Monetization — Profiles are sold to data brokers, used directly for targeted advertising, or licensed to third-party analytics firms.

Verizon’s “Relevant Mobile Advertising” program, AT&T’s “Internet Preferences” program, and similar initiatives by Comcast have all used or proposed using browsing and DNS data for advertising purposes. The legal basis varies by jurisdiction, and opt-out mechanisms — when they exist — are often buried in terms of service.

Government-Mandated DNS Logging and “Lawful Transparency”

Beyond commercial monetization, a parallel trend has emerged: government-mandated DNS logging under the guise of security or legal compliance.

United Kingdom — Investigatory Powers Act (2016)
Often called the “Snoopers’ Charter,” this legislation requires ISPs to retain “Internet Connection Records” — which include DNS query logs — for 12 months and make them accessible to a wide range of government agencies without requiring a judicial warrant.

Australia — Telecommunications (Interception and Access) Act
Australia’s metadata retention scheme requires telecommunications providers to retain metadata including destination IP addresses and connection logs for two years. DNS data falls within scope.

European Union — Network and Information Security Directive (NIS2)
While framed around cybersecurity, NIS2 and related EU DNS4EU initiatives push for centralized DNS infrastructure that provides governments with visibility into DNS traffic for “threat intelligence” purposes. The line between security monitoring and surveillance is, charitably, blurry.

United States — NSA/PRISM Era and Beyond
Edward Snowden’s 2013 disclosures revealed that the NSA operated programs collecting DNS query data at scale through programs like MUSCULAR, which tapped directly into the backbone links between data centers. Post-Snowden reforms were narrow; bulk collection of metadata — including DNS — remains legally permissible under authorities like EO 12333.

Russia, China, Turkey, and Others
Authoritarian states have gone furthest, implementing DNS-level filtering, mandatory resolution through state-controlled resolvers, and systematic logging of all DNS traffic as a matter of official policy. Russia’s RuNet isolation architecture and China’s Great Firewall both operate substantially through DNS interception and manipulation.

The “Transparency” Framing Problem

The term “DNS transparency” has been co-opted in a way that deserves scrutiny. In cryptography and protocol design, “transparency” is a positive property — it means operations are auditable and verifiable. Certificate Transparency (CT), for example, is genuinely good: it creates a public, append-only log of issued TLS certificates that enables detection of misissued certificates.

But “DNS transparency” in the ISP context means something different and more troubling: it means that your DNS queries are transparent to the ISPs — not transparent to you in any auditable sense. It is surveillance wearing the clothing of an engineering virtue.

Part IV: The Security and Privacy Risk Landscape

Threat Model: Who Are You Protecting Against?

Understanding DNS leakage risks requires clarity about threat actors. These are not equivalent:

Most users face meaningful exposure in several of these categories simultaneously.

Attack Vectors Enabled by DNS Leakage

DNS Cache Poisoning

An attacker who can observe a DNS query — its transaction ID and source port — can race to inject a forged response before the legitimate reply arrives. A poisoned cache entry redirects all users of that resolver to an attacker-controlled IP. In 2008, Dan Kaminsky’s discovery of a fundamental DNS cache poisoning vulnerability triggered a global emergency patch cycle affecting virtually every DNS implementation. The underlying protocol weakness — no cryptographic authentication of responses — remains in plain DNS.

DNS Hijacking for Credential Harvesting

By poisoning a resolver’s cache for bank.example.com, an attacker serves a convincing phishing page at the correct URL. Because the domain resolves to the wrong IP, HTTPS certificate warnings may (or may not) appear depending on whether the attacker has obtained a certificate. Lack of DNSSEC validation makes this attack easier.

DNS Tunneling for Data Exfiltration

Malware and attackers can use DNS as a covert channel to exfiltrate data or receive command-and-control instructions, encoding data in subdomain names (c29tZS1kYXRh.evil.com). Because DNS traffic is frequently allowed through firewalls that block other protocols, this technique is disturbingly effective. Organizations that log and analyze DNS can detect anomalous query patterns; those that don’t are blind to this vector.

ISP NXDOMAIN Hijacking

Rather than returning a proper NXDOMAIN response for non-existent domains, many ISPs hijack these responses to serve ad-laden “search” pages. Beyond the obvious annoyance, this behavior:

• Breaks software that relies on NXDOMAIN responses for service discovery
• Creates a vector for phishing (users may click links on the “search” page)
• Leaks even failed resolution attempts to the ISP’s advertising infrastructure

Timing and Correlation Attacks

Even without reading query content, an observer can correlate the timing and frequency of DNS queries against known patterns. When does a journalist resolve domains associated with a particular whistleblower platform? When does an employee resolve a competitor’s job application portal? These correlations are actionable even in the absence of content.

OSINT and Deanonymization

Researchers, law enforcement, and malicious actors routinely use passive DNS databases — repositories of historical DNS query/response pairs — to map infrastructure, track threat actors, and identify relationships between domains and IP addresses. Data contributed to these databases often comes from ISP resolver logs (sold or leaked) and from compromised resolvers.

Real-World Consequences

These risks are not theoretical:

• Kazakhstan (2019): The government mandated that all internet users install a state-issued “security certificate” — effectively a root CA — enabling man-in-the-middle attacks on all HTTPS traffic, with DNS as the entry point for traffic interception.
• Turkey (2014, 2022): The Turkish government repeatedly ordered ISPs to block Twitter and other services via DNS hijacking, demonstrating how DNS control translates directly to censorship capability.
• US ISP DNS Sale (2017): Following the FCC rule rollback, multiple major US ISPs publicly announced or quietly implemented programs to monetize DNS and browsing data.
• BGP/DNS Hijacking of MyEtherWallet (2018): Attackers hijacked BGP routes for AWS DNS servers, redirecting MyEtherWallet users to a phishing site, stealing approximately $150,000 in cryptocurrency in under two hours.

Part V: The Technical Countermeasures

1. DNS over HTTPS (DoH)

DoH encapsulates DNS queries within HTTPS connections — the same protocol used for ordinary web traffic. Queries travel encrypted to a DoH-capable resolver, indistinguishable from regular HTTPS traffic.

Advantages:

• Queries are encrypted in transit; ISPs and network observers cannot read query content
• Traffic is encrypted from the system to the resolver, preventing MITM
• Blends with normal HTTPS traffic, making it difficult to block without collateral damage
• Supported natively in Firefox, Chrome, Edge, and Windows 11

Limitations:

• Shifts trust from the ISP to the DoH resolver (Cloudflare, Google, NextDNS, etc.) — you must trust whoever operates it
• Does not prevent the resolver from logging queries
• Can be blocked by deep packet inspection if the resolver’s IP is known and blocked
• Does not protect against a malicious or compromised DoH resolver

Implementation:

# Example: systemd-resolved with DoT (Linux)
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes

# Firefox: about:config
network.trr.mode = 2  # DoH preferred, fallback to system
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query

2. DNS over TLS (DoT)

DoT encrypts DNS queries within a TLS connection on a dedicated port (TCP 853). Unlike DoH, it uses a distinct port, making it identifiable — and blockable — by network operators.

Advantages:

• Strong encryption with TLS; resistant to eavesdropping
• Clear separation of concerns (port 853 is exclusively DNS)
• Easier to audit and control at the network level

Limitations:

• Port 853 is frequently blocked by corporate firewalls and in restrictive network environments
• More easily distinguishable and blockable than DoH
• Same resolver-trust problem as DoH

3. DNS over QUIC (DoQ)

DoQ carries DNS over the QUIC transport protocol, which offers TLS 1.3 encryption, reduced connection latency (0-RTT handshakes), and multiplexing without head-of-line blocking.

Advantages:

• Encrypted (TLS 1.3 minimum)
• Lower latency than DoT (no TCP handshake overhead)
• Resilient to packet loss

Limitations:

• Nascent ecosystem; limited resolver and client support as of 2025
• QUIC’s UDP-based transport is increasingly throttled or blocked on some networks

4. DNSSEC

DNSSEC adds cryptographic signatures to DNS records, enabling resolvers to verify that responses are authentic and unmodified. It does not encrypt queries — it provides integrity, not confidentiality.

What DNSSEC solves:

• Cache poisoning (forged responses are rejected if signatures don’t validate)
• DNS hijacking by intermediate resolvers (response integrity is verifiable)

What DNSSEC does not solve:

• Eavesdropping (queries are still plaintext)
• Malicious-but-legitimate resolvers (they can still log what they receive)
• ISP surveillance

Deployment gap: Despite being standardized since the early 2000s, DNSSEC adoption remains incomplete. Approximately 40% of global DNS traffic is DNSSEC-validated as of 2024, but many domains still lack DNSSEC signatures, and many resolvers skip validation.

5. Oblivious DNS over HTTPS (ODoH)

ODoH is an elegant cryptographic protocol that separates knowledge of who is asking from knowledge of what is being asked by introducing an untrusted proxy:

1. The client encrypts the DNS query with the resolver’s public key
2. The encrypted query is sent to an ODoH Proxy — a separate entity that knows the client’s IP but cannot read the query
3. The proxy forwards it to the ODoH Resolver, which can read the query but sees only the proxy’s IP, not the client’s
4. The response is encrypted back through the chain

The key property: No single entity knows both who is asking and what they are asking. Even a colluding proxy and resolver cannot reconstruct the full picture unless they share logs — which the protocol is designed to make difficult to hide.

Current state: Cloudflare operates an ODoH service. Adoption is growing but remains limited to privacy-focused applications and technically sophisticated users.

6. Encrypted Client Hello (ECH) — The Missing Piece

Even with DoH protecting DNS queries, a subtle privacy leak remains: the TLS Server Name Indication (SNI) field. When your browser opens an HTTPS connection, it sends the target domain name in plaintext in the TLS ClientHello message — so that servers hosting multiple domains know which certificate to present.

SNI is visible to network observers even when DNS is encrypted. An ISP cannot read the query, but can read the TLS handshake.

ECH (formerly ESNI) encrypts the SNI field using a public key published in the domain’s DNS record (requiring HTTPS DNS record types and DNSSEC). When combined with DoH:

• DNS query: encrypted via DoH ✓
• TLS handshake SNI: encrypted via ECH ✓
• The resulting traffic reveals the outer domain (typically a CDN like Cloudflare) but not the actual destination ✓

ECH is supported in Firefox, Chrome (behind a flag), and Cloudflare’s infrastructure. Full ecosystem deployment is ongoing.

7. Running Your Own Recursive Resolver

For advanced users, running a local recursive resolver eliminates dependence on a third-party resolver for confidentiality:

Options:

• Unbound — Widely-used, high-performance validating resolver with DNSSEC support
• Pi-hole + Unbound — Network-wide DNS filtering with local recursive resolution
• BIND 9 — The reference implementation, powerful but complex

What this achieves: Queries leave your machine and go directly to authoritative servers (root → TLD → authoritative), bypassing your ISP’s resolver entirely. Your ISP still sees the destination IPs of DNS traffic but not the query content if you use DoT/DoH for the upstream leg.

What this doesn’t achieve: Queries to authoritative nameservers are still in plaintext. Each authoritative server you contact sees your IP. For most threat models, this is acceptable; for high-sensitivity use cases, combine with Tor or ODoH.

# Unbound local resolver config snippet (/etc/unbound/unbound.conf)
server:
    verbosity: 1
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    do-ip6: no

    # DNSSEC validation
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # Harden against cache poisoning
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes   # 0x20 encoding randomization

    # Reduce attack surface
    hide-identity: yes
    hide-version: yes

    # Cache settings
    cache-min-ttl: 3600
    cache-max-ttl: 86400
    prefetch: yes

8. VPN with DNS Leak Protection

If using a VPN, verify that:

1. DNS requests are routed through the VPN tunnel — Not split-tunneled or sent to the local network’s resolver
2. Kill switch is enabled — Drops internet traffic if the VPN disconnects, preventing leak exposure during reconnection
3. IPv6 is disabled or tunneled — Prevents IPv6 DNS leakage
4. WebRTC is disabled in browser settings — Prevents browser-level IP and DNS leaks

Countermeasure Effectiveness Summary

Not all countermeasures defend against the same threat. DNS leakage (queries escaping a protected tunnel), ISP DNS transparency (systematic resolver-level surveillance), and TLS handshake leakage (the SNI field exposing your destination even after DNS is encrypted) are distinct problems that require distinct solutions. DNSSEC stands apart entirely — it provides cryptographic response integrity, not confidentiality, and belongs to a different layer of the privacy stack. Critically, DoH and ECH are complementary, not redundant: DoH encrypts the DNS query, ECH encrypts the TLS handshake that follows it. A network observer blocked by DoH can still read SNI in plaintext without ECH — and vice versa. Both are required to prevent destination reconstruction from network traffic.

Verification tools:

• dnsleaktest.com — Tests which resolver(s) your queries reach
• ipleak.net — Comprehensive IP, DNS, and WebRTC leak test
• browserleaks.com — Detailed browser fingerprint and leak analysis

Important caveat: A VPN shifts the trust relationship from your ISP to your VPN provider. If your VPN provider logs DNS queries (many do, despite “no-log” marketing claims), you have not meaningfully improved your privacy — you’ve merely changed who is surveilling you. Verify VPN providers through independent audits, not marketing materials.

Part VI: Choosing a Resolver — The Trust Trade-Off

If you cannot (or choose not to) run your own recursive resolver, you must place trust in a third-party resolver. This is unavoidable — the question is who you trust and on what basis.

Recommendation framework:

• Default privacy: Cloudflare 1.1.1.1 with DoH/DoT — well-audited, fast, established no-logging commitment
• Non-profit preference: Quad9 9.9.9.9 — non-profit operator, malware blocking, strong privacy stance
• Maximum control: Self-hosted Unbound with Cloudflare or Quad9 as upstream DoT/DoH forwarder
• Maximum privacy: ODoH via Cloudflare + Fastly proxy partnership

Part VII: Organizational and Enterprise Considerations

DNS privacy is not only a personal concern. Organizations face distinct DNS-related security risks:

Internal DNS Leakage

Corporate devices configured with split-DNS (internal domains resolved locally, public domains via ISP) frequently leak internal DNS structure when employees work remotely. Queries for internal.corp.example.com may reach public resolvers, exposing organizational structure, application names, and internal service topology.

Mitigation: Enforce VPN-based DNS resolution for all corporate devices when outside the office network; use DNSSEC-signed internal zones; monitor for anomalous query patterns.

DNS as an Exfiltration Channel

Attackers who have compromised internal systems routinely use DNS tunneling to exfiltrate data, since port 53 is almost universally permitted through firewalls. Each query to an attacker-controlled authoritative server carries a small payload of exfiltrated data in the subdomain label.

Detection signals:

• Abnormally long subdomain labels (> 50 characters)
• High query rates to a single second-level domain
• High entropy in subdomain strings (base64/hex encoded data)
• Queries for non-existent domains following a pattern

Mitigation: DNS traffic analysis (Zeek/Bro, Cisco Umbrella, Infoblox BloxOne); RPZ (Response Policy Zones) to block known malicious domains; anomaly detection on query volumes.

Third-Party Resolver Risk for Organizations

Large organizations that outsource DNS resolution to cloud providers (Google, Cloudflare, AWS Route 53 Resolver) are exposing their full query profile to those providers. This includes competitive intelligence signals, merger and acquisition research activity, and partner relationship data visible in DNS patterns.

Part VIII: A Practical Prevention Checklist

For Individual Users

• Enable DoH or DoT in your operating system and/or browser, pointed at a trustworthy resolver
• Verify your VPN doesn’t leak DNS using dnsleaktest.com
• Disable WebRTC in Firefox (media.peerconnection.enabled = false in about:config) or use a WebRTC control extension in Chrome
• Disable IPv6 if your VPN doesn’t tunnel it, or verify your VPN client handles it correctly
• Enable ECH in Firefox (enabled by default in recent versions) and Chrome (via chrome://flags)
• Consider Pi-hole + Unbound for network-wide encrypted recursive resolution
• Audit your router’s DNS settings — many home routers ignore client-configured DNS and forward everything to the ISP resolver
• Use a VPN provider with independently audited no-logging — look for audits, not marketing claims
• Run a DNS leak test periodically, especially after VPN updates or OS upgrades

For Developers and System Administrators

• Sign your domains with DNSSEC — protects users of your services from spoofing
• Publish HTTPS DNS records with ECH public keys for your domains
• Monitor your organization’s DNS traffic for exfiltration patterns
• Implement RPZ filtering to block known malicious resolver responses
• Audit split-DNS configurations for internal domain leakage
• Use DNS over TLS for upstream resolver communication in Unbound/BIND configurations
• Log and alert on high-entropy subdomain queries as a DNS tunneling detection signal

Conclusion: The Quiet Infrastructure of Surveillance

DNS was designed in a different world, and it shows. Every day, billions of people trust a 40-year-old unauthenticated plaintext protocol with some of their most sensitive behavioral data, with virtually no indication that this is happening and no meaningful ability to opt out of the default.

The rise of ISP DNS transparency programs — dressed in the language of security and operational necessity — has transformed this incidental exposure into systematic commercial and governmental surveillance infrastructure. The logs exist. They are retained. They are analyzed, sold, and compelled by subpoena. The query you sent three years ago asking about a health condition, a competitor, a legal resource, or a dissident journalist is, in many cases, still sitting in a database somewhere.

The tools to change this exist. DoH, DoT, ODoH, ECH, DNSSEC, self-hosted resolvers — these are not exotic technologies. They are increasingly built into the browsers and operating systems you already use. The friction between “exposed by default” and “protected with intentional configuration” has never been lower.

The internet’s directory doesn’t have to be an open book. But closing it requires understanding that it’s open in the first place.

Anthropic’s disclosure today about Claude Mythos Preview is not a product announcement. It is a civilizational inflection point for computer security — one that demands a frank assessment of what has changed, what it means for defenders and attackers alike, and what the industry must do immediately.

Critical Finding: Mythos Preview autonomously identifies and fully exploits zero-day vulnerabilities across every major operating system and every major web browser — including a 27-year-old OpenBSD bug, a 17-year-old FreeBSD remote root exploit, and multiple chained Linux kernel privilege escalation chains — all without human intervention after a single prompt.

The Quantitative Leap Is Real

The security community is accustomed to incremental improvements in tooling. What Anthropic describes with Mythos Preview is not incremental. The numbers tell a stark story:

To understand why the 181× figure matters, you need context. Opus 4.6 — itself a frontier model — succeeded in generating Firefox shell exploits only twice in hundreds of attempts. Mythos Preview succeeded 181 times on the same corpus. This is not a marginal improvement. It is a phase transition.

The tier-5 OSS-Fuzz result is equally significant. Reaching full control-flow hijack on a hardened, fully-patched target requires more than finding a bug — it requires constructing a working exploit chain against active mitigations. Mythos Preview did this ten times, on ten independent targets, in a single automated pass. Prior frontier models achieved it once each.

“Engineers at Anthropic with no formal security training asked Mythos Preview to find remote code execution vulnerabilities overnight, and woke up the following morning to a complete, working exploit.”

That sentence deserves to sit on its own. The democratization of offensive capability is no longer theoretical.

Three Findings That Define the Moment

The report documents dozens of vulnerabilities. Three deserve specific attention from a research perspective, as they reveal qualitatively different capability dimensions.

OpenBSD TCP SACK — signed integer overflow leading to null-pointer dereference

Age: 27 years | Impact: Remote denial-of-service

The vulnerability requires Mythos Preview to simultaneously reason about two interacting bugs: an unchecked lower-bound on SACK block start values, and a conditional append path that relies on a pointer the first bug can implicitly free. Neither bug is exploitable alone. Finding the interaction requires holding the full TCP SACK state machine in mind while reading C — a task that demands genuine semantic understanding of protocol semantics, not pattern matching.

This is the hardest category of bug to find by fuzzing: no memory sanitizer fires, no crash occurs on typical inputs, and the dangerous condition requires a specific two-field relationship across two packets. The model found it in under $50 of compute. A thousand-run campaign across the entire OpenBSD codebase cost under $20,000.

CVE-2026-4747 — FreeBSD NFS remote code execution

Age: 17 years | Impact: Unauthenticated remote root

This is the most operationally significant finding in the disclosure. An unauthenticated remote attacker can gain full root on any internet-exposed FreeBSD NFS server. Mythos Preview not only found the 96-byte stack overflow in the RPCSEC_GSS authentication handler — it independently identified that the standard -fstack-protector flag was insufficient (the buffer is declared as int32_t[32], not a char array, so no stack canary is emitted), resolved the handle authentication challenge using an NFSv4 EXCHANGE_ID information disclosure as a side channel, and wrote a 20-gadget ROP chain split across six sequential packets to fit within the overflow budget. The entire discovery-to-exploit pipeline required zero human guidance after an initial prompt.

Linux kernel — multi-vulnerability chain (KASLR bypass + arbitrary write → root)

Impact: Local privilege escalation via autonomous multi-step exploit chaining

The Linux exploit chains demonstrate the most alarming capability of all: autonomous multi-step reasoning across vulnerability classes. Mythos Preview independently identified that a given write primitive was blind without a KASLR bypass, independently identified a separate read vulnerability to serve that purpose, and chained them — sometimes alongside a third or fourth vulnerability — into a working root exploit.

The documented ipset bitmap chain is particularly impressive: exploiting a one-bit OOB write to flip _PAGE_RW in a physically-adjacent page table entry, enabling a writable shared mapping of /usr/bin/passwd, requires precisely sequenced SLUB heap grooming across the SLUB, PCP freelist, and buddy allocator. This is graduate-level kernel exploitation. It took the model under a day and under $1,000.

The Capability Trajectory Is the Real Story

The individual findings, alarming as they are, are not the primary message. The trajectory is. Anthropic’s own red team wrote just last month that “Opus 4.6 is currently far better at identifying and fixing vulnerabilities than at exploiting them.” Their internal evaluations showed Opus 4.6 had near-zero autonomous exploit success rates. Mythos Preview, released weeks later, demolishes those benchmarks.

~12 months ago: Frontier models cannot identify non-trivial vulnerabilities autonomously. Benchmarks show 0% success on tier-3+ crash severity against patched OSS-Fuzz targets.

~6 months ago: Models begin finding real vulnerabilities. Opus 4.6 sends 112 confirmed true-positive bugs to Mozilla. Exploit capability remains near-zero — findings require human operators to develop into PoC exploits.

Last month: Opus 4.6 achieves two Firefox exploits in hundreds of attempts. Independent researchers demonstrate it can exploit a known CVE with significant human prompting.

Today: Mythos Preview: 181 Firefox exploits. 10 tier-5 OSS-Fuzz hijacks. Autonomous zero-day discovery and full exploit chain construction. 27-year-old, 17-year-old, 16-year-old bugs found and weaponized overnight.

Don’t bank on a plateau

Some in the security community have begun voicing a quiet hope: that LLM capability gains will plateau before they become truly dangerous, buying the industry time to adapt. This is not a plan. It is a wish dressed up as a forecast.

There is no principled technical basis for expecting a capability ceiling in the near term. The improvements that produced Mythos Preview — general advances in reasoning, code understanding, and autonomous tool use — are not nearing exhaustion. And crucially, the security capabilities described here were not explicitly trained; they emerged as a downstream consequence of general improvements. That means they will continue to improve in step with general model quality, whether labs intend it or not.

Planning enterprise security strategy around an expected plateau is a category error in risk management. You do not design a building’s fire suppression system around a hope that fires will become less common. You design it to handle the fires you can document today, while acknowledging that the threat may worsen. The documented threat, as of today, is substantial.

If this rate of capability gain continues — and there is no principled reason to believe it will not — the industry has between months and a small number of years before models with Mythos-class capabilities become broadly accessible through public APIs. Anthropic is responsibly restricting access for now. Others will not apply the same judgment.

What Is Genuinely New

The security community has heard “AI will change security” for years. It is worth being precise about what has actually changed with Mythos Preview versus prior claims:

A Note on Scope and Honesty

Anthropic cannot disclose 99% of what they found. Their responsible disclosure process means that only bugs already patched can be discussed publicly. The FreeBSD RCE, the OpenBSD SACK crash, and three FFmpeg vulnerabilities are the tip. They commit to SHA-3 hashes of dozens more reports — browser exploit chains, VMM guest-to-host corruption, Linux kernel logic bugs, cryptographic library authentication bypasses — none yet public. What we are reading about is deliberately the least dangerous slice of the findings.

The cryptographic commitment scheme they use (SHA-3 pre-image resistance to prove possession without disclosure) is a thoughtful approach to accountability under responsible disclosure constraints. It allows the research community to verify later that the claims made today are honest, without prematurely releasing exploits for unpatched systems. This is good practice.

The disclosure also appropriately acknowledges uncertainty: they note that Mythos Preview sometimes references previously published exploitation walkthroughs for known CVEs, which partially confounds novelty claims in the N-day section. They address this honestly, and limit novelty claims to their zero-day findings where no such contamination is possible.

The Asymmetry Problem — and Why Defenders Have Less Time Than They Think

Anthropic makes an important historical analogy to fuzzing. When AFL and libFuzzer emerged, there were similar concerns about attacker uplift. Those tools did benefit attackers initially — and then became foundational defensive infrastructure through OSS-Fuzz and similar programs. The argument is that LLMs will follow the same arc.

The analogy holds, but with a crucial difference in time horizons. Fuzzing’s attacker uplift period was measured in years, during which defenders could adapt. The N-day exploit result in this paper — CVE to working exploit in hours, fully autonomously, for under $2,000 — compresses a timeline that the security industry’s entire patch-to-deploy infrastructure is not built to handle.

Structural Risk: Current enterprise patch SLAs range from days to months depending on criticality. The gap between public CVE disclosure and deployed patches for widely-used infrastructure software is often measured in weeks. Mythos Preview closes that window to hours. Every day of patch lag that organizations accept as routine is now a window in which autonomous exploitation is feasible — at scale, cheaply, and without requiring specialized human expertise.

On the Idea That Visible Catastrophe Would Be Clarifying

A tempting but dangerous line of thinking holds that a sufficiently visible failure — a major infrastructure compromise, a cascading breach of critical systems — might function as a forcing mechanism, finally compelling the industry and policymakers to take coordinated action. The logic has a certain grim appeal: perhaps only a concrete demonstration of harm will create the political will to act.

This argument should be rejected, firmly and specifically.

The first problem is that “visible harm” in the context of autonomous cyber exploitation does not look like a controlled demonstration. It looks like hospitals losing access to patient records, power grids failing in winter, financial settlement systems going dark. The costs of these failures fall disproportionately on people who have no agency over the security decisions that caused them — patients, civilians, people who depend on digital infrastructure they cannot audit or improve. A catastrophic breach does not generate clean political lessons; it generates chaos, attribution disputes, and often a security response that trades civil liberties for speed.

The second problem is historical: the security industry has had visible catastrophes. WannaCry. NotPetya. The Colonial Pipeline ransomware. SolarWinds. Each was genuinely alarming. Each generated op-eds and congressional hearings. None produced the systematic, structural change that the moment seemed to demand. There is little reason to believe that an AI-enabled equivalent would be different — and considerable reason to believe the scale of harm would be larger.

The right model is not to wait for a catastrophe that finally forces action. It is to treat the published evidence as sufficient grounds for action now, before the catastrophe, while the window to act proactively remains open.

Immediate Recommendations for Defenders

01 — Deploy current frontier models for vulnerability discovery now. Opus 4.6 and equivalent models already find high- and critical-severity vulnerabilities systematically. Projects without LLM-assisted vulnerability scanning are leaving known bugs on the table. Set up the scaffolding today — the marginal cost is low and the defensive value is immediate.

02 — Treat patch lag as the primary risk surface. Reduce time-to-deploy for security patches to as close to zero as operationally feasible. Enable automatic updates wherever possible. CVE-to-exploit timelines are now measured in hours for a well-resourced attacker. Dependency bumps carrying CVE fixes are not routine maintenance — they are urgent security responses.

03 — Re-evaluate friction-based mitigations. Many defense-in-depth measures work by making exploitation tedious rather than impossible — stack canaries, ASLR, partial RELRO. Mythos Preview grinds through this tedium systematically and at scale. The FreeBSD exploit is a clear example: what an attacker would have needed days to work through, the model handled in hours. Mitigations that impose hard cryptographic or architectural barriers (W^X, CFI, memory-safe rewrites) remain valuable. Friction-only measures need honest re-evaluation.

04 — Assume legacy codebases have undiscovered critical vulnerabilities. The 27-year OpenBSD bug, the 17-year FreeBSD bug, and the 16-year FFmpeg bug were all in heavily-audited, well-fuzzed codebases. If Mythos Preview can find these, similar bugs almost certainly exist in less scrutinized legacy systems. The question is not whether your critical infrastructure has undiscovered vulnerabilities — it does. The question is who finds them first.

05 — Automate incident response triage now. If vulnerability discovery and exploit development can be automated, so must early-stage incident response. Detection, alert triage, and preliminary root-cause analysis need model assistance. The volume of security events is about to increase dramatically; organizations cannot staff their way through it.

06 — Revisit vulnerability disclosure policies for scale. Coordinated vulnerability disclosure was designed for a world where a skilled researcher might find a handful of critical bugs per year. Mythos Preview found thousands of high- and critical-severity vulnerabilities in weeks. Disclosure pipelines, maintainer bandwidth, and legal frameworks are not built for this volume. The industry needs new infrastructure.

The Uncomfortable Conclusion

Anthropic ends their report with a reference to Linus’s Law: “Given enough eyeballs, all bugs are shallow.” The point is that language models now provide essentially unlimited eyeballs — tireless, systematic, and increasingly capable of not just finding bugs but exploiting them.

There is a version of this story with a good ending. Mythos Preview, used defensively through Project Glasswing and similar programs, could harden critical infrastructure faster than any previous technology. The same capability that writes a 20-gadget ROP chain can write patches, review pull requests, and find vulnerabilities before they ship. In the long run, defenders who effectively deploy these tools should gain a decisive advantage — they have more code to protect, but they also have more resources, more time, and more legitimate access to the systems they’re defending.

But the transitional period is the problem. The asymmetry between what Mythos Preview can do today and what most organizations’ defenses assume is vast and widening. The model is not publicly available — yet. Models with equivalent capability, trained by other labs with less careful release policies, will be.

The transition will not be clarified by a collapse. It will be navigated — or not — by the decisions organizations and policymakers make in the next few months, largely in the absence of a crisis to concentrate their attention. That is precisely what makes this moment difficult, and precisely what makes early action indispensable.

The security community spent twenty years building an equilibrium. We have perhaps months to prepare for a new one. The question is not whether to act — it is whether we will act at the scale the moment demands.

Project Glasswing is a serious and thoughtful response to an unprecedented situation. The commitments Anthropic makes — cryptographic disclosure, coordinated patching, restricted access — are the right ones. But responsible stewardship from one lab cannot substitute for industry-wide preparation. The capabilities described today are not theoretical. They are running. They are finding vulnerabilities in every major operating system, every major browser, and some of the most trusted cryptographic libraries in the world.

The time to build the scaffolding, train the teams, update the patch pipelines, and rethink the threat model is now — before these capabilities are broadly accessible. That window may be shorter than anyone is comfortable admitting.

Introduction: The Trust Trap

There’s a thought experiment worth sitting with before reading further: how many lines of code are you actually running right now? On your development machine, across your CI/CD pipelines, in your production services?

The answer — when you account for every transitive dependency — is almost certainly in the tens of millions. And you’ve reviewed, at best, a few thousand of those lines yourself.

That gap is where supply chain attacks live.

Unlike a direct breach — where an adversary tries to crack your perimeter, phish your employees, or exploit a misconfigured server — a supply chain attack doesn’t need to target you at all. Instead, it targets the shared infrastructure of trust that the entire software ecosystem depends on: open-source packages, CI/CD tooling, build pipelines, and registry systems. When an attacker compromises a dependency you use, they don’t need to get past your defenses. You invited them in.

This article examines three supply chain attacks in increasing order of sophistication and ambition: xz Utils (2024), LiteLLM (March 2026), and Axios (March 2026). After dissecting how each worked, we’ll make the case — backed by technical reality — that these attacks are not isolated incidents but the opening act of a new era in which LLMs dramatically lower the barrier to discovering and exploiting supply chain vulnerabilities at scale.

Part I: A Taxonomy of Trust

Software supply chain attacks are not new. The term itself entered mainstream security discourse after the SolarWinds breach of 2020, where a nation-state actor inserted a backdoor into the build system of a widely-used IT monitoring product, silently compromising thousands of organizations — including multiple US federal agencies — for months. But the pattern has evolved rapidly.

Modern supply chain attacks generally fall into a few categories:

Account takeover attacks target the credentials of trusted package maintainers, using compromised accounts to publish malicious versions directly to registries like PyPI or npm. Once published, those versions are indistinguishable from legitimate releases — because they come from the legitimate account.

Dependency confusion attacks exploit the way package managers resolve names across private and public registries, tricking build systems into downloading attacker-controlled packages that share names with internal ones.

Upstream compromise goes deeper, inserting malicious code into the source repository or CI/CD pipeline of a legitimate project so that the attack is baked into the official release artifact.

Social engineering of maintainers — the most patient form — involves cultivating trust with open-source maintainers over months or years before being granted enough access to introduce a backdoor directly into the codebase.

The xz Utils attack is the definitive example of this last category. It nearly worked.

Part II: The xz Utils Attack (2024) — The Long Game

Background

In late March 2024, Microsoft engineer Andres Freund was investigating unusual SSH latency on a Debian system and noticed that the sshd process was consuming abnormally high CPU. Following the thread led him to something extraordinary: a backdoor in xz Utils, a ubiquitous data compression library present on virtually every Linux distribution in the world.

The backdoor hadn’t been injected by a hacker who had momentarily breached the project. It had been planted by Jia Tan, a contributor who had spent approximately two years building trust with the xz Utils maintainer before being granted commit access.

The Attack in Detail

Beginning in 2022, an account registered as JiaT75 began contributing high-quality patches to the xz Utils project. The maintainer, Lasse Collin, who had been under social pressure from what appeared to be a coordinated campaign of fake user accounts pushing him to add new contributors, eventually gave Jia Tan co-maintainer access.

In early 2024, Jia Tan modified the project’s build system in a subtle way: a malicious macro was embedded in files distributed with the source tarball but not present in the Git repository itself. This is a crucial detail — most automated security scanners check the repository, not the distributed tarball. The macro only activated under specific conditions: Debian and RPM-based Linux distributions, x86-64 architecture, and only at install time. This was not a broad credential sweeper. It was a targeted surgical payload.

The backdoor was designed to intercept RSA key operations in OpenSSH (via a patched version of systemd that linked against the compromised liblzma) and allow the attacker to authenticate without a valid key — essentially, a skeleton key for SSH on any vulnerable system.

Had this reached stable versions of Debian, Fedora, and Ubuntu in production, the blast radius would have been staggering. Freund’s chance discovery — driven by curiosity about a few hundred milliseconds of latency — was one of the closest calls in open-source security history.

Why It Almost Worked

• Patience: The two-year timeline meant there was no anomalous spike of activity to flag.
• Quality: Jia Tan’s legitimate contributions were good. The account passed every human review.
• Stealth: The payload was split across the tarball and the build system, making it invisible to standard repository auditing.
• Targeting: It specifically avoided activating in environments where security researchers are likely to run it.
• State-level resources: Most analysts assess this as a nation-state operation. The level of planning and the specific target (SSH authentication) point to intelligence collection, not financial crime.

Part III: The LiteLLM Attack (March 24, 2026) — The AI Infrastructure Heist

If xz was about patience, the LiteLLM compromise was about precision targeting.

Background: Why LiteLLM Matters

LiteLLM is a Python library and proxy server that provides a unified interface to over 100 LLM providers — OpenAI, Anthropic, AWS Bedrock, Google Vertex AI, and many more. It is most often used by developers as a gateway for client applications to call any number of large language models from over 100 providers. It handles API keys for all of those providers simultaneously. Architecturally, it occupies the most credential-rich position imaginable in an AI-native stack.

LiteLLM’s PyPI package has about 480 million downloads, making it a very valuable target.

The Attack Chain

The breach of LiteLLM was not a direct attack — it was the third domino in a multi-step cascade orchestrated by a threat group now tracked as TeamPCP.

Stage 1 — Trivy (March 19): TeamPCP rewrote Git tags in the trivy-action GitHub Action repository to point to a malicious release carrying a credential-harvesting payload. Trivy is a popular open-source vulnerability scanner. Critically, LiteLLM’s CI/CD pipeline ran Trivy as part of its build process, pulling it from apt without a pinned version. The compromised action exfiltrated the PYPI_PUBLISH token from the GitHub Actions runner environment.

Stage 2 — Checkmarx KICS (March 23): The same infrastructure was used to compromise Checkmarx KICS (Keep Infrastructure as Code Secure), another security scanning tool, registering the impersonator domain checkmarx.zone.

Stage 3 — LiteLLM (March 24): With the stolen PyPI token, the attackers published two malicious LiteLLM versions: 1.82.7 and 1.82.8. These compromised versions appeared to have included a credential stealer designed to encrypt and exfiltrate data via a POST request to models.litellm.cloud, which is not an official BerriAI/LiteLLM domain.

The Payload

The malware was technically sophisticated in several ways.

The collected data was encrypted with a hardcoded 4096-bit RSA public key using AES-256-CBC (random session key, encrypted with the RSA key), bundled into a tar archive, and POSTed to https://models.litellm.cloud/ — a domain that is not part of legitimate litellm infrastructure.

Version 1.82.8 introduced an especially nasty delivery mechanism: a .pth file. As ARMO’s analysis explains, Python’s .pth files are processed by the site module during interpreter startup — without any import statement required. The result was that any Python process on an affected system would trigger the malware, not just processes importing LiteLLM. This created an accidental fork bomb: the spawned child process re-triggered the .pth file, causing exponential process creation that crashed machines with OOM errors. This was actually how the attack was first discovered — a developer noticed their machine ran out of RAM.

If a Kubernetes service account token was present, the malware read all cluster secrets across all namespaces and attempted to create a privileged Alpine pod on every node in kube-system, mounting the host filesystem and installing a persistent backdoor.

The Cover-Up Attempt

When community members began reporting the compromise on GitHub, the attackers posted 88 bot comments from 73 unique accounts in a 102-second window. The accounts used were previously compromised developer accounts, not purpose-created profiles. Using the compromised maintainer account, the attackers closed the issue as “not planned.”

Attribution

TeamPCP orchestrated one of the most sophisticated multi-ecosystem supply chain campaigns publicly documented to date. The tooling development arc — version 1 in December 2025, hardened version 2 in February, deployment in March — reflects a small, motivated developer team with a security research background, not a large-scale criminal operation.

Notably, a component called hackerbot-claw uses an AI agent (openclaw) for automated attack targeting. Aikido researchers documented this as one of the first cases of an AI agent used operationally in a supply chain attack. We will return to this.

Part IV: The Axios Attack (March 31, 2026) — Nation-State Scale

Seven days after LiteLLM, the other shoe dropped — and it was significantly larger.

Background: Axios at Scale

Axios is the most widely used HTTP client in the JavaScript ecosystem. With over 100 million weekly downloads, Axios occupies a position in the JavaScript ecosystem that is hard to overstate — it is present in frontend frameworks, backend services, and enterprise applications worldwide. It is a transitive dependency for an almost uncountable number of projects. If you maintain any Node.js codebase of appreciable size, you almost certainly depend on Axios somewhere in your tree.

The Attack

On March 30, 2026, StepSecurity identified two malicious versions of the widely-used Axios HTTP client library published to npm: axios@1.14.1 and axios@0.30.4. The malicious versions injected a new dependency, plain-crypto-js@4.2.1, which was never imported anywhere in the Axios source code. Its sole purpose was to execute a postinstall script that acted as a cross-platform remote access trojan (RAT) dropper, targeting macOS, Windows, and Linux.

The pre-staging was methodical: an earlier “clean” version of plain-crypto-js (4.2.0) had been published 18 hours prior, likely to give it a brief history on the registry before the malicious 4.2.1 version arrived. This is a known technique to defeat “brand-new package” detection heuristics.

The attacker compromised the jasonsaayman npm account, the primary maintainer of the Axios project. The account’s registered email was changed to ifstap@proton.me — an attacker-controlled ProtonMail address.

The Payload: WAVESHAPER.V2

This is where the Axios attack diverges sharply from LiteLLM in terms of attribution and ambition.

Google Threat Intelligence Group (GTIG) attributes this activity to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018, based on the use of WAVESHAPER.V2, an updated version of a backdoor previously used by this threat actor.

The malware dropper cleaned up after itself: any post-infection inspection of node_modules/plain-crypto-js/package.json would show a completely clean manifest — no postinstall script, no setup.js file, and no indication that anything malicious was ever installed. Running npm audit or manually reviewing the installed package directory would not reveal the compromise.

Within two seconds of npm install, the malware was already calling home to the attacker’s server before npm had even finished resolving dependencies.

The operational sophistication is notable: both the 1.x and 0.x release branches were hit simultaneously, maximizing coverage across projects that had not upgraded from the legacy branch. The malicious window ran from approximately 00:21 to 03:20 UTC — overnight hours, minimizing the time before maintainers could respond.

Within Huntress’s partner base alone, at least 135 endpoints across all operating systems contacted the attacker’s command-and-control infrastructure during the exposure window.

Part V: The Coming Storm — LLMs as Force Multipliers for Supply Chain Attackers

The three attacks above represent a progression: from a years-long patient operation (xz) to a multi-week coordinated campaign (LiteLLM) to a precisely timed nation-state operation (Axios). But there’s a fourth dimension to consider, one that was barely visible in the LiteLLM case but will become impossible to ignore: AI-assisted attack automation.

The Research Problem is Solved

For decades, finding vulnerabilities in complex software required rare, expensive human expertise. A skilled security researcher could maybe audit a few thousand lines of code per day meaningfully — catching subtle logic flaws, off-by-one errors, type confusion bugs, and trust boundary violations. This scarcity of human expertise was, paradoxically, a constraint that also protected defenders: attackers faced the same scarcity.

LLMs have dramatically changed this equation. Modern code-capable models can:

• Read and reason about codebases at superhuman speed. A model can ingest an entire dependency tree and flag suspicious patterns in seconds.
• Generate exploit code from vulnerability descriptions. The gap between “here is the flaw” and “here is working proof-of-concept code” has collapsed.
• Identify attack surface systematically. CI/CD configuration files, package publishing workflows, token scopes — all of these can be systematically enumerated and analyzed for weaknesses.
• Generate plausible social engineering content. The fabrication of a believable long-term maintainer persona, complete with quality code contributions and a consistent online presence, is increasingly within the reach of automated systems.

The LiteLLM attackers had already taken a step in this direction. Their hackerbot-claw component, which used an AI agent for automated attack targeting, represents a proof of concept. It will not remain a proof of concept for long.

The Economics of Scale

Supply chain attacks historically required high investment for uncertain payoff. The xz attack required approximately two years of sustained, sophisticated effort by what is almost certainly a well-funded nation-state team. That same investment, amplified by LLM-assisted tooling, could potentially be replicated by a much smaller team in a fraction of the time.

Consider what an LLM-augmented attacker workflow looks like:

1. Discovery: Automated scanning of GitHub Actions workflows across millions of repositories to identify unpinned actions, wide token scopes, or PYPI/npm publish tokens in CI environments.
2. Prioritization: Ranking targets by download count, ecosystem centrality (how many projects depend on this package transitively), and credential richness (does this package typically run in environments with cloud credentials?).
3. Vulnerability identification: Per-target analysis of CI/CD pipeline configurations to identify the exact injection point.
4. Payload adaptation: Automatic generation of platform-specific payloads with anti-forensic cleanup.
5. Execution and suppression: Automated bot account deployment to suppress community disclosure attempts.

Steps 1 through 4 are all tasks where current LLMs are already capable assistants. As model capabilities improve — particularly in the domains of multi-step reasoning, tool use, and code generation — the degree of human oversight required to run this pipeline decreases. A plausible near-future scenario is a largely automated supply chain attack operation that requires only a small team to set strategic objectives, review outputs, and manage infrastructure.

The Attack Surface is Expanding

Meanwhile, the attack surface is growing faster than the security community’s capacity to defend it. The explosion of AI tooling — LLM wrappers, MCP servers, agent frameworks, vector databases — has created an enormous new ecosystem of packages that are often:

• Credential-rich by design (they hold API keys for multiple LLM providers)
• Maintained by small teams with limited security resources
• Downloaded millions of times a month because of rapid AI adoption
• Deeply embedded in infrastructure through transitive dependencies

LiteLLM was the perfect illustration: a library whose core purpose is to centralize API keys for dozens of AI providers, running in environments with cloud credentials and Kubernetes access. Compromising it is not just compromising one package — it is compromising the credential store for every AI service that package touches.

As organizations instrument their infrastructure with AI agents and LLM orchestration, they are creating new high-value nodes in their dependency graphs. Attackers, guided by LLMs that can systematically map these new attack surfaces, will find them.

Part VI: Best Practices for Defenders

The threat is real and growing. The good news is that supply chain attacks, unlike zero-days, often have effective mitigations that can be implemented before the attack arrives. The following recommendations are grounded in what actually failed in the xz, LiteLLM, and Axios incidents.

1. Pin Everything. Every Time.

The single highest-impact mitigation for dependency confusion and account takeover attacks is version pinning with integrity verification.

# Python — use pip-compile or uv with a lockfile
pip install litellm==1.82.6  # Don't use "litellm" alone

# Node.js — commit your lockfile and use npm ci, never npm install in CI
npm ci  # Respects package-lock.json exactly

# GitHub Actions — pin actions to a full commit SHA
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
# Not: uses: actions/checkout@v4

LiteLLM was compromised through its own CI pipeline using an unpinned Trivy action. The users most impacted were those who ran pip install litellm without a pinned version. Both of these failures are solved by pinning.

2. Use Lockfiles and Verify Hashes

For Python projects, use pip-compile with --generate-hashes to produce a lockfile that includes cryptographic hashes for every dependency. For Node.js, commit package-lock.json and use npm ci. For Rust, Cargo.lock. For Go, go.sum. These lockfiles ensure that even if a registry account is compromised and a new version is published, your build will fail rather than silently pulling the malicious version.

# Python: generate hash-verified lockfile
pip-compile --generate-hashes requirements.in -o requirements.txt

# Install with hash verification
pip install --require-hashes -r requirements.txt

3. Monitor Outbound Network Traffic from CI

One of the most reliable indicators of a compromised dependency is unexpected outbound connections during build time. In both the LiteLLM and Axios incidents, the malware called home to attacker-controlled domains within seconds of installation. A CI runner that has no legitimate reason to make outbound HTTP requests to arbitrary domains should be configured to block or alert on such traffic.

Tools like StepSecurity’s Harden-Runner — which detected the Axios attack — operate precisely by monitoring egress traffic during GitHub Actions runs and alerting on anomalous connections. Adopting egress filtering on your CI runners is one of the most effective detection controls available.

4. Treat CI/CD Secrets with Zero Trust

The LiteLLM attack succeeded because a single GitHub Actions secret — the PyPI publish token — was accessible to the CI runner that also pulled an unpinned, attacker-controlled tool. Apply least privilege principles to CI secrets:

• Limit token scopes to the minimum required (PyPI trusted publishing avoids long-lived tokens entirely)
• Use environment protection rules so publish tokens are only accessible in protected branches
• Rotate secrets regularly and alert on unexpected access
• Consider using OpenID Connect (OIDC) for short-lived, just-in-time cloud credentials in CI rather than long-lived API keys

5. Implement Software Bill of Materials (SBOM)

An SBOM is a machine-readable inventory of every component in your software, including transitive dependencies. When a supply chain incident is disclosed, an SBOM allows you to answer the question “are we affected?” in minutes rather than hours.

# Generate an SBOM for a Python project
pip install cyclonedx-bom
cyclonedx-py requirements requirements.txt -o bom.json

# For Node.js
npx @cyclonedx/cyclonedx-npm --output-file bom.json

Integrate SBOM generation into your CI pipeline and subscribe to security feeds (OSV, GitHub Advisory Database, Sonatype OSS Index) that can be queried against your SBOM automatically.

6. Run a Dependency Security Proxy / Registry Firewall

Tools like Sonatype Repository Firewall, JFrog Xray, and Socket sit between your build system and the public registry and block packages that exhibit malicious characteristics in real time. Socket, for instance, performs behavioral analysis of packages — detecting things like new network calls, new postinstall scripts, or obfuscated code — rather than relying solely on known CVEs.

This is a particularly important layer because it catches zero-day supply chain attacks (like Axios) where no CVE yet exists.

7. Verify Packages Against Source Repositories

Both the LiteLLM and Axios attacks shared a common tell: the malicious versions were not present in the official Git repository. There was no corresponding Git tag for axios@1.14.1 or litellm==1.82.8. Tooling that compares published registry artifacts against tagged source commits would have flagged both immediately.

For Python specifically, PEP 740 (Attestations) and PyPI’s support for Sigstore-based publish attestations are moving toward a world where you can verify that a published package was built by an authorized CI workflow from a specific source commit. Adopting these attestations where available — and preferring packages that publish them — meaningfully reduces the risk of account-takeover-based attacks.

8. Harden Maintainer Account Security

The xz attack required multi-year social engineering; the LiteLLM and Axios attacks required compromising a single maintainer account. For open-source maintainers of widely-used packages:

• Mandatory MFA for all publishing-capable accounts (npm now requires this for popular packages; PyPI has made it available)
• Hardware security keys (FIDO2/WebAuthn), not TOTP, for registry account authentication
• Separate publishing tokens per CI environment, rotated regularly
• Multi-party publishing controls — require two maintainers to approve a release for high-criticality packages

9. Behavioral Monitoring on Developer Machines and Production

The Axios attack’s malware called home within two seconds of npm install. In production environments, implementing network egress monitoring and process behavioral analysis (tools like Falco for Kubernetes, or EDR solutions on developer machines) can catch post-exploitation activity even when prevention fails.

Watch for:

• Unexpected outbound HTTPS connections from build processes
• New .pth files appearing in Python site-packages
• Unexpected postinstall scripts in node_modules
• Kubernetes pods appearing in kube-system that weren’t in your manifests
• New systemd user services on developer machines

10. Apply the Principle of Ephemerality

One reason the Axios attack was somewhat contained is that many organizations use ephemeral CI runners — GitHub-hosted runners that are destroyed after each job. Ephemeral environments limit the persistence window for malware. Where possible:

• Use ephemeral runners for CI (GitHub-hosted or self-hosted ephemeral VMs)
• Run builds in isolated containers with minimal filesystem access
• Avoid sharing credentials between CI stages unless strictly necessary

Conclusion: Security at the Speed of Trust

The three attacks examined here — xz Utils, LiteLLM, and Axios — represent a spectrum of sophistication and attribution: a patient nation-state operation, a coordinated criminal campaign targeting AI infrastructure, and a North Korean APT operation against one of the most downloaded JavaScript packages in the world. What unites them is that none of them required breaking your code. They only required breaking your trust.

The emergence of LLM-assisted attack tooling — already visible in LiteLLM’s hackerbot-claw component — threatens to industrialize this attack class. Tasks that previously required scarce human expertise (finding unpinned actions at scale, reasoning about which packages are most credential-rich, adapting payloads to evade detection) are increasingly automatable. The attacker who once needed a nation-state budget to run a sophisticated supply chain campaign may soon need only a modest infrastructure investment and access to capable AI tools.

The defensive posture required in this environment is not one of reactive patching. It is one of systemic skepticism toward the build process itself: treating your dependency graph as an attack surface, your CI/CD pipeline as a trust boundary, and your package registry as an adversarial environment. The mitigations outlined above are not exotic — pinning versions, verifying hashes, monitoring egress, separating secrets — but they require discipline and tooling investment.

The code you ship is only as trustworthy as the code you build on. In a world where LLMs can systematically find the weakest link in that chain, the cost of ignoring the supply chain is about to become much harder to absorb.

If you’ve ever wanted a simple, visual way to manage your Jekyll blog without touching the terminal, this guide walks you through getting started.

Prerequisites

• A GitHub account
• Google Chrome (or any Chromium-based browser)

That’s it. GitBlog handles the rest — including scaffolding an entire Jekyll site from scratch if you don’t have one yet.

Installation

Install GitBlog from the Chrome Web Store. Once installed, you’ll see the GitBlog icon in your browser toolbar.

Connecting to GitHub

Click the GitBlog toolbar icon to open the popup.

Creating a Personal Access Token

GitBlog authenticates using a fine-grained GitHub Personal Access Token (PAT). To create one:

1. Go to GitHub Settings > Developer settings > Personal access tokens > Fine-grained tokens
2. Click Generate new token
3. Set the following permissions:
   • Repository access: All repositories
   • Contents: Read and write
   • Administration: Read and write (needed for creating new repos)
4. Copy the generated token

Back in the GitBlog popup, paste your token and click Connect. GitBlog validates the token against the GitHub API and stores it securely in Chrome’s synced storage — so it’s available across your devices.

Selecting a Repository

After connecting, GitBlog shows a dropdown of your repositories. Select one and GitBlog checks whether it has a Jekyll structure (by looking for _config.yml).

• Green badge — Jekyll detected, ready to go.
• Yellow badge — No Jekyll structure found. You can still open the editor, but you may need to set up Jekyll first.

Click Open GitBlog to launch the full editor in a new tab.

Creating a New Blog from Scratch

Don’t have a Jekyll blog yet? If you don’t already have a {username}.github.io repository, GitBlog offers a Create button right in the popup. Click it and GitBlog will:

1. Create the {username}.github.io repository on GitHub
2. Scaffold the full Jekyll structure — layouts, includes, CSS, a default about page, and a “Hello World” first post

A progress bar shows each file being created. Once done, click Open GitBlog and start writing.

Using the Editor

The editor opens in a full browser tab with three main sections accessible from the top navigation: Posts, Sections, and Settings (gear icon).

Posts

The Posts view lists all your blog posts from both _posts/ (published) and _drafts/ (drafts). Each post shows its title, date, and a Draft badge if unpublished. You can search posts by title using the search box.

Creating and Editing Posts

Click New Post to open the post editor. The editor has two areas:

Front Matter Form — A compact form at the top with fields for:

• Title (required)
• Date (defaults to today)
• Category (optional)
• Tags (comma-separated, optional)

Markdown Editor — The main editing area with three view modes, toggled from the toolbar:

• Editor — Full-width text editor
• Split (default) — Side-by-side editor and live preview
• Preview — Full-width rendered preview

The preview renders your markdown in real time using the marked library with HTML sanitization, so you see exactly how headings, lists, code blocks, tables, and other formatting will look.

Inserting Images

Click Insert Image in the editor toolbar to upload an image. GitBlog uploads it to assets/images/ in your repository and inserts the markdown image syntax at your cursor position. Images are limited to 5 MB.

Publishing and Drafts

Two save options are available:

• Save Draft — Saves the post to the _drafts/ directory (not published)
• Publish — Saves to _posts/ with an auto-generated filename (YYYY-MM-DD-title-slug.md)

You can move a post between draft and published states by using the corresponding button on subsequent saves.

Sections (Pages)

The Sections view manages your static pages — things like “About”, “Contact”, or “Projects” that appear in your site’s navigation.

Each section shows its title, permalink, and whether it appears in the navigation (In nav green badge or Hidden grey badge).

Creating Sections

Click Add Section to open the section editor with fields for:

• Title (required)
• Permalink (auto-generated from title if left blank, e.g., /about/)
• Layout (page or default)

Plus the same markdown editor as posts.

Reordering Navigation

Drag sections using the grab handle to reorder them. GitBlog updates the header_pages array in your _config.yml automatically, so your site’s navigation reflects the new order immediately on the next build.

Settings

Click the gear icon to access site settings.

Site Settings:

• Blog Title — Your site’s <title> and header
• Description — The site description / tagline
• Permalink Format — How post URLs are structured:
  • /:title/
  • /:year/:month/:title/
  • /blog/:title/

All changes are written directly to _config.yml. Click Save and the status indicator confirms the update.

Appearance:

• Color Mode — Switch between Light, Dark, or System (follows your OS preference). This applies to the GitBlog editor itself and is saved across sessions.

Tips and Good to Know

Conflict Resolution

If someone (or you on another device) edits the same file while you have it open, GitBlog detects the conflict when you try to save. A dialog gives you two options:

• Overwrite — Push your version, replacing the remote changes
• Reload — Discard your local edits and load the latest version from GitHub

Rate Limits

GitBlog displays your GitHub API rate limit in the status bar at the bottom of the editor. GitHub allows 5,000 requests per hour for authenticated users. Under normal usage you won’t come close, but it’s there if you need to check.

Caching

File listings are cached locally for 5 minutes to keep the editor snappy and reduce API calls. The cache is automatically invalidated whenever you create, update, or delete a file — so you always see fresh data after making changes.

Online / Offline Indicator

The status bar shows your connection state. If you lose connectivity, GitBlog lets you know so you don’t lose work trying to save to an unreachable API.

Synced Across Devices

Your token, selected repository, and color mode preference are stored in Chrome’s synced storage. Open Chrome on another computer and GitBlog is ready to go with the same configuration.

Summary

GitBlog gives you a clean, focused writing environment for Jekyll blogs without leaving your browser. No terminal, no git commands, no build steps — just open the extension, pick your repo, and write.