The Sandbox Is the Envelope's Floor

Before the detail — Decision: know what still holds when the policy is correct, tested, and fails closed on every case Lesson 2.3 could throw at it — because a policy can be all three and still sit on a floor an agent can quietly widen. Outcome: an envelope whose own writable paths are as deliberately bounded as its tools and its parameters. Artifact: an allowed_state_paths list that excludes the agent’s own log, its own kill switch, and its own policy file, with the exit-3 refusal that proves it. Status of what follows: reusable guidance; sandbox configuration itself is not this lesson’s — AI Assurance 3.2 (a separate training in this series) owns running a bench inside one. Demonstrated with NON-PRODUCTION classroom artifacts.

Prompt first: ask what the agent can write, not just what it can call

Read-only: list every path or file this agent's sandbox lets it write
to, separately from the list of tools and actions it is allowed to
call. For each writable path, ask: could writing here change what
this same agent - or its next run - is allowed to do afterward? A
startup script, a settings file, an executable on the search path
all count.

Flag any writable path where the answer is yes. A tool policy says
what the agent may do; a writable path can quietly rewrite that
policy's own inputs.

The question is deliberately separate from the tool list, because a policy engine tested against every action it declares says nothing about a path it never considered an action at all.

The floor the decision tests don’t reach

AI Assurance 3.2’s rule for an evaluation bench is no credentials, no egress, and read-only source. This lesson assumes that floor and owns one narrower claim: a writable future-permission source can widen a later run even when every tool decision is correct.

A policy that passes every test in front of it and still runs on a floor it can rewrite has not been tested against the one input that matters most: itself.

A sandboxed command can widen its own next run

The clearest published statement of this risk is Claude Code’s own documentation of what happens when filesystem isolation is off: “a sandboxed command can write files that later commands run or read, such as shell startup files, executables on $PATH, or ~/.claude/settings.json, and use them to widen its own access on the next run.” Nothing about that sentence involves breaking the sandbox — every file it names is one the sandbox was already willing to let the agent write. The escalation is not a bypass; it is a legitimate write today turning into a wider grant tomorrow, because the thing written was itself a source of future permission.

The same documentation states the asymmetry that makes this findable rather than mysterious: “a deny entry only ever narrows access, so any scope can add one, but no scope can remove one.” A deny only narrows. This lesson stops at identifying startup files, settings files, and executables as future permission sources; AI Assurance 3.2 owns the sandbox configuration that excludes them.

allowed_state_paths is the same claim, one level up

For MU-AI-011 — Meridian’s proposed crew-dispatch agent — the NON-PRODUCTION envelope permits a guarded call to point only at target/workmgmt.state.json. It rejects receipts/ (where its own actions are logged), control/ (where its own kill switch lives), and policy/ (the file bounding it in the first place) as state targets, with exit 3. This is a guarded target-path check, not an operating-system filesystem sandbox.

Pointing an action at one of those excluded paths is refused before the action itself is ever considered. transcripts/state-path-denial.txt commits two such calls — one aimed at the agent’s own kill switch, one at its own log — and STEP 1 denies both before pre-state is ever captured:

--- call 1: --state control/KILL, the agent's own kill switch ------
  STEP - DENY   state path control/KILL is not in allowed_state_paths
                ['target/workmgmt.state.json'] - receipts/, control/ and
                policy/ are deliberately outside this agent's reach
RESULT denied  exit 3

--- call 2: --state receipts/mu-ai-011.receipts.jsonl, its own log --
  STEP - DENY   state path receipts/mu-ai-011.receipts.jsonl is not in
                allowed_state_paths ['target/workmgmt.state.json'] -
                receipts/, control/ and policy/ are deliberately
                outside this agent's reach
RESULT denied  exit 3

Two calls, two of the three excluded paths, both refused by the same rule the tool and parameter bounds already use, rather than by a separate mechanism bolted on after the fact — policy/envelope.json itself is the third, excluded the same way. Nothing about this list is generic sandbox configuration; it is the specific, load-bearing answer to “what happens if this particular agent could write to its own log, its own switch, or its own policy” — which is the one claim that belongs to this lesson rather than to AI Assurance’s evaluation-bench rule.

These denials prove only that guarded calls cannot target those paths; they do not prove that the process lacks filesystem access by another route.

Stop and escalate when a writable startup, settings, or executable path can change a later run’s access, or when allowed_state_paths is presented as operating-system isolation. The sandbox owner decides the filesystem control; the envelope owner decides guarded target paths.

Key takeaway

A policy can decide every call correctly, in the shape Lesson 2.3 tested, and still sit on a floor that lets an agent widen its own next run — a startup file, an executable on the search path, or a settings file are all legitimate writes that become a wider grant the next time the agent starts. This training’s envelope proves a narrower property: guarded calls cannot point their state argument at receipts/, control/, or policy/; it does not substitute for the sandbox floor AI Assurance 3.2 owns. Module 3 opens where this floor and Lesson 2.1’s enforced path meet — the pre-state hash captured before anything moves at all.

LEADERSHIP DECISION   require every agent's writable-path list to
                      name its own log, its own halt mechanism, and
                      its own policy as explicitly excluded
PRACTITIONER ACTION   audit every path an agent may write to for
                      whether writing there could change what a later
                      run is allowed to do, before the first live run
SUCCESS MEASURE       zero action-taking agents with write access to
                      their own receipts, halt path, or policy file -
                      an audit finding avoided