From DMZ Escape to Full Network Access: How Hackers Could Use Hermes AI as an Autonomous Cyber Weapon

The Hacker Went Offline. The AI Agent Kept Working: How Hermes Could Change Post-Exploitation

A hacker does not necessarily need to sit in front of a compromised computer anymore.

They can potentially give an autonomous AI agent a goal, provide it with access to an environment, remove the human approval step for risky actions, and allow it to continue investigating while the operator is somewhere else.

That is what makes the recent use of Hermes Agent in an operation targeting Thailand’s Ministry of Finance significant.

But the story is not that “AI hacked a government.”

The more important development is this:

An attacker who already had access used an autonomous AI agent to perform portions of the repetitive work that normally requires a human operator.

The distinction matters.

Hunt.io’s investigation found exposed infrastructure associated with the operation, including attack tooling, web shells, stolen credentials and logs from Hermes. The Hermes logs showed the agent enumerating ministry hosts, traversing files and capturing LinPEAS output from another host. The investigation says the initial access method was not immediately evident from the recovered material.

The Hacker News separately reported that Hermes was operated in YOLO mode, allowing it to run without the normal approval prompts for potentially dangerous commands.

This makes Hermes interesting not because it is malware, but because it can function as something closer to an:

autonomous post-exploitation assistant.

1. What Is an Autonomous Post-Exploitation Assistant?

After an attacker obtains an initial foothold, much of the work is repetitive.

A human operator might have to:

  1. Understand the compromised machine.
  2. Identify the current user.
  3. Discover the surrounding environment.
  4. Determine what systems are reachable.
  5. Examine configuration and credentials.
  6. Understand privileges.
  7. Investigate interesting systems.
  8. Decide what to investigate next.
  9. Repeat.

Traditionally:

Human attacker
      ↓
Observe
      ↓
Run command
      ↓
Read result
      ↓
Think
      ↓
Choose next action
      ↓
Run command
      ↓
Repeat

An autonomous agent changes the loop:

Human attacker
      ↓
Give agent a goal
      ↓
AI agent
      ↓
Observe environment
      ↓
Reason about findings
      ↓
Choose next investigation
      ↓
Use available tools
      ↓
Observe result
      ↓
Update understanding
      ↓
Choose another action
      ↓
Repeat

AI does not necessarily replace the hacker; it can replace much of the hacker’s keyboard work and repetitive investigation.

That is the important change.

2. What Actually Happened in Thailand?

The Thailand incident should be treated as the real-world example, not as proof that Hermes can autonomously conduct an entire cyberattack from beginning to end.

Hunt.io reported that between July 9 and 13, 2026, researchers found three exposed directories on a Hong Kong-hosted server containing hundreds of files and roughly 470 MB of attack tooling and stolen information. The material included exploit code, web shells, tunnels, custom scripts and stolen credentials targeting mail infrastructure and Apache Hadoop.

The infrastructure also contained Hermes logs.

Those logs showed the agent performing activities including:

  • host enumeration;
  • filesystem traversal;
  • privilege-related investigation;
  • LinPEAS output collection;
  • vulnerability-related investigation.

The attacker had already obtained access before Hermes entered the picture.

Therefore:

What we know

Attacker → initial access → Hermes → autonomous investigation

Not:

Hermes → magically compromises ministry

That distinction should be maintained throughout any discussion of this incident.

3. Hermes Was Not the Initial Weapon

This is perhaps the biggest misconception.

Hermes is an autonomous AI agent, not a traditional remote-access trojan.

The attack infrastructure reportedly contained other tooling, including web shells and a Go implant referred to by the operator as Hades.

That means the operation appears more like:

Initial compromise
       ↓
Existing attacker access
       ↓
Additional tooling
       ↓
Hermes
       ↓
Autonomous investigation

This is important because it changes how defenders should think about the threat.

The AI agent can be the operator’s assistant after the door is already open.

4. Why Was Hermes Interesting to the Attacker?

Hermes combines many capabilities that traditionally require several separate tools.

Its current documentation lists a broad tool registry including:

  • terminal execution;
  • process interaction;
  • file reading and editing;
  • browser automation;
  • web search;
  • persistent memory;
  • session search;
  • scheduled tasks;
  • code execution;
  • subagent delegation;
  • MCP;
  • vision;
  • image generation;
  • messaging integrations.

