DORA Didn't Account for an AI Agent Running in YOLO Mode

An AI agent ran a cyberattack on a finance ministry this week. Without a human approving a single command.

Between July 9 and July 13, 2026, threat intelligence firm Hunt.io discovered three exposed directories on a server hosted in Hong Kong. What they found inside changed how I think about the current threat landscape: 585 files, a custom Go-based implant the operators called Hades, and detailed logs from Hermes - an open-source AI agent - showing exactly what it did inside Thailand's Ministry of Finance network.

The agent scanned for kernel vulnerabilities. It mapped privilege escalation paths. It deployed web shells. It tested credentials against mail servers and internal administrative panels. It did all of this in what the Hermes documentation calls "YOLO mode" - a setting that removes the approval prompts that would otherwise require a human operator to say yes before the agent takes a dangerous action.

The Ministry of Finance has not confirmed the breach. But the operational artifacts are specific enough: system names, internal hostnames, IP addresses, and scripts targeting named internal services. The operation was real.

What Hermes Actually Did

Hermes was released in February 2026 by NousResearch. It is designed to operate as a persistent service that maintains context between task sessions and can interact with tools and execute commands to complete assigned objectives. That is a useful description of what defenders call an automated attack framework.

Five recovered Hermes call logs show the agent being used to: find privilege escalation opportunities, scan for kernel vulnerabilities, enumerate internal systems, test credentials, and maintain persistence through deployed web shells. The agent executed continuously. It did not take breaks. It did not make the same human mistakes that most anomaly detection systems are calibrated to catch.

The attack tool costs nothing. It is publicly downloadable. Its source code is on GitHub. Anyone with a target and an objective can configure it, enable YOLO mode, and run it against infrastructure. The barrier to deploying an autonomous post-exploitation agent has effectively reached zero.

The DORA Gap This Exposes

DORA has been in force since January 17, 2025. The regulation covers EU financial entities and requires comprehensive ICT risk management under Articles 5 through 14. The framework is detailed and well-constructed. The problem is the threat model that was in everyone's head when they built their DORA compliance programs.

Most ICT risk registers I review still describe threats in human terms: a threat actor targets a financial institution, moves laterally through the network, exfiltrates data. The assumed pace is human pace. The assumed behavior patterns reflect what human attackers do: variable timing, occasional mistakes, tool signatures that detection teams have learned to recognize.

AI agents operating autonomously look different. Machine-speed execution produces activity logs that look like consistent, scripted behavior rather than the variable cadence of a human operator. Detection rules tuned for human behavioral patterns may not flag what an AI agent does as anomalous, because the agent is not making human errors.

DORA's Article 10 requires monitoring and detection capabilities. Article 11 requires business continuity and response capabilities. Article 13 requires threat intelligence integration. None of these requirements are inconsistent with what I am describing - in fact, they mandate exactly the kind of capabilities that would detect and respond to an AI-assisted attack. The gap is not in the regulation. It is in the implementation.

The organizations that built their DORA programs by documenting existing controls and writing them up for regulators are the ones with the gap. The organizations that used DORA as a forcing function to actually rebuild their detection and response capabilities around the current threat landscape are in a different position.

Third-Party Risk: The Tool Your Vendor Uses

DORA's third-party risk provisions under Articles 28 through 44 are primarily focused on ICT service providers that financial entities rely on. Cloud providers, software vendors, data processors. The framework requires risk assessments, contractual protections, and concentration risk analysis.

The Thailand operation introduces a different third-party risk question that most DORA programs have not addressed: the open-source tools that attackers use, and by extension, the open-source tools that your own vendors and developers use.

Hermes was publicly released five months before it appeared in this operation. It is the kind of tool that security researchers, red teamers, and developers use regularly in legitimate contexts. It is also, as this week demonstrated, an effective autonomous attack platform. The same tool that a vendor's development team might run for automation testing could be configured with a target and pointed at financial infrastructure.

This is not a reason to prohibit all open-source tools. It is a reason to include open-source AI agent capabilities in your threat landscape assessment - both as an attack vector and as a source of third-party exposure through vendor environments.

What DORA-Regulated CISOs Should Do Now

Update the threat model in your ICT risk register. Add AI-assisted autonomous attacks as a named threat category. Document the specific characteristics that differentiate machine-speed attacks from human-operated attacks: execution pace, behavioral consistency, absence of human error signatures. Your risk register needs to reflect that this threat exists and is operational, not theoretical.

Review your detection logic for machine-speed behavior. Most SOC detection rules are calibrated against human baselines. Automated credential testing, rapid privilege escalation attempts, and systematic internal network enumeration at machine pace are patterns an AI agent produces routinely. Ask your security operations team specifically whether your current detection rules would flag high-speed, low-variance automated activity that does not match known attack tool signatures.

Include AI-assisted scenarios in your TLPT planning. DORA requires threat-led penetration testing for significant financial entities. The scenarios used in TLPT should reflect the actual threat landscape. Request that your red team include an autonomous agent scenario in the next testing cycle - specifically testing whether your detection and response capabilities can identify and contain machine-speed post-exploitation activity.

Add open-source AI agents to your third-party tool inventory discussion. The next time you review your vendors' security controls, include a question about open-source AI agent use within their development and operations environments. This is not about banning tools. It is about understanding the exposure surface.

Review your incident reporting readiness for AI-assisted intrusions. DORA mandates reporting of major ICT incidents within defined timeframes. An AI-assisted intrusion that moves faster than human-operated attacks may compress the window between initial compromise and significant impact. Your incident response playbooks should have runbooks specifically for fast-moving automated intrusions, with containment steps that do not assume a human attacker's pace.