The Harness Is a Security Boundary

A model can suggest an action. A harness makes the action happen. It supplies tools, credentials, targets, memory, concurrency, retries, and a route from one result to the next. Those parts decide whether a weak attempt dies in one session or becomes an operating system that keeps learning how to push past failure.

That distinction is easy to miss because the model produces the visible language. The surrounding machinery looks like plumbing. But plumbing carries pressure. A middling model attached to durable state and a broad action surface can do far more than a stronger model trapped in a chat window. The operational capability belongs to the whole system, not to the name in the model picker.

Our position is simple: model vetting that ignores the harness is incomplete security work. You have inspected an engine and waved through the vehicle, the keys, the route, and the person choosing the destination.

Teams keep putting hard requirements into soft text. Do not touch this environment. Do not call that tool. Stop after this many attempts. Those sentences may guide behavior, but they do not remove capability. An agent that can still reach the forbidden path can take it through error, ambiguity, or relentless optimization toward the larger goal.

A real boundary lives outside the agent's discretion. The credential cannot authorize the action. The network cannot reach the target. The tool rejects the argument. The retry budget runs out. The release gate refuses evidence produced only inside the builder's own context. The agent may disagree with any of those controls, and nothing changes.

This is not an argument for weaker agents. It is an argument for stronger systems. Useful agents need enough room to solve problems, while the factory needs mechanical limits on the consequences of being wrong. Prompts describe intent. Permissions, isolation, budgets, and gates enforce it.

One failed action tells you little about a factory. Give the system a failure log, persistent memory, classification, and another attempt, and failure becomes training data. The next run can change tactics, skip dead ends, and concentrate effort where the last run found movement. That is exactly what makes agent-run delivery compound. It is also what makes an overpowered harness dangerous.

Concurrency changes the consequence again. A mistake performed once is an incident. The same mistake routed across hundreds of targets is an operating model. Rate limits and spend limits matter, but they are not enough. The factory needs limits tied to the work: which systems may be touched, how many actions may run, what evidence permits another round, and which failure classes force a stop.

Treat memory as production state. Treat retry policy as executable authority. Treat concurrency as blast radius. If those settings can change without the same review you apply to code and infrastructure, your most important security controls are configuration nobody is governing.

Agent speed does not repeal security fundamentals. Patch the exposed service. Put administration behind a narrow access path. Segment the network. Rotate credentials. Log tool calls. Make sensitive actions require proof and independent authority. These controls can feel ordinary next to a swarm of agents, which is precisely why people underrate them.

Ordinary controls work because they do not need to outthink the agent. A firewall rule does not debate the plan. A scoped credential does not become persuaded by a confident explanation. A gate that checks the actual artifact does not care how persuasive the builder sounds. The defense wins by making the wrong route unavailable or unprofitable, not by writing a more eloquent warning inside the route.

The same principle should shape a constructive software factory. Give agents broad freedom inside a deliberately small box. Make every expansion of that box an explicit decision. Record the action, preserve the evidence, and let a separate control decide whether the work moves forward.

Start the review where consequences become real. Inventory every tool the agent can call, every credential it can receive, every network it can reach, and every piece of state that survives the session. Then follow the retry path. Ask what happens after a refusal, a timeout, a partial success, and a result the agent cannot classify. That path tells you more about operational risk than a polished first response ever will.

Next, test the system from outside the builder's chosen conditions. Can the harness route around a written restriction? Can it expand scope through a helper tool? Can its own output approve the next action? Can it preserve a mistake as memory and repeat it faster? Red-team the machinery as a system, because that is how it will behave in production.

Models will keep improving, and access to them will keep spreading. The durable advantage will not be finding the one model that never makes a bad decision. It will be building factories that turn good decisions into scalable work while keeping bad decisions small, visible, and reversible. The harness creates the leverage. That makes the harness the boundary you have to trust.