This combination is important.

Imagine giving a human analyst:

Terminal
+
Browser
+
File system
+
Web search
+
Memory
+
Automation
+
Messaging
+
Parallel workers

Then adding:

“You decide what to investigate next.”

That is the fundamental architectural shift.

5. How Can the Attacker Control Hermes?

Hermes can be operated through several interfaces.

Not every interface was necessarily used in the Thailand operation.

Direct interface

Attacker
   ↓
Remote access
   ↓
Hermes
   ↓
Terminal / Files / Browser

Messaging

Hermes currently supports numerous messaging platforms, including Telegram, Discord, Slack, WhatsApp, Signal, Email, Microsoft Teams, Matrix and others.

Conceptually:

Attacker
   ↓
Messaging platform
   ↓
Hermes Gateway
   ↓
Hermes Agent
   ↓
Tools

The important security detail is that the official Hermes documentation shows some messaging toolsets can have full tool access including terminal execution.

That means the messaging interface is not necessarily just a chat interface.

It can become a control surface for an agent with real execution capabilities.

API

Hermes also supports API-server access.

Conceptually:

External client
      ↓
Hermes API
      ↓
Agent
      ↓
Tools

Scheduled tasks

Hermes supports recurring and one-shot tasks and can deliver results to local files or configured platforms.

So:

Attacker
   ↓
Task configured
   ↓
Attacker disconnects
   ↓
Hermes wakes up later
   ↓
Performs task
   ↓
Reports result

This is where “unattended” becomes meaningful.

6. Persistent Memory Changes the Equation

Hermes has bounded persistent memory that can survive between sessions, along with session search.

Imagine an investigation that lasts several days.

Monday

Server A is associated with engineering.

Tuesday

Server A communicates with Server B.

Wednesday

Account C appears to administer Server B.

Thursday

Server B appears to support a production application.

The agent can potentially connect those observations.

The result becomes:

Machine
  ↓
Identity
  ↓
Application
  ↓
Dependency
  ↓
Business function

This is much more valuable than isolated command output.

It becomes an environmental memory.

7. Skills: The Agent Can Retain Procedures

Hermes has a skills system based on reusable knowledge documents. Skills can be loaded when needed and follow the agentskills.io standard.

For legitimate use:

“Remember how I perform this type of analysis.”

For an attacker, the theoretical implication is:

Procedures can potentially become reusable agent knowledge.

That doesn’t mean Hermes automatically develops hacking skills.

It means an attacker-controlled deployment could potentially preserve repeatable workflows rather than reconstructing them every time.

8. Scenario: The AI Becomes a Network Scout

Imagine a compromised manufacturing engineering workstation.

The agent’s first task could conceptually be:

“Understand the environment available from this host.”

It could potentially gather information about:

  • the current host;
  • identity/context;
  • available resources;
  • applications;
  • reachable infrastructure.

The result might look like:

ENVIRONMENT SUMMARY

Host:
Engineering workstation

Observed:
• File infrastructure
• Engineering servers
• Authentication infrastructure
• Internal applications
• Management/jump infrastructure

Potentially sensitive:
• Engineering repositories
• Production documentation
• Administrative systems

The important part isn’t the raw data.

It’s that the agent can potentially turn raw observations into a prioritized explanation.

9. Scenario: Credential Discovery Becomes Credential Intelligence

Suppose the agent encounters information suggesting an application identity exists.

The important question is not merely:

“What is this credential?”

It becomes:

“What does this identity represent?”

Conceptually:

Credential
    ↓
Identify account
    ↓
Identify application
    ↓
Identify associated systems
    ↓
Understand permissions

That creates an important defensive signal.

An unusual AI-agent process accessing:

Credential/configuration files
          +
Network activity
          +
Remote-system investigation

is considerably more interesting than an AI agent merely reading a project document.

10. Scenario: Lateral-Movement Opportunity Mapping

Suppose:

Machine A
   ↓
Identity discovered
   ↓
Machine B appears reachable

The agent could potentially investigate whether the relationship actually works.

But:

credentials do not equal automatic lateral movement.

The chain still depends on:

  • valid credentials;
  • permissions;
  • network connectivity;
  • authentication;
  • MFA;
  • segmentation;
  • endpoint controls;
  • application authorization.

