Red-Teaming the Allow-List: Forbidden Effects Through Permitted Tools

Take the worked coding-agent harness exactly as the subject specifies it: seven tools; in sandboxed-edit, edit_file and write_file scoped to the repository working tree, run_command allow-listed to pytest *, npm test *, ruff *, git status, git diff; git push, paths outside the workspace, and destructive primitives gated regardless of tier; one container per task with /workspace writable, credential directories absent, egress denied except the package registry and the model API. The permission policy is written over tool names and command prefixes.

You are running the periodic adversarial review the subject prescribes: not "is this command dangerous" but "what is the cheapest way to achieve a forbidden effect using only permitted tools."

1. Find at least three distinct paths to a forbidden effect (arbitrary code execution, writes that reach beyond the run, network egress, or external state change) that use only permitted tools and allow-listed patterns. Rank them by severity and say why.
2. Explain why each is a permission-model gap rather than a model flaw, and identify which harness component actually bounded the damage for each path — and which path no component bounds.
3. Rewrite the policy over effects so the paths are closed and a newly added tool inherits the fix. Be specific about what the allow-list entries pytest * and npm test * really grant, and what must be true for them to remain acceptable.