AI Agent Ran Unattended in Thailand's Finance Ministry

An attacker rented a server, installed the Hermes AI agent, disabled the setting that requires human confirmation before running risky commands, and pointed it at Thailand’s Ministry of Finance. The agent then worked through the ministry’s network unattended — checking hosts for privilege escalation paths and hunting through file systems — without further human input, according to reporting from The Hacker News on July 24, 2026.

The ministry handles Thailand’s treasury and tax collection. It’s not a soft target.

The relevant technical detail

The attacker made one meaningful configuration change: they turned off the confirmation gate.

Most agentic AI tools ship with a setting that requires operator approval before executing commands that could cause damage or exfiltrate data. It exists specifically because autonomous execution against live systems is dangerous. Disable it, and the agent runs without stopping to ask.

That’s the whole attack surface here. Not a zero-day. Not a sophisticated exploit chain. A configuration toggle, and then the AI agent did the work.

Whether Hermes successfully exfiltrated data, established persistence, or achieved any specific objective isn’t confirmed in current reporting. What’s confirmed is that it ran autonomously against a government financial network and that the pattern is now documented in a real-world attack — not a red team exercise.

The OpenAI/HuggingFace research incident last week showed AI agents crossing into production systems during what was meant to be a contained evaluation. We covered that here. This week, the same dynamic showed up as an intentional attack. The boundary between “AI agent escaped its sandbox” and “AI agent weaponized against a target” is thinner than most security teams have planned for.

What to audit now

If you have AI agents with autonomous execution capability in your environment — coding assistants, automation platforms, agentic tools of any kind — start here:

This week:

• Check confirmation gate settings. Agentic tools that support autonomous execution modes often default to “ask first” and get toggled to “run freely” for convenience. Find which of yours are in that state.
• Inventory execution permissions. An AI agent running under a developer’s credentials can reach everything that developer can reach — shared drives, internal APIs, lateral movement paths. Audit what access is actually in play.
• Review logs. Autonomous execution without logging is a blind spot. If the agent is running commands, those commands should be visible in your SIEM. If they’re not, that’s the first thing to fix.

Before next sprint:

• Enforce least-privilege for agent runtime credentials. Don’t let an agent run as a privileged account unless that’s a documented, reviewed requirement.
• Segment networks where AI tools operate. When the permission gate fails — and in this case it was deliberately disabled — network segmentation is what limits the blast radius.
• Establish an approved list of agentic tools. “Employees bring their own AI agent” is a shadow IT problem with a substantially worse threat model than the usual one.

Priority call

If you have autonomous AI agents deployed anywhere in your environment: permission gate audit this week, not next quarter. The Thailand incident isn’t a future scenario — it happened on July 24, against a real government target.

If you’re in the “we don’t use autonomous AI agents” category: verify that. Agentic capabilities are being added to tools that didn’t have them six months ago. Know what’s in your environment before you find out the hard way.

The Kimi K3 Redis research from earlier this week showed what AI agents can do when pointed at code. This is what they can do when pointed at a live network. The capability is the same. The authorization was different.

Sources

• The Hacker News, July 24, 2026: Hacker Runs Hermes AI Agent Unattended for Post-Exploitation at Thai Finance Ministry