Can AI agents now hack websites on their own? What defenders change

Yes. In 2026 attackers ran AI agents that scanned, broke into and planted access on real company websites with very little human help. The agents mostly win on flaws that are already known: old framework code, unpatched plugins, exposed services and default passwords. Defenders should patch exposed, exploited flaws in days, not months, and shrink what is reachable.

The headlines mix confirmed facts with guesses. This guide separates the two, explains what these agents do at each stage of an attack, shows which defences still hold up, and ends with a quarter long plan and a walkthrough with real commands.

Key takeaways

• It is real, and it is cheap. One operator's agents tried more than 1,200 websites and reached more than 100 companies, at an estimated $50 in AI tokens per successful break in, according to Reuters.
• It is mostly known flaws, found faster. Documented entry points are old framework code, exposed internal services and default credentials, not new classes of attack.
• The human is still there, just less. Anthropic's 2025 case put AI at roughly 80 to 90 percent of the work, with humans at a handful of decision points.
• Agents are not reliable. Success rates were about 10 percent in one campaign, and Anthropic reported its misused model hallucinating credentials.
• The patch window is the thing that changed. The UK NCSC judged in 2025 that AI will almost certainly shorten the already short time between disclosure and exploitation. CISA's June 2026 directive now asks federal agencies to fix the most exposed, exploited and automatable flaws in three days.
• Old defences still work. Patching, inventory, MFA, least privilege and segmentation still reduce risk. What breaks is the idea that monthly patching is fast enough for internet facing systems.
• Use AI defensively, carefully. Inventory, triage, patch preparation and log review fit well; keep a human approval step on anything that changes production.

What is confirmed about autonomous AI attacks, and what is hype?

Four public cases from the past year give a fairly clear picture, and each has limits worth reading closely.

The e-commerce campaign reported by Reuters

On 19 October 2026 Reuters published an exclusive based on research by Snorre Fagerland, principal threat researcher at NorForge. Fagerland found the activity by scanning the internet for exposed copies of Cairn, an open source AI platform meant for authorized penetration testing. Operators had left their Cairn control panels open, so he could watch their projects in near real time.

• Scale. According to Reuters, a Chinese speaking operator began on 25 September and, by the week before publication, their agents had attempted more than 1,200 e-commerce sites in the US, Canada, Australia and Japan. They broke into websites of more than 100 companies. Reuters named three large companies among them; each gave a limited statement, and one said the affected site was run by a vendor. Two smaller businesses also confirmed compromises.
• Effort. The operator's instructions to the agents were under 100 Chinese characters. Reuters reports that successful intrusions typically took around 23 hours of trial and error.
• Cost. Fagerland estimated roughly $5,000 in tokens for the campaign, or about $50 per successful hack. The Hacker News adds his per task estimate of about $5, with considerable uncertainty.
• Success rate. The Hacker News reports an overall success rate of about 10 percent, noting that different clusters pursued different goals.
• What was taken. Reuters could not establish how much data, if any, was stolen.

Reuters describes agents that failed against one large company's main application, went looking for related infrastructure, found a public facing control panel with a subtle flaw in how it processed data, and spent hours getting the server to run their commands. The Hacker News summarizes one documented chain as unauthorized write access to a session store, unsafe handling of serialized objects, and a weakness in old framework code. In another case the agents found a cookie setting that routed requests to a vulnerable backend server. A typical goal was to plant a small file upload form, a web shell uploader, that would give persistent access.

Two details are uncertain. Reuters dates the campaign start to 25 September, while NorForge observed malicious Cairn instances from about 2 October; both can be true. And reports differ on which AI models drove the agents; The Hacker News notes that neither NorForge nor Reuters confirmed them. Fagerland told Reuters he had assumed agents would still need supervision and that it was now clear they do not. That is one expert's read of one campaign, a fair warning rather than a measured rate.

The Asia campaign

Our post on the AI agent intrusion campaign across Asia covers an operator who ran Cairn based agents on 66 intrusion projects from late September to mid October 2026. The operator's own records, only partly corroborated, show 48 reaching session level access. Entry points were again mostly old flaws and defaults, including a 2010 application server flaw and default admin credentials on a management console.

The honeypot agent

On 21 October 2026, Infosecurity Magazine reported that Symantec's Threat Hunter Team, using a decoy AI service as a honeypot, captured a malicious agent's full instruction set. The agent was designed to carry out up to 100,000 actions without human approval, with about 74 tools for reconnaissance, exploiting common web frameworks, stealing databases, harvesting credentials and managing botnets. A core goal was LLMjacking: using exposed model endpoints, AI gateways and MCP servers without paying.

