Start an OpenShell sandbox (the container you run an agent inside) with no policy of your own, and you inherit a specific posture. The working directory is read-write, system paths like /bin and /usr are read-only, and the rest of the filesystem is dark. Outbound network is denied. The process runs as a non-root user with no Linux capabilities. Attach a credential provider and secrets arrive as opaque placeholders, resolving only when network policy and credential binding agree on the destination.
None of that required a line of policy. And each of those boundaries leaves a record when something runs into it.
In the docs' first example, curl reaches for api.github.com:443 and gets back a 403 whose body names the binary, the destination, and the fact that no rule matched. Connection-level and request-level refusals land as separate events, each stamped with time, executable, PID, destination, and the rule that decided, or the absence of one.
Four domains, independently configured
The policy schema gives filesystem, network, process, and credentials their own sections, and none of them implies the others. The default posture is one example: filesystem access, zero outbound network. Run it the other way, with network reach to a public API and no credential authorization, and the network rule still doesn't grant the credential; that takes a separate endpoint binding.
Which matters when something breaks. A blocked request here is a network question and nothing else, not some phantom interaction between permission domains you then have to rule out one at a time.
What expansion requests carry
Turn on Policy Advisor and an agent can ask for more. The ask is structured: an intent_summary in plain language, plus the host, port, binary, method, and path it wants. A prover scores the risk delta in categories rather than vibes — link-local reach opened, a credentialed host added, a new HTTP method allowed at an endpoint that already carries credentials — and what gets approved is the rule itself along with that assessment.
The sequence lands in the log: denial, proposed rule, approval or rejection, the revision that loaded, the retried request. You can start from a permission that exists today and walk back to the denial that prompted it and the risk flagged at the time. And if policy or credential metadata changes after review, the candidate hash changes and the earlier approval stops counting, which timestamps the moment the conditions behind a permission stopped holding.
Advisor is off by default and covers network only. Filesystem, process, and Landlock settings (Landlock being the kernel's filesystem restriction layer) stay where you set them at startup.
Mid-task policy changes
Network rules are live controls. Push a new revision into a running sandbox and OpenShell tears down the connections the old one authorized: keep-alives, tunnels, WebSockets. The next attempt gets evaluated against the new rules. Filesystem and process settings don't work this way; changing those means destroying the sandbox and building another.
That closure is real enforcement, but it has a limit. It stops the relay; it doesn't reach whatever already landed on the other side. I've drawn that distinction before, in issue 44, and OpenShell's own documentation draws it too: halting an in-flight request and undoing its downstream effect are separate operations.
Validation failure at runtime has its own mechanics. The default is fail_closed: traffic stops until a valid policy arrives. The alternative, retain_last_valid, keeps the previous one in force. Either way you can see which is running, and the choice tells you which failure the operator preferred — a stuck agent, or an agent still working under rules you were trying to replace.
The log buffer holding all of this is bounded and non-persistent, and OCSF export is best-effort. Denials, advisor trails, hash invalidations — all of it disappears unless you've built somewhere for it to go. Which is the question I'd put to any policy system after confirming it produces evidence at all. Where does the evidence land, and how long does it keep?
- Policy versus instruction compliance: ST-WebAgentBench found that agents completed tasks at substantially higher rates than they completed tasks without violating applicable policies, which is the gap a runtime policy system like OpenShell's is designed to close from the outside.
- Clearer instructions aren't enough: The UK AI Security Institute's simulated evaluation found that more explicit scope instructions reduced but did not eliminate boundary violations, reinforcing the case for enforcement below the model rather than relying on the model to respect its own boundaries.
- The practical policy question: AP's coverage of OpenShell's launch quoted a security researcher asking the question the documentation doesn't answer — what policy should you actually configure when an agent needs real access to remain useful?
- Identity across the chain: NIST's 2026 consultation on agent identity characterized tools like MCP and A2A as implementation-layer protocols that do not by themselves preserve the full delegation chain, user intent, or revocation state — the layer above what a sandbox can enforce.
