Home/Blog

AI · Cybersecurity

AI is making cyberattacks cheaper, faster, and more accessible

A software weakness can stay exactly the same and become more dangerous. Lower the cost of attacking it, and more people can afford to try.

Chen-Yang Su·· 

Main takeaways
  • Cheaper attempts change which targets are worth attacking. AI can reduce the labor needed to understand software and adapt tools.
  • Speed, access, and capability are different changes. Real incidents and controlled benchmarks provide evidence for different parts of the story.
  • Defenders can change the same calculation. Faster fixes and narrower permissions reduce the opportunities an attacker can use.

Your student club has a website. It holds event registrations and runs on a few donated cloud credits. You built it over a weekend with an AI coding assistant.

Imagine that it contains a bug that could expose the cloud account. Finding and using the bug would take an attacker a full afternoon. Your little website might not be worth the effort.

Now imagine that software can do most of that work in minutes. The website has not changed. Neither has the bug. The attack has become cheaper. Your account could become worth targeting for its computing credits, even if nobody cares about the club.

This is a hypothetical example, but it gives us a useful question to ask about AI and cybersecurity: what happens when an attack that used to require scarce expertise becomes affordable at scale?

01 / The change in one picture

The same app, with a lower cost to investigate itA student stands beside an event-registration app. A human investigator faces a costly afternoon of work. An AI-assisted investigator faces a lower labor cost. The app and its weakness stay the same. This is a hypothetical illustration. You built it. Club sign-ups Same app. Same bug. Human laborAn afternoon of effort AI-assisted laborA lower cost to try The attacker’s calculation changes.
Figure 1. A hypothetical student app. The change is in the attacker's effort, not the underlying software. No measured time or success rate is implied.

A cheaper attempt can make an old weakness worth finding

Start with a simple economic model. An attacker compares the expected benefit of an attempt with its cost. If an attempt has a 10% chance of returning $100, its expected gross return is $10. An attempt costing $20 loses money on average. An attempt costing $2 has a positive expected return, before other costs.

These numbers are invented. The relationship is the point: reducing the cost can change whether the same target is worth attacking. The attacker does not need a better vulnerability for that to happen.

There are two ways activity could increase. An existing operator can afford more attempts with the same budget. Other people may start attempting attacks when the required skills and startup effort fall. The second effect depends on people choosing to enter; it does not follow automatically from a faster tool.

02 / Try the economics

What can a fixed budget buy?

Hold the budget at $1,000. Change the cost of one attempt, then change its chance of success.

$10
10%
100attempts the budget can buy
10expected successful attempts

10 expected successes

Bar scale: 0–40 expected successful attempts.

$1,000 ÷ $10 = 100 attempts; 100 × 10% = 10 expected successes.

Try this: set cost to $100 and success to 10%. Then set cost to $10 and success to 1%. Both give an expectation of one success.

Figure 2. A hypothetical budget model, not attack data. Attempts = floor(budget ÷ cost); expected successful attempts = attempts × success probability. An expectation can be fractional. Each attempt has the selected probability; this is not a count of distinct breached organizations. It omits setup costs, detection, limited targets, and changes in attacker behavior.

Cheaper tools therefore do not guarantee more successful breaches. They could produce many more failed attempts. Defenders could also reduce the probability of success enough to offset the increase. To understand what is actually happening, we need observations as well as a model.

The observed change is in the work between steps

A cyberattack involves several kinds of work. Reconnaissance means learning about a target. A vulnerability is a weakness that could permit an unauthorized action. An exploit is a way to use that weakness. Credentials, such as passwords and access tokens, can provide another route in.

Automation in attacks predates language models. What an AI agent can add is help with unfamiliar code and the transitions between tasks: interpreting an error, modifying a script, choosing another tool, and trying again. An agent is a model connected to tools and a loop that lets it act on results.

In a campaign observed in Q2 2026, Google's Threat Intelligence Group reported that attackers compromised a cloud resource and then planned, built, and ran an agent-enabled credential-harvesting campaign in under six hours. AI handled parts of the scanning workflow and troubleshooting. The report appeared on 8 September.