According to Infosecurity Magazine, Symantec said none of the techniques were new, but combining them into one self directed agent lowers the skill needed for broad exploitation campaigns.

The 2025 espionage case

In November 2025 Anthropic published an account of a campaign it detected in mid September 2025 and attributed, with high confidence, to a Chinese state sponsored group. The attackers built a framework around Anthropic's model and used AI for roughly 80 to 90 percent of the campaign. Humans chose targets and stepped in at perhaps four to six critical decision points per campaign. Around thirty organizations were targeted, and the attackers succeeded in a small number of cases.

Anthropic also reported limits: the model sometimes hallucinated credentials and claimed to have extracted secrets that were in fact public, an obstacle to fully autonomous attacks.

What the research said before any of this

In February 2024, Richard Fang, Daniel Kang and colleagues showed that an agent built on a frontier model could carry out attacks such as SQL injection against test sites without being told the vulnerability in advance. Open source models of that time could not. Two months later the same group showed that an agent exploited 87 percent of a set of 15 real one day vulnerabilities when it was given the CVE description, and 7 percent without it.

That pair of numbers is the key finding: agents got good early at turning a published advisory into a working attack. Finding a new flaw alone was much harder.

Confirmed versus hype

What do these agents actually do?

The agents in these reports do the same work a human attacker does. They just do it in parallel, at all hours, and without getting bored. Breaking the work into stages makes it easier to see where each defence applies.

Why does this mostly speed up attacks on known, unpatched flaws?

There are three reasons, and they reinforce each other.

Known flaws come with instructions. An advisory names the product, affected versions and class of weakness. The 2024 research showed the effect: 87 percent with the CVE description, 7 percent without. An advisory turns a research problem into an engineering problem with clear feedback, which agents handle well.

Unpatched systems are abundant and stable. New flaws are rare and expensive; old flaws in old code sit on thousands of sites for years. The confirmed campaigns lived off exactly that. The UK NCSC's 2025 assessment says it plainly: by 2027, AI will almost certainly help threat actors exploit known vulnerabilities, increasing attacks against systems that have not been patched.

Agents reward volume. At about $50 per success and a 10 percent hit rate, the economics favour trying many targets with one playbook, and known weaknesses are what generalize across targets.

AI can find new flaws too. The NCSC judges that skilled actors with their own or fine tuned models will highly likely get better at zero day discovery. But for a typical company with a website, the practical risk is an AI finding the thing you already knew you had not patched, faster than you expected.

How does the gap between disclosure and exploitation change?

The time between a flaw becoming public and someone exploiting it was already short before agents. The NCSC's May 2025 assessment says that window has shrunk to days and that AI will almost certainly shorten it further. CISA's June 2026 directive says the same thing in policy language: threat actors exploit unpatched vulnerabilities, and their use of AI may further narrow the time defenders have to react.

Be careful with averages. Our post on whether time to exploit is really shrinking or the mix is changing explains why headline averages can fall partly because the sample includes more zero days. Either way, plan for the fastest case on your most exposed systems and measure your own time from disclosure to verified fix.

Agents also change coverage. A human operator had to choose where to spend time, so a flaw in a niche plugin might be exploited on big targets and never on small ones. An agent removes that triage. The small shop running an old plugin gets the same attention as the large retailer, because attention is nearly free.

CISA's response is a useful model even outside government. Binding Operational Directive 26-04, issued on 10 June 2026, replaced the older "fix every known exploited flaw in two weeks" rule with a risk based clock built on four questions:

1. Is the asset publicly exposed?
2. Is the CVE in CISA's Known Exploited Vulnerabilities (KEV) catalog?
3. Can an attacker automate every step of exploitation?
4. Does exploitation give partial or total control of the asset?

When the answers point to the worst case, the deadline is three calendar days, plus a forensic triage to check whether the system was already compromised, because applying a patch generally does not evict an attacker who is already in. Lower risk combinations get longer clocks or can wait for the next scheduled upgrade. CISA's own blog post on the directive reports that in one large agency's initial analysis, only 1 percent of vulnerability instances fell into the three day category and over 60 percent could be deferred.

The question "can an attacker automate every step?" is exactly what agents answer for attackers. If the answer is yes and the system faces the internet, your clock should be days. NIST's patch management guide frames patching as preventive maintenance, a routine cost of doing business; the AI era change is how short that routine has to be for exposed systems.

Which defences still work, and which assumptions break?

