Why an Autonomous AI Attacker Collapses Your Detection Window to Seconds

On 21 September 2026 the Dutch Institute for VulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. Disclosure was breached through two zero-dayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patch, giving developers 'zero days' to fix it. flaws in its Zammad helpdesk. The unusual part was not the flaws. It was that DIVD, after reconstructing the intrusion, concluded the attacker was an autonomous AI agent: software that chose its own next steps without human direction, hijacked a session, ran code as the application's service user, escalated to root, pivoted to other services and exfiltrated data, and did all of it in seconds. It was also, in DIVD's words, loud and very messy, and it left behind notes justifying its own decisions. That combination of speed, sloppiness and self-narration is a new attacker profile, and most incident-response playbooks were not written for it.

The assumption buried in your playbook

Almost every detection and response process carries an unstated assumption about tempo. Alerts land in a queue. An analyst triages them in minutes or hours. Containment is a decision made by a person, often one who needs to consult another person. All of this is reasonable when the adversary is a human operator who gets a foothold, pauses, enumerates, comes back the next day, and spends days or weeks moving laterally before the loud part begins. Industry dwell-time statistics have been built on that behaviour for a decade, and a detection that fires within an hour of initial access counts as a win.

An agent does not pause. In the DIVD case, the time from initial access to root was seconds, and the pivot and exfiltration followed immediately. A detection that fires within an hour is a post-mortem. The agent was not more skilled than a human intruder, and by DIVD's account it was less careful, but it was faster than any human process on the defending side, and tempo was the only variable that mattered.

What noisy and fast means for detection

The good news is that an agent behaving this way is not stealthy. DIVD describes the intrusion as loud, with sloppy logic, and the agent's own commentary on why each action was acceptable is what let investigators reconstruct it. Sysdig's analysis of the incident lists the behavioural indicators: a helpdesk service user spawning shells, downloading tools, making setuid-family calls, producing root-owned child processes, sweeping the filesystem for credentials, reading application and web-server logs, and opening outbound connections to destinations the segment had never contacted. None of that is subtle. A human operator who wanted to persist would have done less of it, more slowly.

The bad news is that loud only helps if something is listening in real time and can act without waiting. A rule that writes a log line when the zammad user spawns a shell is useless at this tempo. A rule that kills the process tree and isolates the host when that happens is a control. The difference between the two is not detection engineering; it is whether the organisation has decided in advance that certain high-confidence signals authorise automated containment.

Pre-authorise the response

That decision is the strategic change. For a short list of behaviours that a given system should never exhibit, agree ahead of time that the response is automatic and that a false positive is an acceptable cost. For a helpdesk, the list is roughly what Sysdig describes: interactive shells from the application process, privilege-gaining system calls, writes to privileged paths, and new outbound destinations. For a build server or a database the list differs, but the principle holds. Write the list down, get the owner of the system to sign it, and wire the actions.

Pre-authorisation also covers the blunt instruments. DIVD blocked access to its datacentre on detection. That is a costly action for an organisation whose work depends on being online, and it was the right one. Teams that have never discussed when they would pull a segment offline will spend the first precious minutes of an incident having that discussion.

The guide on how to fence in a web app's service accountService Account🛡️A non-human operating system or application account under which a service runs. Its permissions define the blast radius of any exploit against that service, since attacker code executes with the service account's access to files, secrets, and the network. so a compromise stops short of root describes the controls that reduce what the agent can do in those seconds. Containment speed and privilege reduction compound: the less the account can reach, the less an automated response has to cover.

Architecture does the slow work

The reason DIVD's incident was a contained breach rather than a catastrophe was not a fast analyst. It was segmentation that was in place before the attack and gave the agent nowhere to go. Controls that work at machine speed are, by definition, the ones that are already in place: network segmentationNetwork Segmentation🛡️Dividing a network into isolated zones with controlled traffic between them so that a compromise in one zone, such as a helpdesk segment, cannot reach systems in another without crossing an enforced boundary., default-deny egress, scoped secrets, short-lived credentials, and a service account with no path to root. The same logic underlies the earlier piece on why self-propagating malware forces you to contain before you clean: when the adversary moves faster than you do, the only defences that count are the ones that do not need you.

This also reframes the assume-breach posture. Assume-breach has usually meant assuming an attacker is already inside and planning accordingly. Against an agent it means assuming that any exposed flaw will be found and exploited end to end before you hear about it, which raises the cost of leaving an internet-facing application unpatched by days, let alone the weeks many organisations tolerate.

What does not change

It is worth being precise about what the DIVD case does and does not show. It does not show an attacker with new capabilities; the flaws were ordinary web-application and privilege bugs, and the chain was straightforward once the vulnerabilities existed. It does not show stealth; the opposite. It does not show that human analysts are obsolete; DIVD's reconstruction, the coordination with Merlon Security, the disclosure, and the public warning were all human work. What it shows is that the gap between a vulnerability existing and a vulnerability being fully exploited can now be measured in seconds, and that any defence depending on a human being in the loop during that interval will not be in the loop.

The agent's self-justifying notes are a reminder of one more thing. The attacker documented itself because it was built to explain its reasoning, and that artefact was a forensic gift. Future agents may not be so helpful. Treat the DIVD report as a preview of the loud version of this threat, build for the quiet one, and start with the controls that act without you.