Hermes Agent Bubblewrap Verdict: The No-Container Sandbox Rated

Hermes Agent bubblewrap earns a 7.5 out of 10 from me: it is the easiest way to keep an agent's shell commands away from your credentials on a Linux box, but it leaves the rest of the filesystem readable and the network wide open by default.

The plugin comes from the Hermes Official Plugins repo and is described there as built and supported by Nous Research.

Every score below is my editorial reading of the plugin README and the Hermes docs, not a benchmark run.

If you want my team to sanity-check your own agent setup, book a free SEO strategy session.

The Verdict In One Paragraph

Install it on any Linux server where Hermes runs commands and where your logins also live.

It hides the folders that matter, refuses to run anything if the sandbox cannot start, and keeps the approval prompts you already rely on.

Skip it if you need outbound network filtering, long-running background processes, or a non-Linux machine.

What Was Reviewed

The Hermes v0.23.0 catalog entry pins bubblewrap 1.3.0, marks it as the official tier, limits it to Linux and requires Hermes 0.22.6 or later.

This review covers the 1.3.0 README at that pinned commit.

The plugin repo's main branch has since moved to a newer version with extra settings, so if you install from main, check its README for the differences.

The plugin entered the catalog in PR #142548 and appears under new official plugins in the v0.23.0 release notes.

The Scorecard

Criterion	Score /10	Why, from the docs
Credential protection	9	SSH, cloud, GPG, kube, docker and package-registry stores plus browser profiles and keyrings are hidden whatever the allowlist says.
Setup effort	8	One distro package, one plugin install, one config line; the Ubuntu 24.04 AppArmor step is the only common snag.
Fail-safe behaviour	9	A missing bwrap or failed probe returns a degraded result; commands are never run unsandboxed.
Write containment	8	Only the working directory and explicit read-write binds can change; the host root is mounted read-only.
Read containment	5	Everything outside the hidden set stays readable, including /etc and secrets left in project folders.
Network control	4	Two profiles are loopback only, the default shares the host network, and there is no outbound filtering.
Resource limits	6	Per-process memory, CPU and process caps exist, but there are no cgroup totals and defaults break pip until raised.
Workflow fit	6	No background processes and no persistent execute_code kernel, so dev servers and stateful notebooks are out.
Approval safety net	9	Dangerous-command approval stays on exactly as for local, which container backends skip.
Overall	7.5	Strong where it matters most for a small server, honest about its gaps.

🔥 Want the Hermes setups that score well in real member businesses? Inside the AI Profit Boardroom you get step-by-step video trainings, the installable Agent OS, four coaching calls a week and 3,400+ members comparing their agent backends. → Join the AI Profit Boardroom

Strength: Credentials Are Hidden By Default

This is the headline feature, and it holds up.

Inside the sandbox, every dot entry in your home folder disappears unless it sits on an allowlist.

On top of that, a fixed list of credential stores stays hidden even if you try to allow it.

That list covers SSH and GPG keys, AWS and Google Cloud logins, Kubernetes and Docker configs, the GitHub CLI login, saved git credentials, package-registry tokens for npm and PyPI, the Postgres password file, netrc, browser profiles and desktop keyrings.

Naming one of them in home_allow just logs a warning.

Credential files below an allowed folder, such as a cargo credentials file, show up empty.

The Hermes home is hidden as well, so a sandboxed command cannot read the agent's own .env or auth file.

Agent and D-Bus sockets under /run/user are unreachable, and the docker socket is replaced by an empty file.

Strength: Sensible Home-Folder Rules

The home-folder handling is more thoughtful than I expected.

Ordinary folders such as ~/projects and ~/Documents are visible but read-only unless the working directory covers them.

Dot entries only appear if they are on the shipped allowlist, sit on your PATH, or are added through home_allow.

Even an allowed dot entry is always read-only, so a command cannot quietly edit ~/.bashrc or ~/.gitconfig to run code in your own shell later.

The allowlist is fixed when the backend starts, which stops a command from widening it by changing PATH.

That design closes off a whole class of sneaky persistence tricks without any setup on your part.

Strength: No Image, No Daemon

The README describes it as not a container, and that is a selling point, not a disclaimer.

Your toolchains, project checkouts and system binaries are all available at their normal paths, read-only.

Nothing to build, nothing to keep running, no volume mapping to get wrong.

For a single small server, that removes a whole layer of maintenance that Docker brings.

Strength: It Fails Closed

When bwrap is missing or the namespace probe fails, the terminal tool returns a degraded result naming the package to install.

Set terminal.degraded_mode: fail if you want a hard error instead.

Either way, the README states that commands are never run outside the sandbox.

That is the right default, and plenty of security tools get it wrong.

Limit: Network Is On Or Off

The three profiles give you a coarse switch.

restricted is read-only with loopback only, workspace is writable with loopback only, and network is writable with the host network.

The default is network.

There is no allowlist of hosts and no outbound filtering, so any job that needs one package registry gets the whole internet.

That is why network control scores lowest on the card.

Limit: Readable Host, No Seccomp, No Cgroups

The sandbox blocks writes, not reads.

Anything your user can read outside the hidden set, including /etc and secrets left inside project folders, a command can read too.

There is no seccomp filter, and Nous frames it as a filesystem and process boundary rather than protection against kernel-level flaws.

