Your agent's blast radius is decided by the filesystem, not the prompt

Part 6 of the Harness Engineering series on dev.to takes the least glamorous piece of an agent stack, the runtime in which tool calls execute, and argues that this is where every side effect the model requests actually materializes ^[1][5]. The consequence for anyone shipping one of these things is that the load-bearing safety decisions are made by whoever configures the filesystem, the shell, the network reach and the resource ceilings, not by whoever writes the prompt ^[4][9].

The definition offered is deliberately mundane. The Environment is the filesystem tools read from and write to, the shell they exec commands in, the network they can reach, and the compute they are permitted to consume: CPU, memory, disk, wall-clock time, API quotas ^[4]. Every tool with side effects points at it. A read_file tool opens a file somewhere; a bash tool runs ls in some shell on some filesystem; a fetch_url tool fires a request from some network stack, subject to some set of rules about what it may reach ^[5]. The series frames tools as the model's reach and the environment as what they reach into, and notes that a good tool set inside a badly designed environment produces an agent that either cannot act, because the environment blocks it, or acts too freely, because it does not ^[6].

The useful part is the boundedness list. A bounded environment, according to the article, lets the agent do what it needs and nothing else: no accidental rm -rf of the host, no reaching into networks it should not touch such as production databases and internal services, no quiet exfiltration through unexpected channels, no burning cloud credits on unchecked resources, no running forever when stuck ^[8]. That is five failure modes ^[13], and none of them is a model alignment problem ^[14]. They are host integrity, network segmentation, egress control, quota enforcement and timeouts. Each has a boring, well-understood implementation, which is the author's point: boundedness is described as containing blast radius rather than distrusting the model, because even a perfectly behaved model working on a legitimate task will occasionally hallucinate a filename or misread an argument ^[9].

The comparison the piece leans on is CI, and it holds up. Anyone who has configured a pipeline runner has already made environment decisions: what OS the runner uses, which dependencies are pre-installed, which secrets are exposed, which artifacts persist between steps ^[10]. Same questions, applied to a caller whose next command you cannot read in advance.

Two caveats. The article names three properties that separate a production-ready environment from a demo one, bounded, reproducible and inspectable, but the text available here only develops the first ^[7][15]. And the series doubles as the on-ramp to a paid Udemy course and a live Maven workshop, though the author states both are optional and that the series stands on its own ^[11].

What to watch is whether Parts 7 through 10, covering memory, observability, the harness architecture and a teardown of Claude Code, put mechanisms behind reproducible and inspectable ^[12]. My expectation is that those are the two properties with a real bill attached, since they imply disposable workspaces, pinned images and a durable record of every command the agent actually ran. The CI analogy the author already reaches for ^[10] is the obvious place to get those answers, and also the point at which the analogy stops being cheap to implement.