The AI Agent Security Guide Nobody Made: Docker Sandboxing, Secrets, and Prompt Injection (July 2026)

Bottom Line (July 2026)

• The risk is real and it is boring. Not exotic exploits — an agent with shell access reading a web page that contains instructions written for the agent.
• Docker isolates the filesystem you did not mount. Every -v is a deliberate hole. Mount one project directory, not your home directory.
• A separate machine beats a VM beats a container. A used Mac mini running the agent and nothing else is the cheapest real isolation there is.
• Never paste an API key into a chat with the model. Env file, chmod 600, one scoped key per agent, rotate anything that has been on screen.
• Treat fetched content as untrusted input, never as instructions. Web pages, emails, and PDFs the agent reads are data, not orders.
• Put a human gate on send, publish, pay, and delete. Read-heavy autonomy is fine. Irreversible autonomy is where people get hurt.
• Snapshot before you update. Agent updates have broken working setups more than once this year.

The Threat Model in One Paragraph

An AI agent is a program that reads text from the internet and then runs commands on your computer. That is the whole thing. Everything else follows from it.

The model cannot reliably tell the difference between “instructions from my user” and “text that appeared in a document I was asked to read.” Both arrive as tokens in the same context window. So when your agent fetches a web page during a search, that page’s content becomes part of what is steering it. This is what people mean by prompt injection, and it does not require anyone to break into your machine — it only requires you to ask the agent to read something.

This is not hypothetical. There were widely reported cases this year of vendor pages carrying instructions aimed at AI agents, embedded in the HTML where a human visitor would never see them. In several cases the agent noticed and flagged it to the user, which is the good outcome; you should not plan around getting the good outcome every time.

The practical consequence: your defense is not “make the model resist manipulation.” Your defense is containment — make sure that an agent that has been successfully steered still cannot reach anything that matters.

Layer 1: What Docker Actually Isolates

The most common question in agent tutorial comments is some version of “does the Docker container keep it totally isolated?” The honest answer is: it isolates a lot, and the parts it does not isolate are exactly the parts you configured.

Docker does isolate:

• The filesystem, apart from what you explicitly mount. The agent sees the container’s filesystem, not your Mac’s.
• The process tree. Nothing in the container can see or signal processes on your host.
• Installed packages. The agent installing something weird affects the container, not your machine.

Docker does not isolate:

• Anything you mounted. -v ~:/home/agent gives the agent your entire home directory: SSH keys, browser profiles, tax documents, everything. This is the single most common mistake.
• Your network, if you run with --network host. That puts the agent on your LAN with reach to your router admin page, your NAS, and every other service on the network.
• Secrets you passed in. Environment variables inside the container are readable by anything inside the container. If you passed in every key you own, the container boundary did nothing for them.
• Anything you exposed. A published port is a published port. See the OpenClaw instances that ended up reachable from the open internet.

So a reasonable container setup looks like this in shape:

docker run --rm -it \
  -v "$PWD/work":/work \
  -v "$PWD/reference":/reference:ro \
  --env-file ./agent.env \
  --network bridge \
  -u 1000:1000 \
  openclaw:latest

One writable working directory. Reference material read-only. A bridge network instead of host. A non-root user inside. An env file with one key in it, not your whole shell environment.

The rule of thumb: before you add a mount, ask what you would lose if the agent deleted or leaked everything under it. If the answer is uncomfortable, mount a subdirectory instead.

Layer 2: Separate User, Separate Machine

Containers are the floor, not the ceiling. Two stronger options, in increasing order of paranoia and cost:

A dedicated non-admin user account. If you run the agent outside a container, do not run it as your daily admin user. Create a separate account, give it no sudo rights, and put the agent’s working files under its home. Now the blast radius is that account. This costs you fifteen minutes and it is the highest-value change most people can make today.

A separate machine. This is the pattern the more careful people in the community landed on: a cheap used Mac mini or an old laptop that runs the agent and nothing else. No personal files, no logged-in email, no password manager, no SSH keys to production. Put it on a guest VLAN if your router supports one. If that machine is fully compromised, you reimage it and lose nothing.

A VM sits in between — meaningfully stronger than a container, cheaper than buying hardware, and easy to snapshot before risky work.

Pick the tier by how much unattended autonomy you plan to give the thing. An agent you watch, working on one repo, is fine in a container. An agent you leave running overnight with web access and an email account belongs on hardware you would not mind wiping.