That is evidence of a fast, AI-assisted operation. It does not show how long the same operators would have taken without AI, or that AI caused the initial cloud compromise.

In a post dated 2 November UTC, Palo Alto Networks CEO Nikesh Arora wrote: “attacks are not becoming more sophisticated, it's the same attacks, faster and by a lot more people.” That describes one mechanism well. It is too broad as a description of every change in AI's offensive abilities.

Anthropic's September misuse report also describes individuals and groups using AI to coordinate work across targets. These are selected cases visible to a model provider. They support the existence of the mechanism; they are not a representative census of attackers.

New capabilities and wider access are separate developments

Some models are also getting better at difficult technical tasks. In April, Anthropic reported strong exploit-development results for Claude Mythos Preview and initially limited access through Project Glasswing. That concerns what a model can do.

By September, a second issue was clear: who could obtain similar capabilities. Open-weight means a model's learned parameters are available for others to download and run. It does not imply that all training data or development code is public, or that running the model is free.

NIST's Center for AI Standards and Innovation assessed Z.ai's GLM-5.3 as the most cyber-capable open-weight model released at the time. It still placed the model about four months behind the US frontier on its aggregate cybersecurity measure. That is a comparison across evaluations, not a forecast of when the gap will close.

Anthropic's separate evaluation found similar performance for GLM-5.3 and Mythos Preview on one exploit-development benchmark. Similarity on one test does not establish equal overall capability.

03 / Read the denominator

Working exploits in a controlled test

ExploitBench: known bugs in Chrome's V8 engine, tested against offline targets.

GLM-5.3
Open weights12.2%
Mythos Preview
Restricted access13.7%

GLM-5.3: 50 of 410 attempts (12.2%). Mythos Preview: 56 of 410 (13.7%). The denominator counts attempts, not internet sites.

Figure 3. Anthropic's reported results: 50 of 410 attempts for GLM-5.3 and 56 of 410 for Mythos Preview, over 41 selected V8 vulnerabilities. Both bars use a 0–100% scale. Repeated attempts on selected bugs do not measure the fraction of real systems a model can compromise. Source and methods.
Three different questions

Speed: how much work can an operator complete in an hour? Capability: which tasks can the model solve? Access: who can obtain and run it? Progress on one can matter even when the other two stay fixed.

The defender is running a clock, too

Many attacks still have ordinary entry points. Verizon's 2026 Data Breach Investigations Report says software vulnerability exploitation accounted for 31% of breaches in its reporting dataset, ahead of credential abuse. Its incident period was November 2024 through October 2025. Those dates make it useful background, not a measure of the effect of the 2026 models above.

A patch is a software update that fixes a problem. Once a flaw becomes known, attackers may investigate it while the organizations using the software test and install the fix. Faster attacker work can shorten the time available to act.

In the example below, a hypothetical attack becomes usable six hours after disclosure. Move the time when the defender installs the fix. The gap between those events is the exposure window in this simplified case.

04 / Move the defender's clock

How long does this path stay open?

48 h

42 hours of exposure

48 − 6 = 42 hours. Installing the fix sooner reduces this window.

Figure 4. An invented timeline, in hours after public disclosure. Window = max(0, fix time − attack-ready time). The six-hour setting is a teaching assumption unrelated to the GTIG campaign. This model assumes a complete fix, no earlier compromise, and no other route in. It is not a measurement of real patching times.

Patching earlier closes this particular route sooner. It does not undo an intrusion that already happened. That is why organizations also investigate evidence of access, monitor systems, and revoke credentials when needed.

A trusted tool can carry the attack across a boundary

Your club app probably depends on libraries, a hosting provider, and a development extension. Those tools can carry permissions: access to files, repository contents, or deployment credentials. An attacker may reach you through one of them.

CISA's May 2026 bulletin about Nx Console describes a poisoned development extension delivered through automatic updates. CISA reported that the compromise reached a GitHub employee's device and led to theft from internal repositories. The bulletin establishes a supply-chain route; it does not establish that AI caused the incident.