Therefore:

Machine A
   ↓
Credential
   ↓
Permission?
   ↓
Reachability?
   ↓
Authentication?
   ↓
Access?

Any step can fail.

11. Scenario: Manufacturing and OT

Consider a fictional manufacturing environment:

Engineering workstation
          ↓
       File server
          ↓
    Engineering server
          ↓
       Jump host
          ↓
       OT network
          ↓
 ┌────────┼────────┐
 ▼        ▼        ▼
Historian SCADA Engineering

An autonomous agent could potentially help an attacker understand:

  • which network segment the workstation occupies;
  • what engineering systems are reachable;
  • which identities are associated with those systems;
  • what files/configuration information exists;
  • which systems appear important.

The agent could potentially produce an environment map.

But discovering an OT system does not mean it can control it.

OT environments may have:

  • segmentation;
  • jump hosts;
  • allowlists;
  • one-way controls;
  • specialized authentication;
  • firewalls;
  • engineering workstation controls.

The defensive goal is to break the chain before an IT compromise becomes an OT incident.

12. Scenario: Banking

Now consider a bank.

Initial foothold:

Employee workstation
        ↓
Corporate identity
        ↓
Internal applications
        ↓
Cloud resources
        ↓
Databases
        ↓
Financial systems

An agent could potentially help determine:

What can this identity reach?

Instead of returning thousands of raw observations, it might summarize:

100 systems observed
       ↓
25 potentially relevant
       ↓
8 sensitive
       ↓
3 apparently accessible

The value is prioritization.

The AI doesn’t need to discover a new vulnerability to be useful.

It can reduce the human effort required to understand a complicated environment.

13. Scenario: Healthcare

A compromised hospital workstation could potentially expose relationships involving:

Clinical workstation
        ↓
Identity systems
        ↓
Clinical applications
        ↓
File infrastructure
        ↓
Imaging systems
        ↓
Administrative systems

An autonomous agent could potentially help classify:

  • sensitive data;
  • important systems;
  • identities;
  • application relationships;
  • infrastructure dependencies.

The consequences could include:

  • patient-data exposure;
  • operational disruption;
  • credential compromise;
  • ransomware preparation.

Again, the agent does not automatically defeat MFA or segmentation.

14. Scenario: Cloud Identity Becomes the Attack Map

Cloud changes the equation because the most important asset may be an identity rather than a physical machine.

Imagine an attacker gains access to a cloud credential.

The conceptual investigation becomes:

Cloud identity
      ↓
IAM permissions
      ↓
Accessible resources
 ┌────────┼─────────┬───────┐
 ▼        ▼         ▼       ▼
Storage Compute Database Secrets

The agent could potentially help interpret those relationships.

For defenders, this makes least-privilege IAM extremely important.

An identity with excessive permissions gives an autonomous agent a much larger search space.

15. Scenario: Browser Sessions

Hermes supports browser automation with local and cloud browser backends.

That means the agent can potentially interact with web applications rather than only local files and shells.

Consider:

Authenticated browser
        ↓
Internal application
        ↓
Cloud dashboard
        ↓
SaaS platform
        ↓
Business information

A browser-capable agent could potentially navigate those systems when it has authorized access through the browser environment.

This is different from saying:

“Hermes steals browser cookies.”

That is not what the documented capability means.

The important point is:

Existing authenticated application sessions can become part of an agent’s effective operating environment.

16. Scenario: Sensitive-Data Discovery

Imagine an organization has millions of files.

A traditional search might produce thousands of filenames.

An AI agent could potentially classify information semantically:

10,000,000 files
       ↓
AI classification
       ↓
2,000 potentially relevant
       ↓
200 sensitive
       ↓
20 highly valuable

Possible categories include:

  • financial information;
  • personnel records;
  • intellectual property;
  • engineering information;
  • source code;
  • contracts;
  • operational documentation.

This turns the AI into an information-triage system.

17. Scenario: Intellectual Property

Manufacturers often store their most valuable information in documents rather than databases:

  • engineering documentation;
  • product specifications;
  • design files;
  • testing information;
  • manufacturing procedures;
  • supplier information.

Suppose an attacker reaches an engineering repository.

Instead of manually reading thousands of documents, an AI agent could potentially help identify:

Which documents appear related to the company’s next-generation product?

