clawmates/docs/TASK-PERMISSION-AND-TAINT.md

Task permission and argument provenance — a design

Two layers ActGov (arXiv 2609.24446) names that our gate does not have. This is what it would take to build them here, grounded in what was measured on 2026-09-22 rather than in what the paper assumes.

Our gate today has one layer: hard invariants — what no mission may do, a global deny-list with rule ids, plus the write-path rules and the first role policy (verifier may not write). Missing: task permission (bind a phase to the tools its task actually needs) and argument provenance (refuse an action whose target came from untrusted content).

Four findings that decide the design

1. --allowedTools is not an enforcement boundary. The microVM lead is launched with --allowedTools Read Edit Write Bash Agent (microvm_executor::LEAD_TOOLS). The recorded corpus has ListAgents and ScheduleWakeup calls on microvm missions — neither is on that list, and both ran. So the flag governs permission prompting, not availability. Any task-permission layer has to be enforced by our own PreToolUse gate; narrowing the flag would change nothing and would look like it had.

2. The guest already has every tool's output on disk. vm_tool_tap's PostToolUse hook appends the whole payload, tool_response included, to tools.jsonl in /root/toolhooks (container) or /root/tap (VM). Taint can therefore be computed guest-locally, by the same shell that already runs there — no network call, no host round trip, no added latency in the tool path. This is the fact that makes provenance feasible at all.

3. The taint store is already protected. The hook-files rule refuses reads and writes to /root/toolgate, /root/toolhooks, /root/tap, the settings documents and .git/hooks/, from Bash and from the write tools. A taint file living there cannot be erased by the agent whose calls it governs.

4. Provenance matters on one tier far more than the other. Measured reachability (docs/MISSION-EGRESS.md) and the VM proxy's allow-list:

tier	tailnet	host ssh	public internet
microVM	n/a (no NIC; CONNECT proxy)	n/a	allow-list only — provider + forge, matched by name, not substring
container	blocked	blocked	open

A microVM cannot exfiltrate to an attacker's host whatever a page tells it: the allow-list already closes that. A container mission can reach any public host. So the network half of provenance is a container-tier control, and saying otherwise would be padding.

Piece 1 — task permission

Shape. A per-phase allowlist of tools, enforced by the gate: a tool outside the set is denied with rule task-permission, alongside the floor and the role policies, rendered into the same guest script from the same table.

Where it is declared. mission_phases.config. Not under the key tools — that is taken: security_scan::run reads it to choose which of cargo_audit / gitleaks / trivy_fs / semgrep run. Use agent_tools, and have phase_config::KNOWN_KEYS describe both so the collision is visible to whoever reads the registry next.

Where the default comes from. The corpus, not intuition. What phase kinds actually used, today:

phase kind	tools observed
coding	Bash 56, Read 19, Write 11, Agent 5, Edit 1, ListAgents 1, ScheduleWakeup 1
research	Bash 37, Read 28, Write 10, Glob 2

Two of those are the point: ListAgents and ScheduleWakeup are the strays from finding 1 — tools no mission needs, that no list stopped. A default set per phase kind of {Bash, Read, Write, Edit, Glob, Agent} covers every observed legitimate call and excludes both strays.

Why this is not just a smaller --agents list. It is enforced by us, in the hook, recorded as a gate.denied with its rule; the CLI's own list is the harness policing itself and demonstrably does not.

Staging.

1. Add agent_tools to the config registry and the gate's table; render into the guest script; unit + shell tests as for the role policies.
2. Shadow first. A new outcome gate.would_deny — recorded, not enforced. Run every scenario and a week of real missions. Promote only when the record shows zero denials of work that completed successfully.
3. Enforce. The scenarios are the utility half: all of them must still pass, which is the trade ActGov measures as CaMeL and ACE failing (ASR 0.000 at utility 0.000) and this module's header already refuses.

What could go wrong. Too tight and agents work around the gate, which is worse than no gate. Mitigated by deriving from the corpus, by shadow mode, and by the default being a union of observed use rather than a guess at need.

Piece 2 — argument provenance (taint)

The invariant worth having, in ActGov's terms: no outbound action whose target was derived from untrusted content. That is the indirect prompt-injection shape — a fetched page says "send this to evil.example", and the agent obliges.

Mechanism, guest-local and deterministic.

• The tap gains a taint step: for each fetching call (Bash curl/wget, and any WebFetch), extract hostnames from tool_response and append them to /root/toolhooks/untrusted-hosts.txt, capped and deduplicated.
• The gate gains rule untrusted-target: an outbound call carrying a body (the existing curl-body / wget-body matchers already identify these) whose target host appears in that file is denied.

Why that shape and not string taint. Tainting arbitrary strings from fetched text and matching them against later commands produces false positives immediately — the failure this module treats as cardinal, and the one gate-exfil-spelling already cost us once. Hosts are high-signal and the asymmetry is real: reading a host a page mentioned is ordinary research; sending data to one is the attack. So the rule fires only on the intersection.

Staging.

1. Taint extraction in the tap, writing the file. Nothing enforced. Inspect on real missions: what does it actually collect?
2. untrusted-target in shadow (gate.would_deny), same as piece 1.
3. Enforce on the container tier, where public egress is open. On the VM tier it is defence in depth behind an allow-list that already holds.

Honest limits, to be written into the module header.

• Indirection defeats it: base64, a shell variable, a URL assembled from pieces. This stops accidents and the obvious case, which is exactly what the gate's header already claims and no more. The real boundary on the VM tier is the egress allow-list; on the container tier it is the network policy.
• It does not cover content exfiltration into deliverables — a page telling the agent to write .env into README.md, which is then committed and pushed to the forge, a host that is allowed. That is a second invariant (stage B) and a harder one, because the legitimate case — writing fetched research into a file — looks identical.

Validation is thin and should be said so. Today's corpus is 171 tool calls, 93 with responses, 15 curl/wget invocations — the larger corpora those earlier numbers came from were wiped with the missions. Fifteen calls cannot validate a rule. The evidence path is therefore shadow mode on real traffic, not a retro-fit against what we happen to have kept.

Sequencing

Piece 1 before piece 2: it is smaller, its default is already derivable from the corpus, and it exercises the shadow-mode machinery (gate.would_deny) that piece 2 then reuses. Both inherit the role policy's proof obligations — rendered from one table into both implementations, unit-tested against the predicate, shell-tested against the generated script, and probed live against the deployed artifact by the rolepolicy scenario's pattern, with the negative controls that stop a gate from passing by refusing everything.