Cybersecurity Is Becoming Proof of Work — and We Need to Talk About Who Pays
A provocative analogy is making the rounds in security circles: cybersecurity has become proof of work. Just like Bitcoin mining burns energy to keep the network safe, organizations now burn endless resources just to keep their systems from being owned. And with AI democratizing attack tooling, the cost of that “mining” is climbing fast.
The Asymmetry Is Getting Worse
The attacker-defender asymmetry in security is nothing new. Attackers need one hole; defenders need to cover every surface. What’s changed is that AI is stretching this gap to breaking point.
LLM-powered tools now auto-generate phishing emails, automate vulnerability scanning, and even handle social engineering. The marginal cost of an attack is converging on zero. Defense costs, meanwhile, remain stubbornly tied to human hours, infrastructure investment, and the never-ending patch treadmill.
Why the “Proof of Work” Analogy Hits
The comparison works because it’s structurally accurate. Bitcoin’s proof of work forces participants to expend real energy to maintain network trust. Cybersecurity demands the same — organizations pour resources into keeping systems in a trustworthy state, continuously, with no finish line.
The problem is that this cost is distributed unevenly. Enterprises can throw nine-figure security budgets at the problem. Startups and solo developers cannot. A single open-source maintainer responsible for a package with millions of users bears a proof-of-work burden wildly disproportionate to their resources. The tax falls hardest on those least able to pay it.
antirez Pushes Back: “Nice Metaphor, Wrong Solution”
Salvatore Sanfilippo — better known as antirez, creator of Redis and one of the more respected voices in the developer community — offered a sharp counterpoint. His core argument: the analogy captures the symptom but points toward the wrong cure.
Bitcoin’s proof of work is intentional by design. Security’s proof of work is an unintended side effect. Conflating the two risks normalizing high defense costs as somehow natural or inevitable, when they’re really a consequence of choices we’ve made.
The real culprit, antirez argues, is that software is fundamentally too complex. Complexity creates attack surface. Attack surface demands resources to defend. Rather than racing to automate defense with AI, we should be reducing the attack surface through better design in the first place.
Will AI Defense Tools Actually Fix This?
The optimist’s pitch is straightforward: if AI powers the attacks, AI can power the defense. And yes, AI-driven threat detection, automated patching, and anomaly analysis tools are advancing rapidly.
But there’s a catch. AI defense tools are paid services. The line item changes — security engineer salaries get replaced by AI SaaS subscriptions — but total spend may not shrink at all. You’re swapping one form of proof of work for another.
There’s a deeper irony, too. AI defense tools are themselves new attack surface. If an LLM-based security system is vulnerable to prompt injection, your defense layer becomes an attack vector. The guard becomes the gate.
So Who Should Bear the Cost?
This is ultimately a question about responsibility. Today, end users and service operators absorb most of the defense burden. But pressure is growing to distribute it more broadly — to vendors who ship insecure software, platforms that don’t enforce security baselines, and governments that set the regulatory framework.
The EU’s Cyber Resilience Act and the US executive order on software supply chain security are early moves in this direction. Both push baseline security obligations onto software manufacturers. The signal: we’re done letting proof of work fall entirely on the people least equipped to handle it.
antirez’s point deserves the last word. The moment we accept defense costs as a law of nature, we stop pushing for better design. The real answer to AI-era cybersecurity may not be “defend smarter” but “build things that are harder to break in the first place.”
Comments
Loading comments...