High
High: attackers have used AI in real intrusions to reach internal data and cloud keys, and it applies to any organization with internet-facing tools. How we rate severity
Agentic AI cyberattacks: attackers hand the steps after break-in to AI agents
Researchers report attackers handing the steps after break-in to AI agents, in one case reaching a database in about an hour. Retest human-pace response plans.
What happened
Two public incident reports from 2026 describe agentic AI cyberattacks in which attackers handed the steps after initial access to AI agents.
On May 26, 2026, Sysdig’s Threat Research Team described an intrusion it observed on May 10 that it says was “driven by a large language model (LLM) agent in its post-exploitation phase.” According to Sysdig, the attacker got into an internet-reachable marimo notebook through a known vulnerability (CVE-2026-39987), took two cloud credentials from the host, used them to retrieve an SSH private key from the cloud provider’s secrets manager, and then exfiltrated the schema and full contents of an internal PostgreSQL database through a bastion server. Sysdig says the full chain “ran end-to-end in under one hour,” that the database phase took under two minutes, and that cloud API calls were spread across many IP addresses within seconds to evade per-source detection. Sysdig’s published timeline runs about 69 minutes from first access to the end of the database dump. Sysdig calls it the first AI-agent-driven intrusion its team has captured.
In September 2026, the Dutch Institute for Vulnerability Disclosure (DIVD), a volunteer-run security organization, reported that it “got hacked through AI agents.” In its casefile, last updated October 9, DIVD says an attacker breached the Zammad ticketing system it uses for its CSIRT mailbox using two then-unknown vulnerabilities, and after gaining root “used AI agents for the further attack.” DIVD bases the AI-agent assessment on the volume of activity and artifacts in a short period, and on attack scripts that were commented and documented as if agents were talking to each other. DIVD reports that Zammad has since fixed both flaws. DIVD publishes its own metrics: an alert within 19 minutes, 19 hours to mount a first response, and a further 9 hours to carry out the containment plan.
Why it matters to leaders (our analysis)
The two cases began differently. Sysdig’s attacker used a known flaw in an internet-facing tool, and the damage came from credentials sitting where an intruder could find them. DIVD’s attacker used two then-unknown Zammad vulnerabilities, which Zammad has since fixed. What the cases share is the pace. When an agent runs the steps after initial access, the window between “someone got in” and “data is gone” can be shorter than the time it takes to assemble a response team.
For leaders, that turns patching, credential hygiene, and segmentation into speed problems as well as hygiene problems, and makes time to detect and contain a metric worth reporting. DIVD’s openness about its own numbers is a useful model: measure them, publish them internally, and test them against an attack that finishes in about an hour.
What to tell your board
Attackers are using AI to move faster once inside, so we are retiring exposed tools, separating key systems, and testing how quickly we can detect and contain an intrusion.
What your board will ask
- If an attacker got in through one internet-facing tool today, how long would it take us to notice and contain it, in minutes, not days?
- Which internet-facing tools, such as notebooks, helpdesks, and ticketing systems, hold credentials or sensitive conversations, and who owns them?
- Are any of our internet-facing systems running versions that are out of support?
- When did we last test our incident response against an attack that moves at machine speed?
Controls that help
- Keep an inventory of internet-facing tools, including data-science notebooks, helpdesks, and ticketing systems. Patch or retire out-of-support versions, and take exposed admin and terminal features offline. ISO/IEC 27001:2022 A.8.8 Management of technical vulnerabilities
- Keep cloud credentials, API keys, and SSH keys off exposed hosts, and rotate anything a compromised host could reach. NIST CSF 2.0 — PR.AA
- Segment networks so one compromised application can't reach internal databases or bastion hosts directly. ISO/IEC 27001:2022 A.8.22 Segregation of networks
- Alert on bursts of automated activity, such as many cloud API calls from rotating addresses in seconds, rather than only on single-source indicators. NIST CSF 2.0 — DE.CM
- Measure time to detect, respond, and contain, and tabletop an intrusion as fast as the one Sysdig documented, whose published timeline runs about 69 minutes from first access to the end of the database dump. ISO/IEC 27001:2022 A.5.24 Incident management planning
Download one-slide summary
Sources
Change log
- Oct 17, 2026. First published.
Coming soon
The weekly AI security briefing
The five AI risks security leaders should know, with the questions your board will ask. Signups open soon.
Signups open soon. We'll never share your email. See our Privacy Policy. Privacy Policy