Most of the playbook is unchanged. What breaks are timing assumptions and a few comfortable shortcuts.

CISA's "Patch smarter, not harder" post adds that in core networks attackers more often use weak configurations and valid credentials than product flaws, and recommends hardened configurations, segmentation and phishing resistant MFA alongside risk based patching. Agents do both, so your defences must too. The OWASP Top 10 for 2025 reads like the agents' checklist: broken access control first, security misconfiguration second, software supply chain failures third. The classes have not changed; the speed of checking has.

Should we use AI agents defensively, and where?

Yes, in specific places, with a human approval step wherever an action changes something real. Anthropic advised defenders to experiment with AI in security operations, threat detection, vulnerability assessment and incident response. The UK NCSC warns of a widening gap between systems that keep pace with AI enabled threats and those that do not.

Where defensive agents earn their place:

Two warnings. First, the Reuters campaign ran on a legitimate testing platform, and The Hacker News reports that some legitimate testing firms also left client data on unsecured panels. If you run agent tooling, its control plane is part of your attack surface: keep it behind authentication and off the public internet. Second, a CSO Online analysis of 2026 agent containment failures quotes experts urging central governance, egress controls and the ability to trace every agent action to a person or process. Those rules apply to your defensive agents too. Our post on whether AI agents can escape their sandbox covers containment in depth.

What should a small team do this quarter?

A small team cannot match an attacker's agent hour for hour. It needs to remove the easy wins the agents depend on. Here is a 90 day plan for a team of two to ten engineers with a public website or app.

Weeks 1 and 2: know what you expose.

• List every public hostname, including support portals, staging and vendor run pages under your domain.
• List every service on a public address. Session stores, caches and databases should never be on it.
• Give each item an owner. Anything without one gets shut down or put behind authentication.

Weeks 3 and 4: close the credential gaps.

• Remove default accounts and passwords on every admin console and back office.
• Turn on MFA for every admin login, phishing resistant where supported.
• Rotate long lived secrets in config files and environment variables.

Weeks 5 to 8: set a patch clock you can keep.

• Write a rule modelled on CISA's: internet facing, known exploited and automatable means fixed within three days, with a compromise check. Other KEV listed flaws on public systems within 14 days; the rest in your normal cycle.
• Inventory the components in your applications and images and match them against the KEV catalog weekly.
• Remove plugins and old framework code you no longer use. The cheapest patch is deletion.

Weeks 9 to 12: make persistence hard and noisy.

• Block script execution in upload directories, and deploy from version control so unexpected files stand out.
• Centralize web and application logs, and give someone a weekly slot to read the summary.
• Add a CI gate so a known vulnerable version cannot come back.

None of this needs an AI product. These are the controls that stop the documented campaigns, on a shorter clock.

Step by step: shrink what an agent can find and use

The commands below are defensive. Run them only against systems you own or are authorized to assess. Adapt paths to your stack.

Step 1: List your public hostnames from certificate transparency

Certificates are public, so agents can read this list too. Read it first.

# Replace example.com with your domain
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' \
  | tr 'A-Z' 'a-z' | sed 's/^\*\.//' \
  | sort -u > hostnames.txt

wc -l hostnames.txt

Review it with whoever owns DNS. Staging, old campaign sites and vendor hosted pages are the usual surprises, and related infrastructure is where the Reuters case agents went when the main application held.

Step 2: Check what each server exposes

On each web server, list listening sockets and their bind addresses.

sudo ss -ltnp | awk 'NR>1 {print $4, $6}' | sort

Anything bound to 0.0.0.0 or [::] is reachable from every network the host is on. Look in particular for session stores and caches. The Hacker News describes one documented chain that began with unauthorized write access to a session store.

For Memcached, bind to localhost and turn off UDP in /etc/memcached.conf:

-l 127.0.0.1
-U 0

For Redis, in redis.conf:

bind 127.0.0.1 ::1
protected-mode yes
requirepass use-a-long-random-secret-here

Then confirm from another machine that the ports are closed, using a scanner against your own address only:

nmap -Pn -p 6379,11211,8000,9000 your.server.example

Ports 8000 and 9000 are worth checking because NorForge found exposed agent panels commonly on port 8000, and the Asia campaign's exposed server ran on port 9000. If you run any agent or testing tooling, it should not answer from the internet.

Step 3: Inventory your components

You cannot patch what you have not listed. Use your ecosystem's own audit tools and an SBOM based scan.

# JavaScript
npm audit --omit=dev