On exposing it remotely: if you want to reach the agent from your phone, do not open a port on your router. Use a VPN back to your own network, or put it behind a reverse proxy that terminates TLS and requires authentication. Publishing an agent’s port directly to the internet is how instances end up in someone’s scan results.

Layer 3: Secrets

This is the layer where the mistakes are self-inflicted and completely avoidable.

Never paste an API key into a chat message with the model. Not into the agent’s chat box, not into a cloud-hosted UI, not “just to test it.” That key is now in a conversation transcript, likely on someone else’s server, possibly in a log. Several popular agent tutorials this year did exactly this on a live stream, in front of a million viewers. Every key visible in those recordings should be considered public.

The working practice:

• Env files, tight permissions. chmod 600 agent.env, owned by the agent’s user, never committed. Add it to .gitignore before you create it, not after.
• One key per agent. If a key leaks, you revoke that one and everything else keeps running. Shared keys make rotation so painful that people avoid it.
• Least privilege, per key. Read-only where read-only will do. Scope to a single project or repo. Do not give an agent a token that can delete infrastructure because it was convenient to reuse.
• Spend caps. Where the provider supports a hard budget limit, set one. It converts a runaway loop from a financial event into an error message. See OpenClaw spending limits.
• Rotate anything that has been on screen. Screenshots, screen shares, recordings, error messages pasted into a forum. If it was rendered, rotate it.

If you run local models, a lot of this gets simpler — there is no provider key to leak because inference never leaves the machine. That is a genuine security argument for local inference, separate from the cost one. See zero-dollar OpenClaw with local models.

Layer 4: Take Capabilities Away

Containment on the machine is half the job. The other half is limiting what the agent is allowed to do even when everything is working correctly.

• Allowlist rather than blocklist. Enumerate the commands and tools the agent may use. A blocklist is a guess about what is dangerous; an allowlist is a statement about what is needed.
• Read-only by default. Most agent work is reading, analyzing, and drafting. Give write access to one directory and grant more only when a task actually requires it.
• Human approval on irreversible actions. Send an email, publish a post, make a payment, delete files, push to a remote, touch production. These get a confirmation step, always. This one gate defuses the large majority of prompt-injection outcomes, because the payload almost always wants the agent to do something outward-facing.
• Use the hard stops the tool gives you. Turn on the guardrail settings, the max-turn limits, the auto-approve toggles that ship off by default. Read the config file once, properly, before the first long unattended run.
• Watch what it installs. Third-party skills and plugins are code you did not write, running with the agent’s permissions. There has been at least one significant poisoned-skill campaign already; see malicious OpenClaw skills.

Layer 5: Treat Fetched Content as Data

A short habit list that costs nothing:

• Instructions inside a fetched page, email, PDF, or issue comment are content, not commands. If your agent framework lets you mark tool output as untrusted, do it.
• Be specific about what you want back from a fetch. “Summarize the pricing table on this page” gives the agent a narrower job than “read this page and do what it says.”
• Scope web access. Some setups let you allowlist domains for search and fetch. If your agent only needs docs sites, only give it docs sites.
• Review the transcript after unattended runs. Not every line — but scan for tool calls you did not expect. That is where a redirected agent shows up.
• If the agent tells you a page contained instructions aimed at it, take that seriously and stop the run. That is the system working.

Layer 6: Update Hygiene

Agent releases move fast, and this year several updates broke working setups — config schema changes, tool-calling regressions, defaults flipping back on. Two rules:

1. Snapshot before upgrading. VM snapshot, container image tag, or just a copy of the config directory. You want a five-minute path back.
2. Re-read your security settings after every upgrade. New versions add new capabilities, and new capabilities usually default to on. The permission you turned off in March may not exist under the same name in July.

Details on that pattern in the OpenClaw update survival guide.

The Thirty-Minute Version

If you do nothing else:

1. Create a dedicated non-admin user for the agent, or run it in a container as a non-root user.
2. Mount one project directory. Not your home directory.
3. Move keys into a 600 env file, one scoped key per agent, and rotate anything that has ever been on screen.
4. Turn on human approval for send, publish, pay, and delete.
5. Do not expose the port to the internet; use a VPN or an authenticated reverse proxy.

That is most of the risk gone, and none of it requires you to understand a single exploit.

Related Guides

• OpenClaw security checklist — the 14-step hardening pass, including CVEs
• OpenClaw Docker setup — getting the container running in the first place
• OpenClaw self-hosting risks — what changes when you host it yourself
• Malicious OpenClaw skills — third-party skill supply chain
• OpenClaw spending limits — hard budget caps as a safety control
• Remote vs in-home OpenClaw setup — where to put the machine