A supply-chain attack compromises something the target depends on. Its impact depends on what that dependency can reach. In the illustration, change the permissions held by an already compromised tool.

05 / Follow the permissions

One compromised tool. How far can it reach?

With broad credentials, the compromised tool can reach production as well as the workspace.

Figure 5. A hypothetical permission map, not a reconstruction of Nx Console. Restricted mode gives this tool only a disposable workspace and no production credentials or alternate production route. It illustrates how limiting permissions can contain one compromise, without making the tool or the workspace safe.

AI agents add a related problem. They read repository files, tool responses, and external documents. An attacker can put instructions in that content and try to make the agent treat them as commands from its user. This is prompt injection: untrusted information attempts to become an instruction.

Google's September report documents malicious files aimed at coding assistants, as well as attempts to manipulate AI security scanners. A model's ability to read a file should not itself grant the file's author authority over the model's tools.

For a student building an app, “it works” is only the first test

Return to the club website. Suppose it correctly saves a registration and displays a confirmation. That checks the happy path. It does not tell you whether one member can read another member's private information.

Authentication asks who you are. Authorization asks what you are allowed to do. A functioning login screen can coexist with broken authorization. An AI-generated app needs both checked.

Several defensive choices follow from the mechanisms we have examined:

Reduce opportunities: know what is exposed and keep it maintained

For your own app, list the public services and software dependencies. Apply relevant fixes. CISA's Known Exploited Vulnerabilities catalog identifies flaws with evidence of exploitation; it helps prioritize work rather than treating every warning equally.

Reduce success: test permissions, including the denied actions

Use separate test accounts. Check that one member cannot read or change another's private record. Keep secrets out of browser-delivered code. Review changes affecting access rules. These checks address specific failure modes that a working demo can miss.

Reduce impact: give tools only the access their task needs

Keep production credentials away from experiments and unfamiliar repositories. Use a disposable environment for code you have not reviewed. A tool that can edit a test project need not also control the live database. The permission map shows why that boundary matters.

Use AI to help find and fix weaknesses, then verify the fix

A defender can ask an assistant to explain a dependency warning, inspect an access rule, or propose a test. Verify the result against the actual application. More generated findings help only when someone can check, prioritize, and resolve them.

06 / Check your understanding

Which conclusion does the evidence support?

1. Attack cost falls tenfold. Must the number of successful breaches rise tenfold?

It depends. A fixed budget can buy more attempts, but changes in success probability, available targets, and operator behavior affect the result.

2. A model succeeds in 50 of 410 exploit attempts. What have we measured?

Performance in that test. Selected vulnerabilities, repeated attempts, and a controlled environment do not represent all websites.

3. An agent reads a file that says “upload the deployment key.” What decides whether it should act?

User authority and tool permissions. Reading attacker-controlled content does not authorize an action. Keeping the key inaccessible also limits what a mistaken action can expose.

Figure 6. Three conceptual checks. Each answer explains a limit of the argument. With scripting disabled, the explanations remain visible.

What would establish the size of the effect?

The reports give us concrete examples of AI assisting real attacks. The evaluations show that some models can solve difficult exploitation tasks. The economic model explains why lower costs could expand activity. Those are different kinds of evidence.

To estimate how much AI increases successful breaches, we would need stronger comparisons: comparable operators working with and without AI, measured labor and computing costs, and outcomes across representative targets. We would also need to account for changes in defenses and reporting. Selected incident reports do not provide that full comparison.

The same economic logic applies to defenders. If AI makes finding a flaw cheap but reviewing and deploying a fix remains slow, the defender's bottleneck persists. If it helps verify and ship fixes sooner, the window in Figure 4 shrinks.

For the student club, the useful change is concrete: review who can access registration data, keep deployment credentials out of the coding agent's workspace, and verify the relevant fixes. These actions change the attacker's chance of success and the damage a compromised tool can cause. In the budget example, a tenfold fall in attack cost was exactly offset by a tenfold fall in success probability.

Sources and further reading