---
title: "The Authority of a Capsule"
description: "Giving Agents Freedom Without Giving Them the Machine."
canonical_url: "https://murmur.nexus/blog/the-authority-of-a-capsule"
last_updated: "2026-09-11T00:00:00.000Z"
---

> *"Covenants, without the Sword, are but Words."* \- Thomas Hobbes

Reading into the recent AI escapades fascinate me and frighten me at the same time. They showcase something more interesting than a model accidentally breaking a rule. In the [recent OpenAI](https://openai.com/index/hugging-face-incident-and-the-road-ahead/) and [Hugging Face incident](https://huggingface.co/blog/agent-intrusion-technical-timeline), the model appears to have reasoned that escaping the intended environment and stealing the answer was "easier" than solving the challenge itself. The Anthropic incidents were different and were largely failures in containment configuration, but the agent reasoning still read like a novel. In several cases I had to laugh out loud, while also growing more aware of the potential dangers of tasking agents in confined environments.

## When the environment becomes part of the task

The important part is not that an AI tried to escape its box. It is that capable agents can treat the environment itself as part of the problem they are trying to solve. If a model has a goal, shell access, tools, credentials, a network connection, or some unexpected path through the system, it can reason about those things together. What looks like infrastructure to us can look like another set of options to the agent. That changes how I think about containment. The question is not only whether an agent can cross a boundary. The first question is whether the environment accidentally gives it authority that was never meant to be part of the task. Once that authority exists, we should assume a capable agent may eventually notice it and use it.

This is why containment is one of the core design ideas in Murmur. A capsule is described by a single `manifest.yaml` file that [declares what the workload can use, see, and reach](https://docs.murmur.nexus/how-to/lock-down-capsule/). The runtime then turns that declaration into controls over execution, identity, storage, tools, and network access. The model is not asked to remember those limits, and the control layer does not ask the model whether an action should be allowed. And this distinction matters here because security is not just about agent permissions. It is also about what becomes possible when permissions are combined. Shell, network and credentials each on their own might be reasonable. Put them together and the effective authority can be much larger than any single permission grant suggests. This is my biggest takeaway when interpreting the incidents; it's not about any single agent capability, rather the authority created by the whole environment. Thinking about security boundaries like this usually are about keeping attackers out. With agents, there is a newer problem. The thing already running on your machine may be capable enough to push beyond the authority you intended to give it. However, it does not have to be malicious. We have already seen plenty of tweets about operations whose authority extended far beyond the intended target, like this one from Crémieux:

![Tweet from Crémieux (@cremieuxrecueil): "I just ran into an issue where GPT 5.6 Sol just straight-up deletes the files it's working with and then panics about recovering them. Apparently I'm the not the first person this has happened to. What's going on?" The attached screenshot shows the agent reporting a cleanup-command problem after verification: PowerShell treated an -Include filter unexpectedly and removed compiled paper files from the papers folder.](/_astro/tweet-cremieux-gpt56sol-deletes-files.DEaHFAHG_7PRrl.webp)

*@cremieuxrecueil, 10 July 2026.*

A model can be confused, overly resourceful, or simply following a goal farther than you expected. Telling an agent to only touch one directory is not much of a boundary when that same agent can run arbitrary shell commands.

## Turning intended authority into an execution boundary

A Murmur capsule turns that intended authority into an execution boundary. What a shell process may access is decided before it runs and enforced below the shell, where the model cannot negotiate or reinterpret the rule. On a capable Linux host, the default enforcement is `scoped`. What this means is that the command can work normally inside its assigned directory, while writes elsewhere on the machine are refused. Reads are limited to the working data and system resources required to execute. A `sealed` capsule goes one step further. Instead of starting with the host filesystem and denying most of it, Murmur constructs a small filesystem from the things the workload was explicitly given. That includes its binaries, libraries, runtime directories, and working data. Your home directory, SSH keys, credentials, and unrelated projects are not meaningfully available for browsing. Some host scaffolding and process metadata still exist underneath, but access to them is restricted.

The important change with these containment classes are that isolation is no longer an instruction the agent is expected to follow. It becomes part of the environment the agent receives. And yes, there are limits to that guarantee. Capsule containment applies to shell subprocesses. WASM tools are separately constrained through their WASI access. If you are building tool logic that WASI artifact can't support, Murmur does allow you to build it as a "native" tool artifact, but these types of tools do not receive the same filesystem confinement and can exercise some authority over your machine. Enforcement also depends on what the host kernel can provide, so the host where the capsule is running matters. If a workload requires one of the above-mentioned containment classes, that requirement should be declared in the capsule's manifest so that you can safely rely on a refusal to run a capsule. Therefore, a capsule is not a replacement for a machine boundary. Its isolation ultimately depends on the host kernel, so genuinely hostile workloads still belong inside a hardened virtual machine or pod if hardened containment really matters. In such cases, the capsule limits the authority available to the workload during normal execution, while the machine boundary is there for the rarer case where the kernel itself becomes the thing being attacked.

## Why bother if containment is imperfect?

Let me be clear that I don't suggest we can actually contain an agent within the capsule, or any runtime environment for that matter. Then why bother with all these boundary layers? This starts to matter quickly once agents are allowed to work without constant supervision. A developer might let a coding agent edit files, install dependencies, run tests, and work for hours inside a repository. The goal is not to make every command harmless. The goal is to give the agent enough freedom to work inside the repository without making the rest of the laptop part of its available world. The same idea becomes more important when the inputs themselves cannot be trusted. A research agent may search the web, open documents, inspect repositories, or execute unfamiliar code. Any of those inputs can contain instructions intended to manipulate the model. A prompt injection in a webpage should not become a path to SSH keys, adjacent projects, or other host data. The agent can still explore freely inside the capsule environment it was given, while the boundary limits how far the consequences of that exploration can travel. This matters in particular in enterprise environments as well, where the problem becomes one of authority at a larger scale. An agent may work with source code, customer data, internal tools, credentials, and long running workflows without a person approving every action. At that point, containment is not mainly about protecting one machine. It is about deciding in advance what the agent is allowed to act on, then making that decision hold even when nobody is watching.

That is the part I find most important about the recent incidents. Better models do not only become better at solving the task we had in mind. They also become better at noticing the environment around the task. As agents gain more freedom to act, the boundary around that freedom has to become less dependent on their cooperation.

Keep the capsule working directory small and commit before you start. A capsule can keep shell access inside that boundary, but everything inside it should be treated as available to the agent.

`- @ewdegraaff`