Fears of Advanced AI Attacks Haven’t Materialized, but There’s Still a Threat

Is the fear of AI attackers supported by the evidence?

If you listen to the headlines, you’d think AI is making adversaries into “super attackers.” In July, Hugging Face reported that an autonomous AI agent system had breached its infrastructure, and OpenAI later said the agents were OpenAI models that escaped a cybersecurity test environment. In late August, OpenAI, Anthropic, Amazon Web Services, Microsoft, and more than 100 other companies warned in an open letter that organizations have only months to prepare for AI-enabled attacks. In September, Axios reported that security experts expect an unprecedented wave of AI-powered attacks. Many of the CISOs and defenders I know have interpreted this as a warning of new, difficult-to-defend classes of AI attacks on the horizon—and plenty of people seem willing to capitalize on that very fear.

On the other hand, Google Cloud’s Cybersecurity Forecast 2026 is more measured. It predicted that adversaries would use AI to increase the speed, scope, and effectiveness of their operations, which means the same attacks, faster and at larger scale, not a new kind of attack. Recently, the Semperis 2026 Ransomware Risk Report reported that more than eight in ten surveyed ransomware targets said their attackers used AI; the report doesn’t show how respondents determined that AI was involved. Both are worth reading, but neither is an investigation of how real intrusions began: one is a forecast, the other a self-reporting survey. A lot of AI attack claims end up looking the same way. They’re forecasts, demonstrations, or vendor assertions rather than observations from real intrusions.

The fear underlying these claims is that AI will give attackers new capabilities, so attacks suddenly become far more advanced and existing defenses stop working. Maybe that will ultimately happen (it’s always wise to bet attacks will get better and cheaper, after all). But for now, the evidence suggests a far less dramatic reality. To understand what is actually leading to breaches, let’s look at incident response (IR) casework and large breach datasets where investigators reconstruct real intrusions after the fact.

Several recent reports on real incidents give us insights into AI’s real impact on the attack landscape. Mandiant’s M-Trends 2026, published in March by Mandiant and the Google Threat Intelligence Group (GTIG) is one such report, and it paints a clear picture: the breaches Mandiant investigated came from exploited code, leaked tokens, and over-scoped identities. In the casework, AI was an accelerant at most, not the root cause. There certainly wasn’t any evidence of any kind of AI-powered super attacker.

Larger and more recent datasets show the same pattern. Verizon’s 2026 Data Breach Investigations Report (DBIR), published two months later and based on more than 22,000 confirmed breaches, found that attackers are mostly using AI to scale and enhance established attack patterns rather than to invent new ones. Microsoft’s Digital Defense Report 2026 points the same way. Each has limits, which we cover below, but together they describe the same pattern: familiar attacks, delivered faster.

This isn’t an argument that AI is irrelevant to attackers. AI is making attackers faster and more effective at techniques they already use, and that’s a real risk: a deepfake can make a phishing lure far more convincing. But it’s still phishing, and high-quality defenses still mitigate it. The response should be scalable fundamentals rather than drama-driven panic.

What the data says about AI

The data ultimately doesn’t seem to support the fear. But it does tell us that AI is changing both attack and defense. Consider Mandiant’s M-Trends 2026 accounts, which show that despite the hype, 2025 was not the year breaches were directly caused by AI. The vast majority of intrusions Mandiant investigated still came from human and systemic failures.

Where attackers did use AI, it was mostly early in the attack lifecycle: for reconnaissance, social engineering, and malware development. However, Mandiant also describes a credential stealer that used a local AI command line tool to search for configuration files, then tried to collect GitHub and npm tokens. This is an interesting factor to consider, but it speaks more to AI tools as new attack surface inside organizations than it does AI as an attack tool per se.

Verizon’s analysis of AI-assisted attacks reached a supporting conclusion that AI primarily impacts attackers’ operational capability, at least for now. It’s scaling the techniques attackers already use, not creating super weapons. In its analysis of 793 adversaries that Anthropic had taken enforcement action against, Verizon found that phishing (44%) and vulnerability exploitation (32%) were the most common AI-assisted initial access techniques. Interestingly, despite phishing campaigns taking advantage of AI, phishing’s share of the breaches in Verizon’s own dataset didn’t meaningfully change over prior years.

Caveats on the samples

Each of these sources has limits, of course. Mandiant’s data comes only from its own IR engagements, which skews toward breached enterprises that hired Mandiant. Verizon’s comes from its contributors and public disclosures, so its mix shifts as contributors come and go. Microsoft’s comes from its own responders and customers.

While it’s reasonable to extrapolate from these findings, it’s also important to bear in mind that they don’t represent every organization.

What is causing breaches

Exploits, again

