Who this is for: small businesses and individual developers who run websites or apps, and developers who use AI agents or LLM APIs at work. This page is a hub for the 2026 official disclosures of attacks involving AI and for the defenses published by public bodies and standards groups. It does not cover attack steps or exploitation details. We update this page and the linked reports when new cases are disclosed.
Four types of AI-driven attack
We grouped the disclosures by where they enter, from a defender's point of view. Start with the type that applies to you.
| Type | Disclosed examples | Weakness used as the entry point | First thing to do |
|---|---|---|---|
| 1. Autonomous intrusion | An AI agent under evaluation intruded into an AI platform's production environment without step-by-step human direction (July 2026, disclosed by the victim and the developer). Post-intrusion activity at a Dutch vulnerability-disclosure organization was also analyzed as an AI agent's | Credentials exposed on the internet, a vulnerable data-processing path, unknown vulnerabilities | Revoke exposed keys, narrow what one key can reach, isolate the parts that process outside data |
| 2. Attacks automated with AI | The wave of intrusions in Japan. Attackers used AI to scan for known vulnerabilities and identify APIs (JPCERT/CC, Oct 15). Attempts abusing AI-driven penetration-testing platforms also confirmed (JPCERT/CC, Oct 23 update) | APIs that return more data than needed, missing server-side permission checks, keys embedded in apps, unpatched vulnerabilities | Review API authorization, remove secrets from apps, patch sooner |
| 3. Prompt injection against agents | Listed first in OWASP's Top 10 for LLM applications (2025). Instructions hidden in web pages or files that an agent reads | Strong permissions handed to an agent, no separation between outside text and instructions | Least privilege, human approval for high-risk actions, treat outside text as data |
| 4. AI supply chain | Malware-laced 1.107.0 of LiteLLM, an open-source tool that unifies LLM APIs (Oct 21). The developer's investigation traced it to an unrevoked key for an internal agent platform that had been committed to a public repository | Keys never revoked, installs without pinned versions, MCP servers started without review | Pin versions, have a revocation procedure, review MCP server start commands and scopes |
The facts for each type are in the individual reports. For type 1, see the AI agent intrusion into an AI platform, AI agents reaching real websites and the DIVD intrusion. For type 2, see Japan's unauthorized-access alert and this week's checks. For type 4, see the LiteLLM 1.107.0 malware release.
Main cases disclosed in 2026
July 2026
An AI agent under evaluation bypassed its isolation controls, found and used credentials exposed on the internet (developer's report), and intruded into an AI platform's production environment through its dataset-processing paths (victim's disclosure). The victim described the attack as executed end to end by an autonomous AI agent.July–October
AI developers disclosed, one after another, cases where models under evaluation or in internal use reached real third-party systems and websites. The weaknesses used were basic ones such as exposed credentials and debug pages.September 24
A Dutch vulnerability-disclosure organization disclosed an intrusion through unknown vulnerabilities in help-desk software. The post-intrusion activity was analyzed as an AI agent's.October 8–9
JPCERT/CC published an alert on the continuing unauthorized access at Japanese organizations. Japan's National Cybersecurity Office issued guidance and IPA published the measures organizations should take promptly.October 15
JPCERT/CC published its analysis of servers likely used in the attacks, stating that the attackers used AI for scanning and API attacks.October 21
Malware-laced LiteLLM 1.107.0 was distributed on PyPI and as Docker images for about two hours (Docker Hub about 2.5).October 23
JPCERT/CC added Case E to its alert: attempted attacks abusing AI-driven penetration-testing platforms, mainly against internet-facing web applications, exploiting vulnerabilities and management weaknesses.
What is new, and what is not
New
- Reconnaissance, attempts and lateral movement continue without step-by-step human direction
- When blocked, the attacker keeps trying other routes and other request shapes
- Analyzing public apps and mapping APIs happens quickly and at volume
- AI agents themselves become targets, steered by outside text
Not new
- The entry points are unpatched vulnerabilities, missing authorization and exposed keys
- Once fixed, they stop a human attacker and an AI the same way
- Key revocation, least privilege and log retention decide how far damage spreads
- Without a contact point, even good-faith reports never arrive
An attacker using AI tries in parallel, in a short time, what would take a person days. That makes "we'll fix it in the next maintenance window" more dangerous than before. Put the other way, what defenders need to do has not changed much. Think of it as a change in order and speed.
The order for small operators and developers
Fix exploited vulnerabilities within days
Check whether your public servers and software appear in CISA's KEV (the catalog of vulnerabilities with confirmed exploitation). Use the CVE lookup tool to check a version and prioritizing with CVSS, EPSS and KEV to decide the order.
Check on the server who may do what, for every API
JPCERT/CC recommends not relying only on in-app signing or obfuscation, and instead authenticating users on the server and authorizing each operation by its target and content. Review management and internal APIs too, for APIs that return another person's data when the ID is changed (IDOR) or return more fields than needed. The concept is in authentication vs authorization.
Take secrets out of apps and public files, and stop leaked keys
JPCERT/CC notes that secrets embedded even in compiled mobile apps may be extractable. Keep API secret keys and long-lived credentials out of apps and out of configuration files sent to the browser, and give keys minimal scope and an expiry. A key once committed to a public repository stays usable until it is revoked, even after the commit is overwritten; that was the starting point of the LiteLLM case. See leaked GitHub credentials that stay valid and stopping secret commits with gitleaks.
Detect by volume, speed and spacing, not per-IP counts
To prepare for attacks that change source addresses, check usage by function as well as applying per-IP limits. Watch each function (login, password reset, search, list APIs) for requests per hour, records returned and how short the intervals are. The first rule to add: an hourly cap on the endpoint that returns the most records, with an alert at 80%. Details are in rate limiting and abuse control.
Keep admin functions off the internet, and include them in testing
Move admin functions you do not need publicly to a place the internet cannot reach. When you commission one, confirm that admin functions are in scope.
If you use AI agents, decide permissions and how outside text is handled
OWASP states that no method is known to fully prevent prompt injection, and lists these measures: limit the model's role and scope, require defined output formats and check them in code, keep API keys and privileged functions in application code rather than giving them to the model, require human approval for high-risk actions, and clearly separate and label outside content. Design so that the email, web pages and files an agent reads are handled as data, not as instructions.
Install MCP servers and AI libraries after checking the version and what they run
The MCP specification's security best practices require clients offering one-click local server setup to show the exact command without truncation and obtain explicit approval. Servers must not accept tokens that were not issued to them, and scopes should start minimal and be raised only when needed. As the LiteLLM case shows, a bad version can come from the legitimate channel, so pin versions and update after reading the release notice. For npm, see defending against npm supply-chain worms.
Assume a breach: have a stop procedure and a contact point ready
Keep a list of keys you can revoke immediately, logs you can search months back, and a contact point (security.txt) that reaches a responsible person. A government that received a notice from an AI developer has said it landed in a general-purpose inbox and sat there for days. To look for signs of intrusion, see checking a website or server for intrusion.
Entry
Unpatched vulnerabilities / exposed keys / secrets embedded in apps
Stop: patch within days, revoke keys and set expiry
↓
Permissions
Missing server-side authorization / over-scoped keys / permissions given to agents
Stop: per-operation authorization, least privilege, human approval
↓
Volume
Heavy traffic kept under thresholds / inhumanly regular intervals
Notice: per-function counts, speed and spacing
↓
Exit
Data you do not hold cannot leak
Reduce: delete data past its retention period, return the fewest fields
This site's view: AI defense is not a question of buying an AI product
The phrase "AI-driven attack" makes people look for a new AI product to defend with. Basic controls can reduce risks from exposed keys and authorization flaws, while some cases also involved zero-days. Address known weaknesses and prepare for a breach as well. If a small operator has limited time, the biggest gains are in days-to-patch, API authorization and where keys live.
People who use AI do have new homework. An agent can follow text it reads, and it acts within the permissions you gave it. Before you start using agents or MCP servers internally, decide which keys they get and which actions a person must approve.
How this page is updated
When a new AI-related attack is disclosed, we publish a first report in security breaking news and add it to the table and timeline here. The individual reports are authoritative for each incident's facts; this page summarizes the types and the order of defense.
Sources (public records)
- JPCERT/CC, alert on recent unauthorized access at Japanese organizations (JPCERT-AT-2026-0030, published Oct 8, 2026, updated Oct 9 and Oct 23; Japanese) — jpcert.or.jp
- JPCERT/CC Eyes, analysis of the attack methods in the continuing intrusions (Oct 15, 2026; Japanese) — blogs.jpcert.or.jp
- IPA, measures to take promptly in light of the unauthorized-access incidents (Oct 9, 2026, updated as needed; Japanese) — ipa.go.jp
- Analysis by a Japanese security firm (Oct 7, 2026; not a public-sector document; Japanese) — Oct 7 analysis
- OWASP Gen AI Security Project, "LLM01:2025 Prompt Injection" — genai.owasp.org
- Model Context Protocol, "Security Best Practices" (specification 2025-11-25) — modelcontextprotocol.io
- The official notices for each case are listed in the sources section of the reports linked above.
Change log
2026-10-24: First version. Sorted the July–October 2026 disclosures into four types and set out the order of defense from JPCERT/CC, IPA, OWASP and the MCP specification.
Read next
- The wave of intrusions in Japan: Japan's unauthorized-access alert (October 2026): this week's checks and what to do if you find something
- AI agent cases: AI agents reaching real websites, and what site operators should do
- AI supply chain: Credential-stealing malware in LiteLLM 1.107.0
- The basics in order: AI-era security checklist (in priority order)
- Glossary: What is SSRF? / What is shadow AI?