Conceptually:

Engineering repository
        ↓
Document classification
        ↓
Product-related documents
        ↓
Sensitive subset

Again, the AI is functioning as an analyst.

18. Scenario: Ransomware Preparation

An autonomous agent does not need to encrypt anything to be useful to a ransomware operator.

The preparation phase may be more important.

Conceptually:

Initial access
      ↓
Understand environment
      ↓
Identify critical servers
      ↓
Identify business dependencies
      ↓
Identify backup infrastructure
      ↓
Prioritize systems

The attacker wants answers to questions such as:

Which systems are critical to production?

Which applications depend on which servers?

Where are recovery systems?

Which identities appear privileged?

An AI agent could potentially help organize this information.

The result is a ransomware reconnaissance assistant, not necessarily ransomware itself.

19. Scenario: Backup and Recovery Mapping

Backups are critical during ransomware attacks.

A compromised environment might look like:

Production
   ├── Applications
   ├── Databases
   ├── Backup servers
   └── Recovery infrastructure

An autonomous agent could potentially help identify those relationships.

This is why defenders should isolate backup infrastructure and protect it with credentials and network controls that are independent of ordinary production systems.

20. Scenario: DevOps and CI/CD

A developer endpoint can be a gateway into:

Developer
    ↓
Git repository
    ↓
CI/CD
    ↓
Artifact registry
    ↓
Cloud deployment
    ↓
Production

An autonomous agent could potentially help an attacker understand those relationships.

It could classify:

  • repositories;
  • build infrastructure;
  • deployment systems;
  • cloud resources;
  • configuration;
  • dependencies.

The dangerous part is not necessarily immediate exploitation.

It is understanding the software supply chain.

21. Scenario: Internal Documentation as Intelligence

Attackers don’t only learn from servers.

Organizations also expose architecture through:

  • wikis;
  • tickets;
  • README files;
  • runbooks;
  • project documentation;
  • incident reports.

An autonomous agent could potentially transform:

Documentation
      ↓
Application names
      ↓
Owners
      ↓
Infrastructure
      ↓
Dependencies

into an internal intelligence database.

This is why sensitive architecture documentation deserves security controls.

22. Scenario: Vulnerability Prioritization

Suppose an attacker observes:

20,000 assets
      ↓
2,000 vulnerabilities
      ↓
200 potentially relevant
      ↓
30 reachable/relevant
      ↓
5 high-priority

An autonomous agent could potentially help prioritize based on:

  • exposure;
  • system importance;
  • software;
  • identity;
  • network position;
  • business context.

The same capability is useful defensively.

This is an important theme:

AI can accelerate both cyber defense and cyber offense.

23. Scenario: Continuous Monitoring

Hermes supports scheduled automation, including recurring jobs.

Conceptually:

Environment
    ↓
Agent records state
    ↓
Wait
    ↓
Check again
    ↓
Compare
    ↓
Investigate changes

The agent could theoretically be used to monitor for:

  • new systems;
  • configuration changes;
  • newly accessible resources;
  • application changes;
  • infrastructure changes.

The presence of scheduled tasks is not itself malicious.

The security question is:

Who created the task, what can it access, and where are its results delivered?

24. Scenario: Multiple AI Investigators

Hermes supports subagent delegation. Its documentation describes child agents with isolated context and restricted toolsets.

Conceptually:

                    Hermes
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
     Agent A         Agent B        Agent C
   Identity          Files          Apps
   analysis          analysis       analysis
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                  Parent agent

This is parallelization, not self-replication.

That’s an important distinction.

The agent can potentially delegate work without creating a self-propagating malware organism.

25. Could It Deploy More Agents?

Potentially—but this requires careful wording.

There are four different concepts:

1. Subagent

Hermes delegates another AI task.

2. Tool execution

Hermes runs software that already exists.

3. Additional software deployment

If an attacker has sufficient privileges, an agent could potentially be used as part of deploying additional tooling.

4. Self-replication

The agent autonomously spreads through a network like a worm.

These are completely different.

The Thailand incident does not demonstrate autonomous self-replication.

A more realistic hypothetical is:

Attacker
   ↓
Hermes on Machine A
   ↓
Access discovered
   ↓
Machine B becomes reachable
   ↓
Additional tooling
   ↓
Agent/tool operates on B

