How an AI Agent Exposed Its Hacker's Operation

An AI agent does not need to be tricked by malicious instructions hidden in a document or webpage, a technique called prompt injection, to cause a serious security failure. Sometimes it only needs to run an ordinary command from the wrong directory.

That is the most useful lesson in a recent investigation by Palo Alto Networks' Unit 42. Researchers documented a Chinese-speaking threat actor using DeepSeek through the open-source Hermes Agent framework as part of an offensive workflow. The agent searched for internet-facing systems, obtained public exploit code, checked targets, and attempted exploitation after receiving instructions through Telegram.

The autonomous attacks Unit 42 recovered did not compromise their intended targets. Then the operation suffered a different kind of failure. Hermes Agent started Python's simple Hypertext Transfer Protocol (HTTP) server from the operator's home directory. That exposed a workspace containing application programming interface (API) keys, exploit scripts, target lists, shell history, tool configurations, and agent session logs, giving the researchers the evidence they needed to reconstruct the campaign.

The irony is memorable, but it should not obscure the engineering lesson. The model was never the only security boundary. Once an agent can use a terminal, the meaningful boundary is the environment that determines what its process can read, change, execute, and expose.

Unit 42 attributed the operation to an actor using the aliases knaithe and KnYuan. The actor connected DeepSeek to Hermes Agent, which supplied terminal access, persistent skills, and a Telegram gateway. A Model Context Protocol integration connected the system to FOFA, a search engine for internet-facing infrastructure, and to the Nuclei vulnerability scanner.

In one recovered session from May 7, 2026, Unit 42 found no further operator input after the initial task. The agent first downloaded a public proof of concept, or demonstration exploit, for a Langflow vulnerability. It found 84 exposed instances and identified one system running an affected version. The exploit still required a configuration condition that the target did not provide, so the attempt failed.

The agent then pivoted. It searched for other public exploits, compared product footprints and vulnerability severity, and selected an n8n exploit chain. It found systems running vulnerable versions and probed more targets, but the exposed forms required authentication. That attempt failed too.

This distinction matters. Unit 42 found a functional workflow for autonomous reconnaissance, exploit acquisition, target filtering, and attempted exploitation. It did not report a successful autonomous compromise in the recovered sessions. The confirmed data theft and command execution described elsewhere in the report came from separate manual activity by the operator.

That is already significant without inflating the result. The system automated several steps that normally require a person to search, compare, download, test, and decide. It also made a mistake at machine speed.

The command at the center of the exposure was simple:

Python includes this server as a convenient way to share files. According to the Python documentation, it serves the current working directory unless another directory is specified. It also binds to all network interfaces by default unless the user supplies a narrower address, such as 127.0.0.1 for local access only.

Unit 42 reports that Hermes ran the command from /home/worker, the operator's home directory, instead of an isolated staging directory. The server therefore exposed the files beneath that location to systems able to reach the host and port.

Nothing about this required a novel vulnerability in Python. The server did what it was designed to do. The danger came from three pieces of context around it:

A command filter could easily consider a temporary file server less dangerous than deleting a directory or changing a firewall. In this environment, however, it had the larger consequence.

This is why agent security cannot end with a list of prohibited commands. A command's effect depends on the working directory, mounted files, process identity, environment variables, network isolation, and current state of the system. The same command can be harmless inside an empty container and disastrous inside a home directory full of credentials.

The offensive agent needed substantial capabilities to do its assigned work. It needed to query external services, download code, run scanners, inspect results, and execute commands. That does not mean it needed every file and credential available to its host process.

This is a familiar security principle with a new interface. The principle of least privilege says that a process should receive only the access required for its task. Agent frameworks make violations easier to miss because a flexible natural-language interface can sit in front of a highly privileged shell. The experience feels like asking an assistant for help, while the operating system sees a process with whatever permissions the operator gave it.

The Open Worldwide Application Security Project's (OWASP) guidance on Excessive Agency divides the problem into excessive functionality, excessive permissions, and excessive autonomy. The Unit 42 case touches all three. A general terminal could create a network service. The process could reach sensitive files. No deterministic boundary prevented those files from being served.

The important word is deterministic. A model can be instructed to avoid secrets, and an approval system can ask a human about commands it recognizes as dangerous. Neither replaces operating-system controls that make a forbidden action impossible.

The right design assumption is not that an agent will always choose badly. It is that any sufficiently active system will eventually choose a technically valid action in the wrong context. The runtime should make that mistake survivable.

Start with a task-specific workspace. An agent generating a report should see the input data and an output directory, not the operator's entire home folder. Secure Shell (SSH) keys, browser profiles, shell history, unrelated repositories, and persistent logs should remain outside the mounted filesystem. If the agent starts a file server from the wrong location, there should be little worth stealing.

Use an isolated execution backend for general commands. A container or virtual machine can restrict filesystem access, process capabilities, and network reach. Current Hermes security documentation describes its local backend as having no isolation and recommends Docker or other sandboxed backends for production gateway deployments. That guidance should not be read as an explanation of the 2026 incident's exact configuration, which Unit 42 did not publish. It does show what a stronger present-day boundary looks like.

Isolation can still be undermined. A container that mounts the host's home directory has inherited the original filesystem problem. A sandbox that receives a long-lived cloud token can still leak it. Hermes' documentation explicitly warns that environment variables forwarded into a container can be read and exfiltrated by code running there.

Credentials therefore need their own boundary. Prefer short-lived tokens with narrow scopes, delivered only to the action that needs them. A research step that queries an asset database should not automatically receive a source-control token, cloud administrator key, or messaging credential. Removing a secret from the prompt is not enough if it remains readable from a file or environment variable.

Network policy is equally important. Agent sandboxes should not be able to open inbound listeners or contact arbitrary destinations merely because the host can. Bind local services to the loopback address by default so only the same machine can reach them. Require an explicit policy decision before exposing a port, reaching a new domain, or sending data outside an approved channel.

Finally, place approvals at consequence boundaries. A useful policy asks whether an action will publish data, read a protected path, open a listener, modify production, or use a privileged credential. It does not rely only on whether the command string resembles a known destructive pattern. Microsoft's agent security guidance reaches a similar operational conclusion: scope permissions, govern tools, monitor agent behavior, and test workflows under adversarial conditions before deployment.

These controls do not solve every agent-security problem. A sandbox can contain the wrong assets. An approved network destination can still be compromised. A narrow tool can contain an authorization flaw. Logs can miss the event that matters, and frequent approval prompts can train people to click through them.

Containment also does not make model output correct. It limits what an incorrect or manipulated decision can damage. That distinction is important. Model safeguards, prompt-injection defenses, tool validation, authorization, and runtime isolation solve different parts of the problem. They should reinforce one another.

The Unit 42 report also has an evidence limitation. Its findings come from one vendor investigation, and the underlying session logs are not public. The exact Telegram instruction, Hermes version, and decision path that placed the server in /home/worker cannot be independently reviewed. The case demonstrates a plausible and concrete failure mode, not how frequently it occurs.

It is still a valuable design test because it asks a question that does not depend on accepting a forecast about artificial intelligence: If this agent runs one valid command in the wrong directory, what can it read, expose, modify, or send?

That answer describes the agent's real scope of damage, often called its blast radius. A secure deployment makes it small before the model takes its first action.