AI containment is a deny-by-default security boundary between an AI-capable process and the resources its user can reach. It exists because the permission model every operating system uses was designed for software that does what it was written to do — and an agent decides what to do next.
AI containment is the practice of placing an independent, deny-by-default security boundary between an AI-capable process — an agent, an MCP client, a local model — and the resources available to the user who started it, so that the process holds only the authority a human explicitly granted it.
The three load-bearing words are independent, deny-by-default and explicitly granted. Drop any one of them and what remains is a preference panel.
When you run a program, it inherits everything you can do. That has always been true and has always been a known weakness — it is why the term ambient authority predates all of this by decades. It was tolerable because programs were predictable: a text editor edited text, and if it did something else, that was a bug or a crime, and either way it was detectable.
An agent's behaviour is not in its source code; it is generated at runtime from a model, a prompt, and whatever it read five seconds ago. You cannot audit that in advance, which means the only durable control is over what it can reach.
Agents read issues, web pages, dependency READMEs and tool output. Any of those can carry instructions. This is the confused deputy problem with a model in the deputy's chair — and it is why prompt injection is a containment problem before it is a prompting problem.
Deny the app and it launches a shell. Deny the shell and it invokes an interpreter. Authority that stops at the first process is authority that stops at nothing, which is why process lineage has to be part of the boundary.
All four are useful and most serious setups want several. They fail in different places, and knowing which failure you are buying is the entire point of keeping the words apart.
A containment system that collapses everything into "can this app do things" has already lost the argument. An agent that legitimately needs to write to one folder has no business reading your keys because of it.
Which files and directories, for which operations, resolved to real objects rather than compared as path strings. A grant that can be escaped with a symlink was never a grant.
How BitShout implements this →Which destinations, by category. Reaching an approved API endpoint is not authority to scan the LAN, open a loopback service, or listen for inbound connections.
How BitShout implements this →Which binaries, scripts, interpreters and shells may be started — and containment that follows every descendant, because otherwise the first `bash -c` ends the discussion.
How BitShout implements this →Which external tools and credential-backed operations may be invoked, brokered so the agent receives a result rather than the reusable secret behind it.
How BitShout implements this →Any boundary strict enough to be useful will block something you wanted. If the only way to unblock it is a broad, permanent allow, everyone will use it and the boundary evaporates within a week. Containment lives or dies on the quality of its grant model.
Including this one. Every question below has a wrong answer that is easy to ship and a right answer that is expensive, which is exactly why they are worth asking out loud.
If the thing being contained can turn the containment off, argue with it, or approve its own request, it is a setting, not a boundary.
An allowlist you must maintain is a boundary. A blocklist of known-bad paths is a speed bump — it can only stop what someone already thought of.
Ask what happens when the agent spawns a shell, and the shell spawns Python. If authority resets at any hop, the boundary is decorative.
A process name, a PID, and a path are all things that can be changed by whoever you are containing. Signing identity and audit tokens are not.
A permanent, broad allow granted once during onboarding is how every permission model fails. Scope to one subject, one operation, one resource, one clock.
Ask directly whether an unhealthy enforcement component results in allow or deny. If the answer is a pause, it results in allow.
A tool that says "blocked" when it merely decided something should be blocked is telling you it has enforcement it may not have.
Look for a tamper-evident local record with a vocabulary precise enough to distinguish observation, policy and enforcement. Screenshots of a green shield prove nothing.
BitShout answers the last one by publishing its own limits. One Apple entitlement — Endpoint Security — is still in review, and until it lands we do not claim production runtime enforcement for the filesystem and execution paths. The site says so on every page where it matters rather than in a footnote. See exactly where the line is.
AI containment is the practice of placing an independent, deny-by-default security boundary between an AI-capable process — an agent, an MCP client, a local model — and the resources available to the user who started it, so that the process holds only the authority a human explicitly granted it. It is a security architecture, not a feature of the AI: the boundary is enforced by a separate, privileged component that the contained process cannot approve, disable, or negotiate with.
Guardrails operate inside the model — they shape what it is willing to produce. Containment operates outside it and governs what the process can actually reach. Guardrails fail when the model is manipulated, because the manipulated model is the thing enforcing them. Containment does not depend on the model behaving, which is why the two are complementary rather than alternatives.
Sandboxing is one mechanism containment can use, but the terms are not interchangeable. A sandbox typically restricts one process and is usually adopted voluntarily by the software being sandboxed. Containment covers a process and all of its descendants, is imposed from outside by the user rather than by the vendor of the AI, splits authority into separate domains, and ties every exception to an explicit, narrow, expiring human grant.
Because on your own machine they inherit your authority. To the operating system, a coding agent is just a process you started, so it receives your user ID, your home directory, your keychain access, your network, and your mounted volumes. Nothing granted it those things; it simply was not stopped from having them. That inherited authority is called ambient authority, and removing it is the first thing containment does.
A containment decision is a policy lookup over already-resolved identity, measured in microseconds, and it sits in the same authorization path the operating system already runs for every file open and network flow. In BitShout’s Guard Mode the agent runs natively with no virtual machine and no filesystem shim in the hot path. Vault Mode carries the normal cost of a virtual machine, which is why it is a mode you choose rather than the default.
Coding agents are the sharpest case because they execute code, install packages and hold repository credentials. But anything that combines a language model with tools has the same shape: an MCP client, a desktop assistant with file access, a local model wired to a shell. The moment software chooses its own next action, the question stops being "is this program trustworthy" and becomes "what can this program reach".