Resource caps are per-process rlimits, so a command that forks can exceed memory_mb in total.

Other Unix sockets outside the masked ones remain connectable if a command knows where they are.

Limit: No Background Jobs Or Persistent Kernel

Each command is torn down when its shell exits, so a background: true job dies straight away.

execute_code falls back to one script per call, which means Python variables do not survive between calls.

The defaults also trip everyday tools: 256 MB of memory and 30 CPU seconds are too low for pip, node, cargo or a long compile until you raise memory_mb and cpu_seconds.

How It Sits Next To Local And Docker

No official page compares the three side by side, so this table is my reading of the plugin README and the Hermes security guide.

	local	bubblewrap	docker
Where commands run	On the host as you	On the host, inside a per-command bwrap sandbox	Inside a container
Needs an image or daemon	No	No	Yes
Host filesystem	Full access	Read-only, one writable folder	Only what you mount
Credentials in home folder	Reachable	Hidden	Not mounted unless you add them
Dangerous-command approval	Yes	Yes	Skipped
Platforms	All Hermes platforms	Linux only	Anywhere Docker runs

One oddity worth knowing: the security guide's backend comparison table does not list bubblewrap at all, so the README is the place to read about it.

The key difference from container backends is the approval row.

According to the security guide, the four container-style backends drop the dangerous-command prompt since the container itself is the wall; bubblewrap keeps the prompt because its writes land on real host folders.

📞 Weighing up which backend fits your business? Book a free SEO strategy session and my team will walk through the trade-offs for your setup. → Book a free call with my team

Scenario Check: How It Holds Up In Three Small Firms

Scores mean more against real jobs, so here is how the plugin handles three typical ones, step by step.

An accountant processing client exports

The exports folder becomes the working directory and the profile is workspace.

The agent reads the files, writes a summary sheet beside them, and has no internet from the shell.

Saved logins and the Hermes keys file are hidden.

Verdict for this job: a strong fit, as long as no passwords are stored inside the exports folder itself.

A design studio running npm builds

The client repo is the working directory, the profile stays on network, and memory is raised to 2048 MB.

Installs and builds work; a live preview server does not, because background processes die with their command.

Verdict: a good fit for builds, a poor fit for live previews.

A shop trying an unknown import script

The script sits alone in a test folder under the restricted profile while the agent reads it and lists what it would do.

Then it runs under workspace against one sample file.

Verdict: exactly what the offline profiles are good at, with the caveat that the rest of the disk is still readable.

Who Should Use It, And Who Should Skip It

Use it if you are

An accountant or bookkeeper with client exports on a Linux server who wants the agent to process them without seeing saved logins.
A small agency running client builds on one shared Linux box, with each job pointed at one repo.
A shop owner testing a downloaded feed-conversion script under the offline restricted profile before trusting it.
Anyone already on the local backend on Linux who wants a fence without learning Docker.

Skip it if you are

Mac and Windows users, since it is Linux only.
Teams that need outbound traffic limited to named hosts.
Workflows built around dev servers, watchers or other background processes.
Notebook-style data work that relies on Python state carrying between calls.
Gateways already isolated in Docker or a cloud sandbox and maintained by someone who knows them.

If you are still choosing add-ons, our ranking of the best Hermes Agent plugins puts this one in context.

Final Verdict

7.5 out of 10, and an easy yes for Linux operators on the local backend today.

Install it, give it 1024 or 2048 MB of memory when the agent installs packages, clear any keys out of project directories, and default to workspace for jobs that never touch the web.

Also On Our Network

FAQ: Hermes Agent Bubblewrap Verdict

What score does Hermes Agent bubblewrap get?

7.5 out of 10 overall, an editorial rating from the docs. It scores highest on credential hiding and fail-safe behaviour and lowest on network control.

Which version was reviewed?

Version 1.3.0, the one the Hermes v0.23.0 catalog pins. The repo main branch is newer.

Does bubblewrap filter outbound network traffic?

No. The network profile shares the host network with no filtering, and the other two profiles allow loopback only.

Is bubblewrap safer than Docker for Hermes?

They work differently. Docker isolates the filesystem more fully but skips dangerous-command approval; bubblewrap keeps the host readable but keeps approvals on.

Who should not use it?

Non-Linux users, teams that need host-level network allowlists, and workflows that depend on background processes or persistent Python state.

📺 Video notes + links to the tools 👉

🎥 Learn how I make these videos 👉

🆓 Get a FREE AI Course + Community + 1,000 AI Agents 👉

About Julian

I'm Julian Goldie, an SEO entrepreneur, author and founder of the AI Profit Boardroom, which has 3,400+ members.

I help business owners scale with AI agents, automation and SEO.

I've built a 7-figure SEO and link building agency, Goldie Agency, with a team of 70+ SEO experts.
I've grown a YouTube channel to 400,000+ subscribers.
I wrote "Link Building Mastery".
My Udemy courses have taught over 29,000 students.

→ Get my best AI training inside the AI Profit Boardroom

Switch the backend on your Linux box this week, and book a free SEO strategy session or join the AI Profit Boardroom if you want help deciding where Hermes Agent bubblewrap fits.

Hermes Agent Bubblewrap Verdict: The No-Container Linux Sandbox Rated Out Of 10