Agent Boundaries Must Be Enforced Outside the Model

Digg Tech and Digg AI are again clustering around prompt-injection and coding-agent safety, and the current operator lesson is sharper than “be careful with prompts.” Anthropic’s containment write-up explains why approval logic and model-side defenses help but fail in predictable ways once the user prompt, project files, or tool outputs become an injection surface. AI Now’s July 8 exploit brief then demonstrates the practical consequence: an out-of-the-box Claude Code auto-mode or Codex auto-review run can be steered through a malicious third-party codebase into remote code execution during a defensive security review. Simon Willison’s recent commentary lands on the same conclusion from a builder perspective: even strong model-layer defenses are not enough if the agent can still reach data or tools that should never have been in scope. The useful synthesis is that agent autonomy now has to be earned through containment architecture, not just better prompting or fewer permission clicks.

A lot of teams still think the main tradeoff is human approvals versus convenience. That is too narrow. Once agents can run commands, inspect code, fetch external content, and call services, every untrusted file, prompt, and tool response becomes part of the control plane. If the environment is wide open, a sufficiently convincing instruction can turn a legitimate workflow into an exfiltration or execution path. Builders who keep treating this as a UI-level approval problem will either ship unsafe automation or keep humans in the loop forever. Builders who define hard runtime boundaries can let agents run longer without pretending the model is perfectly trustworthy.

Redesign one autonomous workflow as a contained agent run. Trigger: choose a task that currently touches untrusted code, external docs, browser content, support tickets, or third-party data. Context: state the exact objective, the specific assets the agent may read or modify, and which sources are untrusted by default. Tools: give the worker only the minimum commands, network destinations, repos, and connectors needed for the job; isolate it in a repo-scoped or VM-scoped environment instead of granting host-wide access. Verifier: require an external check that evaluates artifacts and side effects, such as tests, schema validation, diff review, deployment policy checks, or a reviewer agent that cannot execute commands. Budget: cap retries, outbound requests, spend, and the number of cross-boundary actions per run. Artifacts: preserve the prompt, trace, command log, accessed resources, generated patches, verifier output, and any blocked actions for audit. Stop condition: end the run when the verifier passes, when the agent requests a forbidden boundary crossing, when repeated attempts do not produce new evidence, or when the runtime budget is exhausted.

Take one agent workflow you would currently hesitate to leave unattended and write its trust boundary in plain language: what it may read, what it may write, where it may send data, and what must always stay unreachable. If that boundary is fuzzy, the workflow is not ready for more autonomy.