# Python
pip install pip-audit
pip-audit -r requirements.txt

# PHP, common on e-commerce platforms
composer audit

# Safeguard CLI: repositories, container images or existing SBOM files
safeguard scan --dir .
safeguard scan --image registry.example.com/storefront:3.8.1
safeguard scan --sbom sbom.cdx.json

The Safeguard CLI writes its results as JSON under ./output, matches components against vulnerability databases, and adds reachability analysis so you can see which vulnerable code paths your application actually calls.

Step 4: Cross reference with the KEV catalog

CISA publishes the KEV catalog as JSON. Matching it against your findings tells you which flaws are known to be exploited right now.

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' | sort -u > kev.txt

# Pull every CVE ID out of your scan results, whatever the tool's format
grep -rhoE 'CVE-[0-9]{4}-[0-9]{4,}' ./output npm-audit.json pip-audit.json 2>/dev/null \
  | sort -u > found.txt

# CVEs that are both in your estate and known exploited
comm -12 found.txt kev.txt

Each line is a candidate for the three day clock if the system faces the internet. KEV only lists flaws with reliable evidence of exploitation, so an empty result is not an all clear.

Step 5: Gate the build so fixed flaws stay fixed

A version you removed this week can come back with next week's merge. Add a check to CI.

name: dependency-gate
on:
  pull_request:
  push:
    branches: [main]

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: safeguard-sh/gold-scan-action@v1
        with:
          fail-on: kev

Start with fail-on: kev, which blocks only known exploited vulnerabilities, so you do not stop every merge on day one. Move to vuln once the backlog is under control.

Step 6: Lock down admin paths and upload directories

Agents look for control panels and try to plant upload forms. Two web server rules take away a lot of their options. In nginx:

# Only allow admin access from your office or VPN range
location ^~ /admin/ {
    allow 203.0.113.0/24;
    deny  all;
    try_files $uri $uri/ /index.php?$args;
}

# Never execute scripts from upload or media directories
location ~* ^/(media|uploads|pub/media)/.*\.(php|phtml|phar|pl|py|cgi)$ {
    deny all;
}

# Slow down repeated login attempts
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /admin/login {
    limit_req zone=login burst=5 nodelay;
    allow 203.0.113.0/24;
    deny  all;
    try_files $uri /index.php?$args;
}

Adjust paths for your platform, test in staging, then run sudo nginx -t and reload.

Step 7: Look for files that should not be there

If you deploy from version control, untracked files in a web root are a strong signal.

cd /var/www/storefront
git status --porcelain --untracked-files=all | grep '^??'

If you do not deploy from git, list recently changed script files and compare them against your last release:

find /var/www -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) \
  -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

NorForge advises looking for unexpected file upload forms in hidden directories, according to The Hacker News. If you find one, treat it as an incident: preserve the file and logs before removing anything.

Step 8: Read your logs the way an agent writes them

Agent driven intrusions in the Reuters case took close to a day. That leaves a long trail.

# Top client addresses in today's access log
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Requests that hit admin, upload or setup paths and did not get a 404
awk '$9 != 404 && $7 ~ /(admin|upload|setup|install|phpinfo)/ {print $1, $7, $9}' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -50

The goal is that someone reads a weekly summary, and that logs last long enough to answer "were we hit before we patched?", the forensic triage question CISA's directive now asks.

Common mistakes

• Treating AI attacks as a new category that needs a new product. The documented campaigns used old flaws and default passwords. Spend the first effort on patching and inventory.
• Patching the main site and forgetting the rest. Support portals, staging environments and vendor run pages under your domain are where the Reuters case agents went when the front door held.
• Leaving session stores and caches on public addresses. These services were often built for trusted networks and do little or no authentication by default.
• Assuming a WAF rule is a fix. It buys time. Agents retry with variations for hours. Patch behind it.
• Patching without checking for prior compromise. If an exploited flaw sat open on a public system, assume someone may have used it. CISA's directive pairs the three day fix with forensic triage for this reason.
• Running your own agent tooling on the open internet. Exposed control panels gave researchers a view into criminal operations. The same mistake gives attackers a view into yours.
• Letting a defensive agent push changes to production. Use pull requests, tests and a human approval step.

Fix it without waiting for upstream

Agents win on the time between "a fix exists" and "the fix is running in production", and on the flaws that never get a fix at all. Both gaps are where your patch clock lives.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Where Safeguard fits against agent driven attacks, and where it does not

