[itswl]

Two things a read-only investigator could still do, both found by asking a second deployment's audit questions of this code, and both closed here.

1. A run could rewrite the files configuration points at. The work compose kept the planner's and the watcher's MCP config on each node's own volume. The engine rereads that file at every run and starts the stdio servers it names, and the input guard protected only fixed names in the workdir. Measured on the probe image with that setting and a recording stand-in for the model API:

moment	MCP config on the volume	marker from the planted command
before any run	no	absent
after a run that wrote it with a shell step	yes	absent
after an unrelated run with no tool call	yes	present

The fix has three parts:

• The input guard protects every file the operator names by path, wherever it lives, on all three runtimes, and a run's before-and-after digest covers them. That means the MCP config, roles, both allowlists, the declared radius, decline patterns, the codex and pi configs, and the appended methodology when its path is configured. A test fails if a new file setting is left unclassified.
• At startup the posture record names any of the operator's files this node's own user could write or replace (writable_inputs), and the alarm channel says so once. It is reported, not refused, so a node configured from the old docs still starts.
• The work compose reads both MCP configs from the read-only secrets mounts. The configuration doc no longer offers the volume.

Read back from this branch's image:

setup	planted config	writable_inputs	a write by the service user
MCP config on the volume	refused by the input guard; nothing ran	/data/mcp.json, paged once	refused by the guard
MCP config on a read-only mount	not possible	empty	refused by the kernel

2. A read-only identity still reads secret values.

• Posture now records reads_secrets beside the verdict and never lets it decide anything. The questions are kubectl auth can-i get|list secrets -A plus wildcard rules, and a second AWS simulation of Secrets Manager values, SSM parameters, KMS decryption and S3 object reads. Their failures go to read_errors, never to the errors that make a verdict unverifiable.
• The bash guard refuses printing a secret's value under every posture: a Secret's data from kubectl, Secrets Manager values, decrypted SSM parameters, KMS plaintext, and AWS credentials. Whether a secret exists, which keys it holds and when it changed stays open.

This overturns the 2026-09-09 note that left kubectl get secret … -o yaml allowed on purpose. That note is corrected in place, and the output-guard test's premise now says which read is refused and why every other read stays open.

Shown. The console's posture card adds secret-read counts and names any config a run could rewrite, in both languages.

Checked.

• Gate: STACK GATE GREEN locally, with 940 investigator tests.
• Four new guard mutations are each caught: configured files unprotected, the writable report silenced, secret prints allowed, and the read questions dropped.
• The offline engine check on the branch image still completes a scripted turn, refuses a protected write, and keeps prompts verbatim.

Not changed: codex keeps its hooks in a home on the run's volume, which is already its own containment row. Nothing is deployed. The two local MCP configs move to the read-only mounts after this merges, and the stack stays stopped.

CodeQL. The first run raised two high alerts, clear-text logging and clear-text storage of sensitive data, at the gate's output and the audit writer. The flow started at the guard's rule table, whose name held the word code scanning treats as secret data, and carried its fixed descriptions into the refusal text. The second commit renames the rule and question tables. Every field an operator reads keeps its name.

CI read back before merging.