Exhibit A(I): Agentic Intrusions Need an Operator Record

A reported Hermes-agent intrusion shows why agentic security controls need operator accountability, session evidence, and hard limits on unattended execution.

Exhibit A(I): Agentic Intrusions Need an Operator Record

A reported intrusion into Thailand's Ministry of Finance has the sentence every executive will remember: an AI agent helped automate the attack.

That is not the most useful sentence.

The useful sentence is this: an operator allegedly gave an agent objectives, tools, and an approval posture that let routine post-exploitation work continue without a human approving every command.

That is where the governance problem lives.

Why this belongs in Exhibit A(I)

BleepingComputer reports that Hunt.io and researcher Bob Diachenko found exposed directories tied to alleged activity against Thailand's Ministry of Finance.

The report says those directories contained exploit code, web shells, tunneling tools, custom scripts, stolen credentials, compiled payloads, and logs generated by the Hermes AI agent.

The Ministry has not publicly confirmed a breach in the reporting reviewed for this draft. Some artifacts reportedly showed targeting rather than confirmed compromise.

That caveat matters.

The legal and security lesson does not require turning every allegation into certainty. It requires asking what an organization can prove when an agent becomes part of the intrusion record.

If the record shows an operator used an agent to enumerate services, look for privilege-escalation paths, inspect containers, traverse file systems, and search web directories, then the question is no longer only, "Which host was compromised?"

The question becomes, "Who authorized the agent, what did it do, what did it touch, and what evidence survives?"

The old control model is too human

Most access-control programs still imagine a human with a keyboard.

Agentic tools break that mental model.

An AI agent can carry intent across a session. It can remember context, call tools, execute commands, summarize results, and continue a task while the operator steps back.

That does not make the agent independent in the moral sense.

It makes the operator record more important.

BleepingComputer describes the Hermes activity as operator-directed. The exposed logs reportedly showed instructions, environment details, and agent outputs, including unattended mode.

That is the part defenders should study.

A human attacker used automation to compress post-exploitation labor. The legal issue is not whether the agent had intent. The issue is whether the organization can reconstruct the chain of custody from human objective to automated action to system impact.

The evidence problem hiding inside unattended mode

Unattended agent execution is not automatically reckless.

It is also not ordinary automation.

A backup job does one narrow thing. A privileged agent can decide which commands to run next, which files to inspect, which outputs matter, and which path deserves another step.

That makes approval posture a control surface.

If a company uses agentic tools internally, it should be able to answer basic questions before a breach, not during one.

Which agents can execute commands? Which agents can reach production?

Which agents can read credentials, logs, tickets, source code, datasets, or personnel files?

Which sessions run in approval-required mode, and which run unattended?

If those answers live only in tribal knowledge, the organization does not have an AI governance program.

It has a vibes-based permission system with better tooling.

What counsel should ask this week

Start with the places where agentic tools already exist.

Do not limit the review to official AI products. Include developer workstations, security labs, SOC tooling, vulnerability-management scripts, internal automation platforms, cloud consoles, notebooks, and red-team utilities.

Then separate three records.

First, the identity record: which human, service account, API key, token, or machine identity launched the agent.

Second, the authority record: what the agent could execute, access, modify, download, or transmit.

Third, the session record: prompts, approvals, commands, outputs, files touched, environment variables exposed, credentials encountered, and follow-up actions.

Those records turn an agent incident from a mystery into a defensible timeline.

They also give legal teams the facts they need for privilege, notification, vendor-management, and board reporting decisions.

What to do this week

  1. Inventory every AI agent, coding assistant, automation agent, security copilot, and internal workflow tool that can call tools or execute commands.
  2. Label each one by execution mode: approval-required, limited unattended, or unrestricted unattended.
  3. Block unattended mode for agents that can reach production, credentials, regulated data, customer records, source repositories, or internal document stores unless a named risk owner approves it.
  4. Require durable session logging for prompts, tool calls, command output, files touched, approvals, and operator identity.
  5. Put agent logs in the incident-response evidence plan, not in a disposable developer cache.
  6. Test whether the organization can reconstruct one agent session from objective to command to impact.

The lesson is not that every AI agent is a breach waiting to happen.

The lesson is that agentic execution creates a new kind of operator record.

If you cannot preserve that record, you cannot govern the tool.

If you cannot govern the tool, you will not be able to explain what happened when it matters.

Sources