Agents exploit what is known and unpatched. Safeguard's part is shortening the time from "CVE published" to "fix merged" for the software you build. safeguard scan --dir ., --image and --sbom match the components in repositories, container images and SBOM files against vulnerability databases, and the platform shows which projects contain a given component and version, so a newly KEV listed framework flaw is one search, not a round of emails. Reachability analysis puts the vulnerable code your application actually calls at the top of the list. Policies and gates evaluated in the platform stop known vulnerable versions from moving forward, and safeguard exec brings the same checks into CI. Griffin fix pull requests do the upgrade work, switched off until you turn them on.

The Safeguard CLI's assistant is a defensive agent of the kind described above. It edits code and runs commands with your approval, and /permissions lets you choose Ask, Accept edits, Plan, Auto (the default) or Strict, so a person stays in charge of anything that changes a repository.

What Safeguard does not do here: find forgotten subdomains, close an exposed cache port, remove default admin passwords, configure MFA or a WAF, detect a web shell on a running server, or patch a hosted platform or vendor appliance you do not build. Those steps belong to the walkthrough above and your hosting and identity tools. No tool would have guaranteed that the organizations in these reports stayed out of the news. What Safeguard can do is make your patch clock shorter and more honest. If you want to try the CLI, download it from safeguard.sh/download and read the CLI documentation.

FAQ

Can AI really hack a website by itself?

Mostly, yes. In the documented 2026 campaigns, agents did most of the reconnaissance and exploitation while a human set goals and occasionally steered. They fail often, but the human effort per break in has dropped sharply.

How many websites have been hacked by AI agents?

Nobody has a global number. The best public figures are for specific operators: Reuters reported one operator's agents attempting more than 1,200 sites and reaching websites of more than 100 companies, and a separate Asia campaign recorded 66 projects, with 48 reaching session level access by the operator's own count.

Are AI agents finding zero day vulnerabilities in websites?

The documented web campaigns relied on old and known weaknesses, misconfiguration and default credentials. The UK NCSC judges that skilled actors will highly likely get better at zero day discovery with AI, but for most organizations the immediate risk is faster exploitation of flaws that are already public.

How much does an AI hacking campaign cost?

NorForge's researcher estimated about $5,000 in AI tokens for the e-commerce campaign, or roughly $50 per successful break in, and about $5 per task. He described the estimate as uncertain.

Does a web application firewall stop AI agents?

It helps as a temporary shield while you patch. It is not a fix: agents try variations for hours, and a WAF does nothing about default passwords or exposed internal services.

How fast do we need to patch now?

For internet facing systems with a flaw that is known to be exploited and can be exploited automatically, aim for three days, which is what CISA now requires of federal agencies for that combination. Pair it with a check for prior compromise. Lower risk systems can stay on a longer cycle.

Should small businesses worry about AI hacking?

Yes, more than before. Agents remove the need to choose targets carefully. The fixes are the basics: patch quickly, remove what you do not use, turn on MFA and close exposed services.

Should we use AI agents to defend our websites?

Yes, for inventory, triage, log review, preparing patches and authorized testing of your own systems. Keep them read only where you can, route changes through pull requests and human approval, and never expose their control panels to the internet.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install it, open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow is how you would move a vulnerable library in a storefront or web app to its fixed version inside the three day window, with a person approving each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For this topic, it is the route when you want to inventory the components in your web applications and images on your own infrastructure, then match the results against the KEV catalog as in Step 4.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It is one practical answer to "should we use AI defensively?": an assistant that can read your vulnerability data and help triage, with access you scope yourself rather than an agent with free rein.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Reuters via CP24: How one hacker used AI agents and a few thousand dollars to break into scores of sites
• The Hacker News: autonomous AI agents used against e-commerce websites (20 October 2026)
• Infosecurity Magazine: Symantec research on a malicious AI agent and LLMjacking (21 October 2026)
• Anthropic: Disrupting AI espionage (November 2025)
• Fang et al.: LLM Agents can Autonomously Hack Websites (arXiv 2402.06664)
• Fang et al.: LLM Agents can Autonomously Exploit One-day Vulnerabilities (arXiv 2404.08144)
• UK NCSC: Impact of AI on cyber threat from now to 2027
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Patch smarter, not harder
• CISA: Known Exploited Vulnerabilities catalog
• CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities (revoked)
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• OWASP Top 10:2025
• CSO Online: AI agents aren't going rogue, frontier labs are skipping security basics
• Hacker News discussion of AI hacking reports

Last reviewed: 22 October 2026. Campaign figures come from researchers and reporters and may be revised; check the linked sources for updates.