Unfortunately, I believe we're entering the golden age of hackers.
Not because software suddenly became less secure. Not because engineers stopped caring about cybersecurity. And not because artificial intelligence invented vulnerabilities that didn't exist before.
We're entering this period because AI is dramatically changing the economics of finding and exploiting vulnerabilities.
On October 29, 2026, Binance suffered a security breach involving approximately $6.3 billion in cryptocurrency assets.
According to Binance's initial investigation, attackers may have compromised a DevOps engineer's laptop and gained access to internal infrastructure capable of submitting unauthorized withdrawal transactions. The company subsequently acknowledged additional breach points.
Around $3 billion in affected assets had been frozen by October 30, and Binance committed to covering the losses. The investigation remains ongoing.
There is currently no confirmed evidence that AI coding agents were involved in the Binance attack.
But the incident illustrates something I've been warning about.
Our digital infrastructure can contain thousands of security controls, countless engineering decisions, and years of accumulated protections.
Yet one successful attack chain can potentially cause billions of dollars in damage.
And we are entering an era in which finding those attack chains may become substantially easier.
The Fundamental Problem: Hackers Only Need One Way In
For people outside software engineering, let me explain the imbalance that makes cybersecurity so difficult.
An attacker needs to discover one exploitable path into a system. Defenders need to protect the system against an enormous number of possible attack paths.
Of course, real systems use multiple security layers. One vulnerability doesn't automatically mean a complete compromise.
But every additional component introduces another set of assumptions, dependencies, permissions, and potential weaknesses.
Consider what a modern application depends on:
- Hardware and firmware
- Operating systems and device drivers
- Networking protocols and infrastructure
- Servers, containers, and cloud services
- Databases and authentication systems
- Programming languages and software frameworks
- Third-party libraries and external APIs
- Browsers, mobile applications, and user interfaces
Each layer is a specialized field of computer science.
A vulnerability in one component may be harmless in isolation. Combined with weaknesses in other components, it can become much more dangerous.
That's what makes complex security incidents so difficult to prevent.
A company might invest millions of dollars protecting its infrastructure, yet an attacker could discover an unexpected interaction between a few seemingly unrelated components.
Security is not simply about how many vulnerabilities exist. It's about which vulnerabilities can be combined, which boundaries they can cross, and what privileges they ultimately expose.
Why Software Was Relatively Safe for Decades
I've been building software since 2010, and one thing has always fascinated me about cybersecurity.
For much of the internet's history, discovering sophisticated vulnerabilities was intellectually expensive.
Not impossible. Expensive.
You needed people with specialized expertise, extensive knowledge of operating systems and software internals, and the patience to investigate enormous amounts of code.
Finding a vulnerability might require weeks or months.
Building a reliable exploit could require significantly more effort.
Coordinating multiple specialists introduced additional costs, delays, and communication challenges.
And illegal exploitation carried substantial legal consequences.
These constraints never guaranteed security. Serious breaches have occurred throughout the history of computing.
But they helped limit the number of attackers capable of conducting highly sophisticated operations.
The world's digital infrastructure benefited, at least partially, from the difficulty of attacking it.
Now consider what happens when that difficulty starts falling.
AI Coding Agents Are Changing the Economics of Hacking
Modern AI coding agents are not merely autocomplete systems.
They can inspect repositories, understand unfamiliar code, run tests, interpret failures, investigate hypotheses, and work across multiple software components.
More advanced agent systems can divide problems into smaller tasks, coordinate specialized agents, and repeat experiments without the same human coordination overhead.
This matters enormously in cybersecurity.
Imagine investigating a system containing millions of lines of code.
A human security researcher must decide what to inspect, build a mental model, investigate suspicious behavior, and carefully test each hypothesis.
An AI-assisted system can help perform many of those activities in parallel.
And the same infrastructure that makes AI useful for legitimate software development can also assist offensive security research.
The problem isn't that AI automatically turns an inexperienced person into an elite hacker.
Human judgment, expertise, access, and resources still matter.
The problem is that capabilities once restricted by time, expertise, and coordination costs are becoming more accessible and scalable.
When the cost of testing potential vulnerabilities falls, the number of possible investigations can increase dramatically.
And when AI agents become capable of coordinating across multiple technical layers, complex attacks become more economically feasible.
This is already happening.
Google Chrome: A Complex Exploit Built in Six Days
On October 13, cybersecurity company XBOW publicly described a remarkable achievement.
Its researchers, working alongside AI agents powered by OpenAI models, developed a complete Google Chrome exploit chain involving three previously unknown vulnerabilities.
The attack crossed Chrome's security sandbox, potentially allowing code execution outside the browser's restricted environment.
Google awarded the research a $250,000 vulnerability reward.
The final exploit chain was built in just six days, with approximately $40,000 in compute costs.
For context, XBOW explained that comparable work had historically taken teams of specialists several months.
That's the part I find extraordinary.
Not the reward.
Not the number of vulnerabilities.
The reduction in time required to discover and combine weaknesses across multiple security boundaries.
The researchers still contributed essential expertise, and the vulnerabilities were responsibly disclosed and fixed.
This was legitimate security research, not a criminal attack.
But the underlying capabilities do not become technically irrelevant when used by someone with different intentions.
The same acceleration available to defenders can potentially benefit malicious actors.
The PHP Vulnerabilities: AI Is Finding Problems Hidden for Years
Another significant example appeared on October 21, 2026.
Security researchers disclosed two critical PHP vulnerabilities, commonly referred to as php2shell.
PHP is foundational technology used by a substantial portion of websites and web applications.
The vulnerabilities were identified through research involving AI-assisted systems, with organizations including Calif, Wiz, OpenAI, and Cloudflare participating in discovery or coordinated response efforts.
Emergency fixes and network-level protections were prepared.
Cloudflare subsequently reported observing attackers attempting to exploit the vulnerabilities and modifying their payloads to bypass protections.
An important distinction: attempted exploitation does not necessarily mean that an attacker successfully compromised a system.
Nevertheless, the significance is difficult to ignore.
AI is helping security researchers discover serious vulnerabilities in mature software that has been examined and maintained for years.
These are not necessarily weaknesses introduced by AI.
Many have existed for a long time.
AI is making it possible to find some of them faster.
That creates an enormous opportunity for defenders, but it also raises an uncomfortable question.
What happens when the rate of vulnerability discovery grows faster than the industry's ability to investigate, patch, test, and deploy fixes?
Binance: A Reminder of How Much One Successful Attack Can Cost
The Binance incident makes the stakes tangible.
Approximately $6.3 billion in crypto assets were affected in the October 29 attack, according to the exchange's initial estimate.
Investigators are still reconstructing the sequence of events.
Reports indicate that attackers compromised internal infrastructure involved in processing withdrawal transactions. Binance initially identified a potentially compromised employee device and later acknowledged additional breach points.
The company reported no evidence of wallet private-key leakage at the time of its initial disclosure.
I don't want to speculate about AI involvement without evidence.
The breach is not proof that AI agents conducted the attack.
What it does demonstrate is how devastating an attack can become when an adversary finds a path through a high-value system's security boundaries.
For an exchange, the consequences are measured in financial assets.
For a hospital, they might involve medical services and sensitive patient information.
For cloud infrastructure, they could affect thousands of businesses simultaneously.
Different systems. Different consequences.
The same underlying architectural challenge.
How do we make sure that compromising one component cannot become a catastrophic compromise of everything connected to it?
That question brings me to what I've been calling Security V2.
Security V1 Was Built Around Human-Scale Threats
For simplicity, I divide the problem into two architectural generations.
These are my own labels, not formal industry standards.
Security V1: The Traditional Model
Most modern software security combines established practices such as authentication, authorization, encryption, code reviews, vulnerability scanning, patching, monitoring, and incident response.
These protections remain essential.
But many practical security processes still operate on timelines shaped by human teams.
A vulnerability is discovered.
Researchers investigate it.
Developers prepare a fix.
Engineers test the patch.
Organizations schedule deployment.
Security teams monitor for exploitation.
Depending on the system, the process might take hours, days, weeks, or longer.
Meanwhile, attackers can investigate alternative attack paths.
This model has become increasingly sophisticated over time, but much of its operational structure still depends on human coordination and response.
AI threatens to compress the attacker's timeline.
Security V2: Architecture for Machine-Scale Threats
My argument is that we need to move beyond relying primarily on detecting vulnerabilities and patching them individually.
We must design systems that assume some vulnerabilities will remain undiscovered, some defenses will fail, and attackers may operate at machine speed.
Security V2 should emphasize several architectural principles.
1. Stronger isolation between components
Critical services should be isolated so that compromising one component doesn't automatically grant access to unrelated systems.
A web application processing user input should not possess unrestricted access to production databases, payment systems, or infrastructure controls.
Containers, virtual machines, operating-system sandboxing, and stronger hardware-backed isolation can help enforce these boundaries.
The goal is to limit the consequences of a successful exploit.
2. Independent security boundaries
One of my biggest concerns is security infrastructure in which multiple protections ultimately depend on the same underlying authority.
If compromising one service provides enough privileges to disable monitoring, change permissions, and authorize sensitive operations, then several apparent security layers may effectively depend on one point of failure.
For critical operations, authorization should be enforced by independently protected components.
For example, compromising an application server should not automatically provide sufficient authority to transfer financial assets.
Additional independent controls should remain effective even when the primary application has been compromised.
3. AI-powered defensive systems
If attackers can investigate vulnerabilities continuously with AI, defenders need similarly capable tools.
That means AI systems dedicated to detecting suspicious behavior, reviewing code changes, identifying dangerous configurations, and helping security teams respond faster.
But there's an important caveat.
Defensive AI systems must themselves operate under tightly restricted permissions and independent oversight.
Giving an AI security agent unrestricted production access could create another serious attack surface.
4. Continuous verification, not permanent trust
A successful login should not automatically establish unrestricted trust across an entire system.
Permissions should be narrow, temporary when possible, and continuously evaluated.
Sensitive operations should require stronger authorization than ordinary application activity.
An account used for reading information should not possess permissions to modify infrastructure or move significant financial assets.
The principle is simple.
Access to one component should never imply trust across the entire system.
5. Automated containment and damage limitation
Security systems should be capable of recognizing dangerous deviations and limiting their consequences before a human team completes an investigation.
Examples include suspending unusual privileged operations, restricting compromised service identities, and isolating suspicious workloads.
These controls must be designed carefully to avoid allowing false alarms or compromised detection systems to cause widespread outages.
But when high-value systems face machine-speed attacks, waiting for manual intervention in every scenario may be too slow.
6. Build security into the architecture, not only the patching process
The long-term solution isn't simply finding vulnerabilities faster.
It's reducing entire categories of weaknesses.
Memory-safe software, stronger type and permission systems, formally verified critical components, and more rigorous isolation can make vulnerabilities harder to exploit or less damaging when they occur.
This is where AI could become one of the greatest security tools we've ever developed.
Instead of merely finding bugs in existing systems, it could help engineers redesign the foundations that allow those bugs to become catastrophic.
Why Patching Every Vulnerability May No Longer Be Enough
Recently, Sam Altman argued that AI could force the industry to rethink its approach to software security.
His concern was that simply patching bugs individually may no longer be sufficient as AI-driven offensive capabilities improve.
That aligns closely with my own concern.
If attackers can discover and test potential weaknesses at increasing speed, the defensive model must evolve.
Patching is still necessary.
But patching addresses known weaknesses.
Architecture determines what happens when an unknown weakness is exploited.
Those are two different problems.
A strong defense requires both.
An organization with excellent patch management but poor isolation could still suffer a devastating breach.
An organization with strong isolation but outdated vulnerable components is also at risk.
Security V2 is about reducing the impact of failures while improving the speed and effectiveness of prevention and response.
Why I Warned About the Next 30 Days, Not 18 Months
On October 23, I shared my concern that the following 30 days could become an especially difficult period for cybersecurity.
That was a prediction, not a claim of certainty.
I was looking at the capabilities emerging from AI-assisted security research and the enormous amount of existing software that was never designed with those capabilities in mind.
I don't believe we should automatically assume that the most important consequences are 18 months away.
Some of the capabilities changing the security equation already exist.
They are being demonstrated in public research.
They are being integrated into real development workflows.
And their effectiveness is improving.
The Binance breach occurred six days after my warning.
That timing is striking, but it does not establish that AI caused the incident or validate every part of my prediction.
The broader issue is more important than any individual event.
We have an enormous installed base of software, written over decades, running critical infrastructure and financial systems.
We cannot realistically rebuild everything overnight.
But we can start changing the assumptions that guide how new software is designed and how existing systems are protected.
Is AI Also the Best Chance Defenders Have?
Absolutely.
This is an important part of the argument.
AI is not inherently an advantage reserved for hackers.
Security researchers can use it to identify vulnerabilities before criminals discover them.
Software companies can use it to review enormous codebases, generate regression tests, investigate unfamiliar dependencies, and improve architectural protections.
Infrastructure providers can use it to improve threat detection and incident response.
And better development tools could eventually make entire categories of security problems less common.
The competition is therefore not simply humans against AI.
It's increasingly about which side can use automation, intelligence, and secure architecture more effectively.
Defenders also possess important advantages.
They control their systems, can change their architecture, can restrict permissions, and can prevent specific actions regardless of what an attacker discovers.
The challenge is turning those advantages into systems that remain resilient under much faster and more sophisticated attacks.
What Businesses Should Be Doing Now
You don't need to run a cryptocurrency exchange to take this seriously.
Businesses increasingly depend on cloud services, APIs, payment infrastructure, third-party software, and AI agents that can perform actions across multiple systems.
The first priority is understanding what a compromised account, application, service, or AI agent could actually reach.
A business should know where its most sensitive operations occur, which components have authority over them, and whether those permissions can be reduced.
It should also review how quickly it can detect suspicious activity, revoke credentials, isolate affected services, and recover from an incident.
Existing best practices such as multifactor authentication, dependency updates, secure backups, least-privilege access, and continuous monitoring remain essential.
But businesses should increasingly evaluate systems from another perspective:
If an attacker successfully compromises this component, what is the maximum damage they can cause before an independent security boundary stops them?
That question should influence software architecture long before an incident occurs.
My Conclusion: The Golden Age of Hackers Should Become the Beginning of Security V2
I believe we're witnessing one of the most consequential changes in cybersecurity since the internet became mainstream.
AI is lowering some of the barriers that historically constrained sophisticated vulnerability research.
It is making complex software more accessible to automated investigation.
And it may allow attackers to explore combinations of weaknesses that previously required extensive human expertise.
The recent Chrome research demonstrates how quickly AI-assisted teams can develop sophisticated exploit chains.
The PHP vulnerabilities demonstrate how AI can help uncover serious weaknesses in foundational software.
The Binance breach demonstrates the financial scale of damage that a successful compromise of critical infrastructure can create, even without any established AI involvement.
Together, these developments reinforce my central concern.
Finding one exploitable path can be far easier than securing every possible path.
But I don't believe the answer is to fear AI or stop developing it.
The answer is to build software that can withstand a different class of threat.
Stronger isolation.
Independent security boundaries.
Smaller privileges.
Continuous verification.
AI-powered defense.
Architectures that remain resilient even when individual components fail.
We cannot build a future in which every vulnerability is guaranteed to be eliminated.
But we can build systems in which a single vulnerability is far less likely to become a disaster.
Security V1 was developed in a world constrained by human-scale attackers.
Security V2 must be prepared for adversaries operating at machine scale.
And I believe the transition needs to begin now.
Frequently Asked Questions
Are AI coding agents making hacking easier?
AI coding agents can reduce the time and expertise required for some cybersecurity research tasks, including code analysis, vulnerability investigation, and exploit validation. They do not guarantee successful attacks, but they can increase the scale and speed of security research.
Was AI used in the $6.3 billion Binance hack?
As of October 30, 2026, there is no confirmed public evidence that AI coding agents were responsible for the Binance breach. Investigations remain ongoing. The incident illustrates the potential consequences of compromised internal infrastructure, not proven AI-driven exploitation.
What is Security V2?
Security V2 is my proposed way of describing the architectural shift required for an era of increasingly capable AI-driven threats. It emphasizes isolation, independent security boundaries, least-privilege permissions, automated containment, continuous verification, and AI-powered defensive capabilities. It builds on existing cybersecurity practices rather than replacing them.
Can AI make software more secure?
Yes. AI can help defenders discover vulnerabilities, review source code, test fixes, monitor infrastructure, and improve software architecture. Its impact depends on how safely and effectively those capabilities are deployed.
Is traditional cybersecurity becoming obsolete?
No. Authentication, encryption, patch management, monitoring, and secure development remain essential. The concern is that these practices alone may not be sufficient if sophisticated attackers can discover and exploit vulnerabilities faster than organizations can respond.
Can any software system be completely secure?
Absolute security is generally not realistic for complex, evolving systems. However, strong architecture, independent controls, minimized privileges, continuous testing, and effective incident response can substantially reduce the likelihood and impact of successful attacks.
Marian Sorca is the founder of abZ Global, a software development and technology consultancy. He has worked in software development since 2010, building websites, applications, and software products for businesses.
This article reflects the author's technical assessment and forward-looking opinions as of October 30, 2026. Details of the Binance incident may change as investigations continue.