The Attacker Gave the AI YOLO Mode. Thuban Gives the Machine a Veto.

Recovered logs from an alleged intrusion into Thailand's Ministry of Finance show something we haven't had to write about yet: an open-source AI agent, run unattended in what its logs label “YOLO mode,” automating the post-exploitation phase of the attack. Privilege escalation checks. Filesystem traversal. Service enumeration. Credential-related activity. Internal reconnaissance. Not one script kiddie mistake — a chain of actions, run by an agent with no human approving any of them.

This is not the story we've told so far. Every incident I've covered on this blog — the Hugging Face escape, the SharedRoot VM breakout — was an AI agent going wrong while trying to be helpful. This one is different in kind, not degree. Someone pointed an agent called Hermes at a national ministry's network, switched off the part where it asks permission, and let it run the intrusion.

What's actually been reported

Here is what's publicly known, without embellishment. Recovered logs show the Hermes agent running in an unattended, unsupervised mode — often called “YOLO mode” in agent tooling, where the human-approval step for tool calls is disabled and the agent executes autonomously. Under that mode, the logs show it automating: privilege escalation checks, filesystem traversal, service enumeration, credential-related activity, and internal network reconnaissance — the standard shape of a post-exploitation phase, run by software instead of a person typing commands.

There is evidence of access to multiple systems inside the ministry, of stolen credentials, of active session cookies, and of web shells left behind for persistent access. Investigators also identified a new cross-platform backdoor, named Hades, associated with the intrusion. The Ministry of Finance has not publicly confirmed a breach, and data exfiltration has not been established. I'm not going to speculate past that line, and neither should you — the facts that are confirmed are damning enough on their own.

What makes this categorically different from every other AI-agent incident I've written about: this was not an accident. Nobody left a coding assistant running overnight and it wandered somewhere it shouldn't have. Someone deliberately configured an autonomous agent, deliberately removed the human checkpoint, and deliberately pointed it at a target. The agent didn't go rogue. It did exactly what it was told, at machine speed, without anyone in the loop to say no.

Two threat models, one defence

For the last few months the AI-safety conversation has been almost entirely about agents making mistakes: overwriting the wrong file, escaping a sandbox, hallucinating a destructive command. Thailand's Ministry of Finance incident is the other threat model, and it's the one the industry has been slower to plan for — AI agents are no longer just writing code. They are already being used to run intrusions.

Here's the part that matters for anyone deciding what to actually build: those two threat models — the well-meaning agent that goes wrong, and the agent deliberately weaponized against a target — both cash out to the same requirement. Neither one is stopped by making the model smarter, more aligned, or better trained. Both are stopped the same way: by controlling what the agent can actually do on the machine it's running on, regardless of why it's trying to do it. An agent that has been given YOLO mode by an attacker and an agent that hallucinated a bad `rm` command hit the exact same wall if that wall exists. Intent doesn't matter to a policy engine. Only the action does.

Walking the kill chain through Shield

The reported Hermes kill chain reads like a checklist: enumerate the environment, escalate privileges, harvest credentials, move around internal systems, establish persistence, look for a way out. Look at what Thuban Shield's Phase 5 layers already do to each of those steps individually. None of this is hypothetical roadmap material — these are shipped components.

None of these layers depends on recognising Hermes specifically, or Hades specifically, or knowing the shape of this particular attack in advance. That's the point. Each individual step in the reported kill chain — a subprocess spawn here, a read of a credential file there, an outbound connection to an unfamiliar host, a directory walk outside scope — is the kind of thing that looks almost normal in isolation. An agent might legitimately need to spawn a subprocess. It might legitimately need network access. Any one signal alone is thin evidence. But the chain isn't thin. Enumerate, then escalate, then harvest credentials, then reach outward — that sequence, hitting multiple independent layers in order, is not what a benign coding agent's normal operation looks like. Each step is individually suspicious. The chain is conclusive.

Do not predict every attack. Constrain what consequences are permitted.

I want to be precise about what this argument is, and what it isn't. I am not claiming Thuban Shield would have specifically detected “Hermes” or specifically recognised “Hades” as named threats — we had never heard of either before this incident became public, and a signature-based defence that only works on names it already knows is worthless against the next unnamed tool. That's not the claim.

The claim is narrower and, I think, more durable: you cannot enumerate every AI agent that might someday be turned against a target, any more than antivirus vendors of twenty years ago could enumerate every future virus. What you can do is constrain what any agent — named, unnamed, well-intentioned, malicious, doesn't matter — is actually permitted to do on the machine it's running on. Don't try to predict the attack. Constrain the consequences that are possible regardless of which attack it turns out to be. A policy engine that blocks unauthorised subprocess spawning, unauthorised credential file access, unapproved network destinations, and out-of-scope filesystem traversal doesn't need to know Hermes exists to stop Hermes-shaped behaviour.

A new discipline, not a rebrand of an old one

This incident is a useful marker for something that's been forming for a while: AI agent runtime security is becoming its own discipline, distinct from generic cybersecurity and distinct from AI model safety. It's not about whether a model was trained well or aligned carefully. It's about what happens at runtime, on a real machine, once an agent — any agent, built by anyone, with any intent — has execution access and the ability to take actions with real consequences.

This isn't a category we're inventing to sell something. The OWASP Agentic AI Top 10 and the direction NIST's AI agent guidance is heading both point at the same gap: the industry has spent years securing models and training pipelines, and comparatively little time securing what an agent is allowed to actually do once it's running with tool access and a task. Thailand's Ministry of Finance incident is what happens when that gap gets used on purpose instead of stumbled into by accident.

Where that leaves us

The question is no longer whether AI agents can cause damage. It is whether yours is allowed to. That question doesn't change based on who's driving the agent or why. A developer's coding assistant with too much unsupervised access and an attacker's intrusion tool running in YOLO mode fail the same way, for the same underlying reason: nothing was watching what the agent was actually permitted to do on the machine, only trusting that it wouldn't do the wrong thing. One version of that story ends with an overwritten config file. The other one ends with recovered logs at a national ministry.

The attacker gave the AI YOLO mode — unattended, no approval gate, full speed. Thuban gives the machine a veto. Not a better model. Not more alignment training. A policy layer that doesn't care what the agent intends, only what it's about to do, and that says no regardless of whether the thing asking is a helpful assistant that made a mistake or a tool that was never supposed to ask permission in the first place.

npx thuban shield init