But this requires the underlying environment to permit the action.

26. MCP Can Expand the Agent’s Reach

Hermes supports Model Context Protocol servers, allowing external tools to be connected to the agent. The official documentation describes MCP connections to systems such as GitHub, databases, filesystems, browser stacks and internal APIs.

Conceptually:

                    Hermes
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
    Terminal         Browser         MCP
                                      │
                             ┌────────┼────────┐
                             ▼        ▼        ▼
                          Database   GitHub   Internal API

This creates another security boundary.

Every external tool connected to an agent potentially expands what that agent can see or do.

Therefore:

MCP permissions should be treated like application permissions.

27. The Agent Can Potentially Become the Attacker’s Intelligence Analyst

This may ultimately be the most important use case.

Imagine the attacker has access to:

Files
Logs
Emails
Network observations
Cloud information
Documentation
Application information

The agent can potentially transform this into:

Raw data
   ↓
Classification
   ↓
Relationships
   ↓
Prioritization
   ↓
Attacker intelligence

Instead of thousands of observations, the human receives:

“These three systems appear most relevant.”

“This identity appears associated with those systems.”

“This application depends on this infrastructure.”

“These resources appear particularly sensitive.”

The agent becomes the analyst between the attacker and the compromised environment.

28. What If the Hacker Goes to Sleep?

This is where the Hermes incident becomes especially compelling.

A traditional attacker:

Hacker
   ↓
Command
   ↓
Wait
   ↓
Analyze
   ↓
Command

An autonomous operation:

Hacker
   ↓
Goal
   ↓
Hermes
   ↓
Investigate
   ↓
Reason
   ↓
Investigate
   ↓
Reason
   ↓
Investigate
   ↓
Report

The human can disconnect.

The agent can continue.

That is the operational difference.

29. Hermes vs OpenClaw vs NanoClaw

Hermes is not uniquely capable of agentic behavior.

OpenClaw and NanoClaw have overlapping capabilities.

The distinction is primarily architectural.

CapabilityHermesOpenClawNanoClaw
Autonomous agentYesYesYes
Persistent memoryYesYesYes
SkillsYesYesYes
Terminal/tool executionYesYesYes, inside container
BrowserYesYesWeb access supported
Scheduled tasksYesYesYes
SubagentsYesYesAgent swarms
MCPYesYesSupported
MessagingVery broadVery broadBroad
Self-hostedYesYesYes
Container isolationAvailableConfigurableCore design emphasis
Main emphasisAutonomous persistent workerBroad personal-agent ecosystemLightweight agent + isolation

OpenClaw’s current documentation describes tools such as exec, browser, web search, messaging, automation and multi-agent orchestration.

NanoClaw describes itself as a lightweight alternative that runs agents in separate Linux containers with filesystem isolation and only explicitly mounted directories exposed.

So the security question is not:

“Which one is the hacking AI?”

It is:

“Which architecture gives an agent the combination of autonomy, access, persistence and connectivity that an attacker needs?”

30. Why NanoClaw’s Architecture Matters

NanoClaw deliberately emphasizes container isolation.

Its documentation says agents run in containers and can only see explicitly mounted resources. It also describes credential handling through a credential proxy rather than placing raw API keys directly inside the agent container.

That changes the potential blast radius.

Conceptually:

NanoClaw
   ↓
Container
   ├── Agent
   ├── Tools
   └── Allowed files

       X
       │
       │
    Host system

The objective is:

If the agent is compromised, the container becomes a security boundary.

That doesn’t make NanoClaw immune to abuse.

It makes unrestricted host access harder by design.

31. Why Would an Attacker Choose Hermes?

There is no evidence that cybercriminals universally prefer Hermes.

But a self-hosted agent can offer characteristics attractive to an attacker:

Runtime control

The operator controls the environment.

Model flexibility

Hermes supports multiple providers and models.

Persistence

The agent can remain available.

Memory

It can retain context.

Skills

Procedures can be reused.

Scheduling

Tasks can continue without the operator being connected.

Subagents

Work can be parallelized.

Tools

Terminal, browser, files, web and external tools can be combined.

Messaging

The agent can be controlled through numerous communication channels.

Customization

An open-source runtime can be modified by its operator.

This doesn’t make Hermes malicious.

It makes it operationally flexible.