Exploits are the most common way in, and the trend is up. Mandiant found that exploits were the number one initial infection vector for the sixth year running, at 32% of investigations where the initial infection vector could be identified. Verizon’s much larger dataset shows the same direction: exploitation was the most common initial access vector at 31% of breaches, up from 20% a year earlier. Microsoft saw exploits of public-facing applications rise from 15% to 24% of the intrusions it investigated. The three measure slightly different things, so the figures aren’t directly comparable, but they point the same way. In Mandiant’s cases, zero-day exploitation of internet-facing enterprise applications dominated, including SAP NetWeaver (CVE-2025-31324), Oracle E-Business Suite (CVE-2025-61882), and Microsoft SharePoint (CVE-2025-53770). SAP and SharePoint were also exploited as n-days, meaning after patches shipped. Patching isn’t keeping pace, either: Verizon found that only 26% of critical vulnerabilities in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities (CISA KEV) catalog were fully remediated in 2025, down from 38%, and the median time to full resolution rose to 43 days.

Tokens and identities

The other recurring theme in these reports is the continued targeting of credentials and similar secrets as an effective attack strategy. Verizon found credential abuse in 39% of all breaches when counted at any point in the attack (not just first access) even though it fell to 13% as an initial access vector, a drop Verizon attributes partly to a methodology change involving tracking pretexting separately.

Palo Alto Networks’ Unit 42, drawing on more than 750 incident response engagements, found identity weaknesses played a material role in nearly 90% of them. In Mandiant’s supply chain cases, attackers pivoted from a source code management (SCM) account or a developer workstation, used personal access tokens (PATs) to find hardcoded integration tokens in repositories, and turned one compromised repo into a customer-wide event. M-Trends cites UNC6395 and the Salesloft Drift incident as an example. Over-scoped integration keys and wildcard API keys were common, and OAuth and refresh tokens bypass multifactor authentication (MFA).

None of this needs AI; these are all well-worn patterns. It’s probable AI is accelerating these attacks, but it’s hard to confirm that from incident investigation data alone.

Time-to-exploit has gone negative

The clearest changes in the data all have to do with speed. GTIG estimates the mean time to exploit fell from 63 days in 2018 to -1 in 2024, and to about -7 in 2025. A negative number means exploitation, on average, now happens before a patch exists. The change in attacker pace coincides suspiciously well with AI adoption, but it’s hard to say conclusively from this data alone how much of the impact can be attributed to AI specifically.

The direction matters more than the specific value; reports differ on the exact numbers, but they agree on the direction. For example, Microsoft’s separate finding that the median time from a vulnerability appearing in the wild to being weaponized has dropped well under 24 hours points the same way. Speed to patch is therefore becoming a key capability for defenders, but attacks arriving before patches are released means there has to be more to a defensive posture than rapid patching alone.

Attackers are also moving faster once they have a foothold. In 2022, the median time between initial access and a hand-off to a second threat group was more than eight hours, according to Mandiant. But in 2025, it was 22 seconds. M-Trends ties this in many cases to the often-automated way initial access partners deliver malware on behalf of the secondary group. Speed is a real problem, and much of it comes from automating established tradecraft—something AI tools are well-suited for.

Where the sources diverge, and what’s changing

The data can’t seem to agree on the impact of phishing, though report authors do seem to agree that AI-driven technologies either are already, or will soon, have an impact on phishing effectiveness.

Microsoft’s Digital Defense Report 2026, published October 1, draws on a different sample: Microsoft’s own incident responders and telemetry, covering July 2025 to June 2026. Phishing was the successful point of entry for attackers in 23% of the intrusions Microsoft investigated, up from 7% a year earlier. Microsoft says AI is making those lures more personalized and effective. But this is also an inference from the authors, not something that the data definitively proves. Microsoft also says target selection, decision-making, and the most complex intrusions are still manually driven in most of the campaigns it sees.

Meanwhile, Verizon’s 2026 Data Breach Investigations Report, published in May, draws a different conclusion about phishing from a much larger sample: more than 22,000 breaches. Its figures blame phishing for just 16% of breaches, unchanged from the prior year.

Mandiant’s data is more mixed: email phishing fell to 6% of intrusions from 14% in 2024, while voice phishing rose to 11%, making it the second-most common vector. The samples may count these differently, and M-Trends doesn’t quantify AI’s role in that shift. At the same time, the M-Trends authors say attackers are using large language models (LLMs) to move from mass email toward personalized, rapport-building social engineering. That’s the quality side of the risk. A well-written, personalized lure, or a deepfaked voice on a call, makes an old attack far more convincing, but it’s still phishing.

Microsoft expects the manual limits to fade. And in July, Sysdig documented what it called the first agentic ransomware operation, JADEPUFFER, an extortion campaign driven end to end by an LLM. It got in through a Langflow vulnerability that had already been disclosed and had an available patch. That is still ransomware, reached through a known vulnerability. But with less human effort required thanks to AI tooling, operational scaling tilts in the attacker’s favor.

Where AI does matter

None of this should be taken as saying AI isn’t having an impact—it clearly is. Not only is it helping operationalize attacks faster, but it’s growing attack surface inside organizations. The developer toolchain is becoming more important to attackers, and AI agents are both a target and a tool inside it. Attackers who compromise a developer environment now find agents, command line tools, and tokens sitting together. GTIG’s campaign timeline in M-Trends points the same way: it lists the Shai-Hulud npm worm and CVE-2025-55182 (React2Shell), including React2Shell-linked campaigns with XMRig and TruffleHog payloads. M-Trends gives them no body analysis, so we use them only as corroboration that developer tooling is under attack. We’ll cover a concrete example in the next post in this series.

