AI Cyberattacks and Defenses: What Recent Security Incidents Show

I've followed artificial intelligence for years, but a string of cybersecurity incidents has made me worried in a new way. AI can lower the time and expertise needed to find weaknesses and conduct attacks, while defenders are using the same technology to find and fix them. This is an argument about how those forces may interact, not evidence that every recent attack was AI-driven.

Google's threat researchers reported a zero-day exploit that they believe was developed with AI. A zero-day is a vulnerability that defenders may not have had an opportunity to fix. Historically, an attacker might hold a valuable one back because using it risks revealing it and prompting a patch.

[Google's report](https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access) says criminals planned a mass exploitation operation and that Google's counter-discovery may have prevented it. The team expressed high confidence that AI supported discovery and weaponization, based on features of the exploit, while saying it did not believe Gemini was used. The flaw bypassed two-factor authentication on an administration tool but still required valid credentials.

I see this as an early sign that vulnerability discovery may become faster and cheaper. It does not establish exactly which model was used or prove that all planned exploitation was stopped; those are the limits of the reported evidence.

Another incident hit the JavaScript package ecosystem. Attackers inserted malicious versions into trusted packages, including TanStack packages, turning a software dependency into a potential route into developers' machines and build systems.

The attack also had a destructive feature: researchers described a monitor that could erase files if a stolen GitHub token was revoked. This makes remediation an incident-response problem rather than a simple instruction to flip a switch. Affected teams should follow the maintainers' and security responders' current guidance.

A package can appear legitimate and still carry a malicious update. I worry about how casually developers, myself included, install dependencies and let automated tools pull them in. The expanding set of packages and services we trust enlarges the consequences when a supplier is compromised.

Researchers tracked the broader Mini Shai-Hulud campaign across npm and PyPI, with figures changing as the incident developed. [JFrog's contemporaneous analysis](https://research.jfrog.com/post/shai-hulud-here-we-go-again/) describes credential theft, propagation and the destructive switch; its findings do not establish that AI caused this particular attack.

This video is sponsored by GenSpark. Berman describes GenSpark Claw as a hosted way to use an OpenClaw-style agent through messaging apps, without setting up a server oneself. These are the sponsor's product claims; hosting an agent does not by itself eliminate the need to assess access, configuration and security.

The examples raise a bigger question for me: what happens when more capable models are used both to attack and to defend? I want to look at the reported incidents first, then explain why I think the relative capabilities and economics of these models matter.

Vercel disclosed an April 2026 security incident involving access to certain customer environment variables. The company said it contacted affected customers and recommended rotating exposed credentials. Environment variables often contain secrets, so their exposure can have consequences beyond a single application.

Vercel's [incident bulletin](https://vercel.com/kb/bulletin/vercel-april-2026-security-incident) traces the initial compromise to Context.ai, a third-party AI tool used by an employee, and then to that employee's accounts. The company found some additional affected accounts and distinguished separate compromises that did not appear to originate on Vercel systems.

Vercel's leadership pointed to the attack's speed and sophistication when discussing possible AI assistance. That is a suspicion, not proof of AI involvement. The verified lesson is that access granted to a third-party service can create an indirect route into a company's systems.

Google's threat report describes a broader pattern of adversaries experimenting with AI for vulnerability research, malware development and other parts of their operations. Some activity is experimental, and the report distinguishes observations from the researchers' inferences about intent and model use.

A discovered flaw and an exploit are related but different: one is a weakness, the other is a way to use it. Defenders need to identify, validate and patch weaknesses before attackers can make reliable use of them. AI may speed up both sides of that race.

I wonder whether attackers are relying on frontier models from commercial providers, given their restrictions, or models with fewer controls. I suspect sustained misuse of guarded models is difficult, although safeguards are imperfect and Google's report documents observed misuse and attempts to circumvent restrictions.

My central framing is my AI versus your AI: the model helping a defender finds and fixes a weakness, while the model helping an attacker searches for another route. That framing is useful for thinking about speed, but the outcome also depends on access, configuration, human operators and deployment.

AI does not create the underlying need for security review. Vulnerabilities have existed for decades; models can accelerate discovery, including of logic flaws that ordinary scanning tools may miss. They can also generate incorrect findings or introduce new bugs, so their output still needs verification.

Google also describes AI-assisted development of obfuscation and other tools intended to evade defenses. Rather than treat every example as a fully autonomous campaign, it is more accurate to see a range of uses, some experimental, supporting different stages of an operation.

The report discusses malware that can use model output to help decide how to interact with a device. This is why I worry about scale: the same mechanism that helps an agent respond to an unfamiliar environment could be used by an attacker as well as by a legitimate operator.

AI services can themselves be targets. Attackers may attempt to steal credentials, abuse paid inference, or use access to an AI application as a bridge to other systems. The security of the agent, its connected tools and the permissions it receives all matter.

I think about these threats in the context of model guardrails and the difficulty of stopping abuse. A provider can put controls around a hosted model, but attackers can also seek compromised accounts or alternative models. The balance between useful access and misuse prevention is not simple.

There is a human side too: synthetic voice can make a fraudulent call sound like someone you know. A family can agree on a private verification phrase or independently call back on a known number when a message creates urgent pressure. No single precaution covers every scam.

One optimistic possibility is that AI helps expose a large backlog of software vulnerabilities and enables maintainers to fix them. I speculate that in two or three years security could look very different. That timeline is a prediction, not an established outcome, and new software and configuration errors will continue to create risks.

I initially describe an eventual world with almost no vulnerabilities, then qualify the point: I do not expect perfectly secure software. Even successful automated auditing depends on access to the right systems, accurate reports, responsible disclosure and actual deployment of fixes.

The economics are important. The largest model providers invest substantial resources in training and inference, while an attacker may seek a cheaper open-weight model or abuse someone else's access. Local models also require hardware and energy; the fact that weights are available does not make their use costless.

My hypothesis is that well-resourced defenders will often have access to stronger models than many attackers. That could help them review important code earlier. But model size alone does not determine security, and a stronger model is not guaranteed to identify every issue a smaller model finds.

A company could use an advanced security model to inspect an important application and address the problems it identifies before adversaries arrive. I consider that a meaningful advantage, provided findings are checked and fixed. Tools cannot eliminate social engineering, stolen credentials or mistakes in systems they never examine.

Anthropic's Claude Mythos Preview is one example of a model applied to security research. Anthropic introduced Project Glasswing to use the model against vulnerabilities in critical software. Its [technical report](https://www.anthropic.com/research/mythos-preview) describes findings and a process for working with maintainers on disclosure.

Anthropic reports that the model helped identify long-standing flaws in widely used projects, including OpenBSD and FFmpeg. The age of a bug shows how long it escaped detection; it does not mean every reported issue has the same severity or can be easily exploited.

For the FFmpeg example, Anthropic says the underlying bug dates to 2003 and became a vulnerability after a 2010 refactor. It also says turning that particular issue into a functioning exploit would be challenging. Other reported findings were still being disclosed and validated.

Anthropic chose a restricted preview instead of making Mythos generally available. I am skeptical of concentrating access to powerful security tools, and I question whether the most cautious release strategy leaves defenders without capabilities they need. That is my policy judgment, not proof of Anthropic's motives.

The displayed CyberGym chart gives Mythos Preview 83.1% and Claude Opus 4.6 66.6% on a vulnerability-reproduction benchmark. Those are results for a particular evaluation, not a measure of overall security or a guarantee of performance against real attackers.

I contrast Anthropic's approach with OpenAI's GPT-5.5-Cyber announcement. [OpenAI said](https://openai.com/index/gpt-5-5-with-trusted-access-for-cyber/) the cyber variant was a limited preview for selected defenders, with additional verification and controls. It was not an unrestricted release to everyone.

OpenAI said its initial cyber preview was designed to be more permissive on authorized security tasks, rather than to outperform standard GPT-5.5 on every cyber evaluation. Comparing numbers reported by different labs requires attention to the test conditions and should not settle which system is universally stronger.

I use a sketch of attack value and difficulty to explain my economic argument. High-value targets can justify substantial investment by both attackers and defenders; lower-value targets have historically been less attractive when finding and exploiting each one takes significant human effort.

Automation may change that calculation. If the cost of finding a weakness or customizing an attack falls enough, a large number of smaller targets could collectively become worthwhile. This is a proposed economic mechanism, not a measurement of how many attacks have already occurred.

The same falling cost enables useful software for smaller, previously underserved problems. I support open models and the broader benefits of cheaper development, while acknowledging that the same diffusion of tools can make security and abuse prevention harder.

I return to the claim that larger, well-funded models can help defenders harden valuable systems. Access to a capable model could improve a team's odds, but a model's capabilities, deployment and human response all matter. The attacker's objective may be narrower than the defender's task of protecting an entire system.

For an individual or small organization, the practical concern is not only an elaborate state-backed operation. Scaled phishing, credential theft, vulnerable dependencies and poorly configured services can cause harm as the cost of targeting falls. Ordinary protective practices and timely response remain useful.

I am less worried about an isolated group using an inferior model to defeat every defense of a major state than about many smaller attacks becoming economical. That is my assessment of relative risk, not a guarantee about what any particular attacker can accomplish.

The broader conclusion is that AI changes both the speed of attacks and the possibilities for defense. We should examine the evidence for each incident, make security a continuing process, and avoid treating either a powerful model or a single patch as a guarantee of safety.