32. What Hermes Did NOT Demonstrate

A responsible investigation must clearly separate fact from possibility.

The Thailand incident does NOT establish that:

  • Hermes discovered the original vulnerability.
  • Hermes independently selected Thailand’s Ministry of Finance.
  • Hermes independently compromised the ministry.
  • Hermes compromised every system it discovered.
  • Hermes successfully exfiltrated all personnel data.

The strongest evidence instead shows an already-established attacker using Hermes to perform autonomous investigation.

33. A Four-Level Evidence Model

Every claim about agentic cyberattacks should be classified.

DOCUMENTED

Directly observed or reported.

Example:

Hermes was used in unattended mode in the Thailand operation.

SUPPORTED

Confirmed by official documentation or independent research.

Example:

Hermes supports persistent memory, scheduled tasks and subagent delegation.

POSSIBLE

Technically feasible based on documented capabilities.

Example:

An attacker with sufficient privileges could potentially use an agent to coordinate additional tooling.

SPECULATIVE

Future possibilities without current evidence.

Example:

A fully autonomous fleet of self-replicating AI agents taking over enterprise networks.

The last one should not be presented as today’s reality.

34. How a SOC Should Detect This

The biggest mistake would be:

“Search for Hermes.”

An attacker could use another agent—or rename the executable.

Instead look for behavior.

Process telemetry

Monitor unusual:

Agent
 ↓
Shell
 ↓
System discovery
 ↓
File access
 ↓
Network activity

Pay attention to parent-child relationships.

Credential access

Monitor unusual AI-agent processes accessing:

  • credential stores;
  • configuration files;
  • environment variables;
  • secrets;
  • cloud credentials;
  • browser-related data;
  • SSH material.

Network activity

Monitor:

  • connections to many internal hosts;
  • unusual east-west traffic;
  • new external destinations;
  • messaging platforms;
  • agent gateways;
  • unexpected API endpoints.

Persistence

Monitor:

  • cron;
  • scheduled tasks;
  • systemd;
  • services;
  • containers;
  • startup mechanisms;
  • unexpected long-running processes.

Hermes itself supports scheduled tasks, so a new scheduled Hermes-related task on an unexpected system is particularly worth investigating.

35. EDR Perspective

For an EDR such as CrowdStrike, don’t begin with:

“Is Hermes installed?”

Begin with:

“Why is this process behaving like an autonomous operator?”

Useful telemetry includes:

  • process tree;
  • command line;
  • network connections;
  • authentication;
  • file access;
  • credential access;
  • persistence;
  • remote-system connections.

A suspicious conceptual sequence is:

Unknown agent
     ↓
Shell spawned
     ↓
System discovery
     ↓
Credential/configuration access
     ↓
Connections to multiple internal hosts
     ↓
Remote access
     ↓
Persistence

The sequence is the signal.

36. SIEM Correlation

A useful conceptual detection could correlate:

Event 1

Unexpected AI-agent runtime

Event 2

Shell spawned

Event 3

Credential/configuration access

Event 4

Multiple internal hosts contacted

Event 5

External control channel

Event 6

Persistence mechanism

=

HIGH-RISK AGENTIC POST-EXPLOITATION PATTERN

This is much stronger than a simple:

“Hermes detected.”

37. What Stops the Attack?

The best defense isn’t necessarily banning AI.

It is limiting what an AI agent can reach.

Identity

  • phishing-resistant MFA;
  • least privilege;
  • PAM;
  • restricted service accounts;
  • short-lived credentials.

Endpoint

  • EDR;
  • application allowlisting;
  • agent-installation controls;
  • credential protection;
  • script controls.

Network

  • IT/OT segmentation;
  • east-west monitoring;
  • egress filtering;
  • restricted management interfaces.

Cloud

  • least-privilege IAM;
  • workload identity;
  • secrets management;
  • cloud audit logs.

AI-agent controls

  • human approval for high-risk operations;
  • sandboxing;
  • container isolation;
  • restricted filesystem access;
  • restricted network access;
  • tool allowlists;
  • MCP restrictions;
  • audit logging;
  • agent identity;
  • outbound destination controls.

The goal is:

Even if an autonomous agent is compromised or misused, it should not automatically inherit the keys to the enterprise.

38. The New Security Equation

The risk can be thought of conceptually as:

Autonomy × Access × Persistence × Connectivity × Privilege

Consider two agents.

Agent A

High autonomy
+
No credentials
+
Sandbox
+
No network
+
Read-only data

Potential impact: limited.

Agent B

High autonomy
+
Credential access
+
Terminal
+
Broad network access
+
Persistent memory
+
External communication
+
High privilege

Potential impact: dramatically greater.

The AI model may be identical.

The security boundary is not.

39. The Future Attack May Not Look Like Malware

This is perhaps the most important lesson.

Traditional malware:

Attacker
   ↓
Malware
   ↓
Command
   ↓
Action

Agentic operation:

Attacker
   ↓
Autonomous agent
   ↓
Observe
   ↓
Reason
   ↓
Act
   ↓
Observe
   ↓
Reason
   ↓
Act

The agent becomes a decision-making layer above the attacker’s tools.

That makes traditional malware-only detection insufficient.

Defenders need to understand the behavior of AI runtimes just as they understand the behavior of scripts, shells and remote administration tools.

40. The Most Important Scenario: One Machine Becomes Many Investigations

Imagine an attacker compromises one workstation.

Normally:

One machine
    ↓
One human
    ↓
Manual investigation

Now:

One machine
    ↓
Hermes
    ↓
Network mapping
    ↓
Identity analysis
    ↓
Application analysis
    ↓
Document analysis
    ↓
Cloud analysis
    ↓
Continuous investigation

And if subagents are used:

                    Hermes
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
     Identity        Files          Apps
     analysis       analysis       analysis

The attacker has effectively turned one compromised machine into an AI-powered intelligence platform.

That is the force multiplier.

41. The Real Threat Is Not “AI Can Hack”

AI agents are still imperfect.

They can:

  • hallucinate;
  • misunderstand environments;
  • choose irrelevant actions;
  • fail authentication;
  • get stuck;
  • trigger security controls;
  • misinterpret output;
  • waste resources.

They are not autonomous cyber-superweapons.

But that misses the point.

A human attacker doesn’t need the AI to be perfect.

If the agent can automate 60% of the boring work, the human can spend their time on the remaining 40%.

If the agent can operate while the attacker sleeps, the attacker gains additional operational hours.

If the agent can summarize thousands of observations, the attacker can understand a large environment faster.

If the agent can run parallel investigations, the attacker can potentially examine more paths simultaneously.

That is where the economics change.

42. The Bigger Security Shift

The important story is not:

“Hermes can hack a computer.”

The more accurate story is:

“Once an attacker has access, an autonomous agent can potentially turn a human-driven intrusion into a continuously operating investigation.”

The Thailand incident demonstrates the beginning of that model.

The broader capabilities of Hermes show where it could go.

And OpenClaw and NanoClaw demonstrate that this isn’t necessarily a single-product phenomenon.

The technology is moving toward agents that can:

remember, browse, execute, communicate, schedule, delegate and reason across multiple tools.

That combination changes the threat model.

Conclusion: What Happens When the Hacker Goes Offline?

Imagine this:

An attacker compromises one employee workstation at 10:00 PM.

At 10:15 PM, they give an autonomous agent a broad investigative objective.

The attacker goes offline.

The agent continues.

It examines the environment.

It identifies systems.

It analyzes identities.

It organizes information.

It discovers relationships.

It remembers what it found.

It potentially delegates parts of the investigation.

It can continue according to scheduled tasks.

At 8:00 AM, the attacker returns.

Instead of seeing:

“One compromised computer.”

they may see:

Environment mapped
       ↓
Systems categorized
       ↓
Identities understood
       ↓
Applications identified
       ↓
Potentially sensitive resources prioritized
       ↓
Further investigation paths identified

That is the real significance of autonomous post-exploitation.

The AI has not necessarily invented a new exploit.

It has changed how much work one attacker can perform.

The future security question therefore isn’t simply:

Can AI hack?

It is:

If an attacker only needs to compromise one machine, but an autonomous agent can spend the next 24 hours figuring out everything that machine can reach, how much has the cost of the attack fundamentally changed?

And that is why the Hermes incident matters.

Not because Hermes is a magical hacking tool.

But because it provides a glimpse of what happens when AI reasoning, persistent memory, real tools, credentials, network access and autonomy are combined inside an active intrusion.