The point is that AI raises the speed, scale, and quality of familiar attacks, including phishing, malware, ransomware, and credential theft, and puts access and credentials in new places. It isn’t a new category of attack that fundamentals can’t address.

What’s a defender to do?

If exploitation can precede the patch, phishing lures are getting more personalized, and tokens bypass MFA, the useful work is unglamorous. None of it is materially new, though, even if priorities might have shifted. The goal is to do the fundamentals faster and more consistently, not to chase a class of AI attack the data doesn’t show. I think about that work in two layers: general tactics that apply to any organization, and application security (AppSec) controls aimed at the exploitable code, leaked secrets, and over-scoped integrations behind most of the breaches above.

On the general side, know which internet-facing systems you run, and keep compensating controls ready for the case where no fix is available. A firewall rule, a disabled feature, or an isolated host buys time while the vendor catches up. Make phishing resistance a priority: move to phishing-resistant MFA, and assume the old tells, like clumsy writing, are disappearing. Don’t stop at email, since voice and messaging lures are rising too, so give your help desk a way to verify callers that doesn’t depend on how a voice sounds. Because OAuth and refresh tokens can outlive a password reset, revoke sessions as part of incident response. And plan for speed after initial access: if a hand-off to a second group can take seconds, detection and containment can’t wait on a ticket queue.

The AppSec layer targets the other half of what the data shows: code that can be exploited and credentials that were given too much power. Checkmarx products can support several of these activities, and I’ve noted where, but the activities matter more than the tooling, and you can do most of them with other products or by hand at smaller scale:

• Know what’s in your software. Keep a current software bill of materials (SBOM) and use software composition analysis (Software Composition Analysis (SCA)) to see which vulnerable components in your applications are reachable, so you can act before a patch exists. When the next vulnerability in a widely used framework lands, as React2Shell did, “are we affected?” should take minutes to answer. Checkmarx One’s SCA capabilities support this.
• Prioritize by exploitability, not severity alone. A critical-rated finding in dead code matters less than a medium-rated one on an internet-facing execution path, so correlate findings from code, dependencies, and infrastructure, and rank them by reachability and exposure. Application security posture management (ASPM) tools, including our own Checkmarx ASPM, do this correlation, and it keeps scarce remediation time on what attackers are actually using.
• Prevent familiar weaknesses at creation. Attackers keep going after the same classes of code weaknesses, and AI coding assistants increase the volume of code that reviewers have to check. Giving developers and their assistants security feedback while code is written, through static analysis in the integrated development environment (IDE) and the pipeline, costs far less than finding the weakness after it ships. Checkmarx Developer Assist and Next Gen SAST support this.
• Inventory secrets and rotate them. Use short token lifetimes and the narrowest scopes that work, and scan repositories, build pipeline configuration, and infrastructure as code for hardcoded tokens so they’re caught before they spread.
• Treat integration tokens and PATs as production credentials, including the ones in personal and side-project repos.
• Treat the developer toolchain as attack surface. Inventory the AI coding assistants, command line tools, Model Context Protocol (Model Context Protocol (MCP)) servers, and agents in your development environments, and hold them to the same least-privilege standard as any other service that can reach tokens. Vet packages before they enter the build, since compromised and malicious packages are how worms like Shai-Hulud spread. Checkmarx AI Supply Chain Security and malicious package protection support this.
• Make policy enforceable. A policy without a gate is advice. Failing a build or blocking a merge on known-exploited components or hardcoded secrets turns policy into a control, but only if findings are accurate enough that teams don’t route around the gate. Policy enforcement in Checkmarx One provides various levels of enforcement, from reporting issues to blocking activities entirely.
• Close the loop on fixes, and measure the backlog, not just the clock. Use AI-assisted triage and fix suggestions, such as Checkmarx Triage Assist and Remediation Assist, with a human approving each merge. Mean time to remediate (MTTR) can improve while the number of open critical findings grows, so track both.

Conclusion: Be skeptical of the loudest claims

The next time an AI attack headline lands, ask what it’s based on: a demonstration, a forecast, or an investigated intrusion. The IR and breach data we have, from Mandiant, Verizon, and Microsoft, says the breaches are still coming through exploitable code and credentials that were given too much power. AI is making attackers faster and more effective at going after them, but it hasn’t changed what they go after. Those problems are old, and they’re fixable.

Read the M-Trends 2026 report and the Verizon DBIR yourself, with their sample biases in mind, and consider how much of your security budget might be aimed at hype.

Review your security program, looking for opportunities to increase the pace of triage and remediation activities. Find places to enable detections earlier in the application software development life cycle (SDLC) so that you have a chance to fix issues before they reach production. Understand your AI agent, model, and tool inventory, and update your threat model accordingly.

Unpublished preview copy — do not publish without permission from Checkmarx