Free-range AI still needs a fence

A coding agent can give a founder a working feature before they know whether it is safe to run.

The button appears. The test that the agent wrote passes. A deployment is one click away. Then somebody has to answer less pleasant questions: did it change an authorisation path, add a migration that cannot be reversed, send customer data to a new service, or leave a credential in a log?

The problem is not that people without a traditional programming background are suddenly able to make software. That is useful. The problem is that generating a change and evaluating its consequences are different jobs.

A founder can recognise that a feature solves the problem they described. They may not recognise that it has quietly changed the trust boundary around the product.

That is the moment a coding tool needs a fence.

The demo and the system are different things

A prototype answers: does this idea work well enough to show someone?

A production change answers a much larger set of questions. Who may use it? What data can it read? What happens when a dependency fails? Can it be rolled back? What does it cost when it succeeds more often than expected?

Experienced engineers miss these things too. The point is not to reserve software creation for people who already know every failure mode. It is to make the dangerous parts visible and difficult to skip.

The useful boundary is not a warning saying “be careful”. It is a system that gives the agent less authority than the operator, captures what it did, and makes promotion a separate decision.

Give the agent a job, not a master key

The first practical decision is where generated code runs.

An agent should be able to inspect a repository, create a branch, run tests and start a disposable service without inheriting the operator’s shell, production database, cloud account or browser session. Some tasks need access to real systems, but that access should be granted for the task, not assumed because the agent happens to be running on the same machine.

This changes the failure mode.

A bad patch can still waste time. A confused agent can still produce a poor answer. But a prompt injection inside an issue, dependency or source file no longer starts with the same authority as the person who opened the editor.

The boundary has to include the network as well as the process. A sandbox that cannot write to the host but can send every file it reads to the internet has contained only part of the problem.

Turn the change into evidence

The next decision is what the human sees before approving a change.

A diff is necessary, but it is not enough. The operator needs the facts that make the diff meaningful:

• which files, services and credentials the task could access;
• which commands actually ran;
• which tests passed and which did not run;
• whether the change includes a schema migration or external request;
• what would be deployed and where;
• what the rollback path is.

This is where many agent tools become unhelpfully theatrical. They describe a plan, stream activity, and end with a confident summary. The useful output is quieter: a bounded record of authority, action and result.

If the product cannot show that record, the operator is being asked to approve a story about a change rather than the change itself.

A fence should match the consequence

Putting every task behind the strongest available boundary makes ordinary work slow and expensive. Giving every task broad access makes the fast path unsafe.

The practical answer is a gradient.

A request to explain a codebase may need read-only access to a copy. A request to add a feature may need a branch, a test environment and no production credentials. A request to change a live billing rule needs a named approver, narrow authority, an audit record and a known recovery path.

The important part is that the system makes these differences explicit. It should not silently turn an analysis task into a production-capable one because that is convenient for the model.

What GlobalStacks needs to make possible

GlobalStacks should give an operator a place to run agent work where the available authority is deliberate.

That means isolated execution, network policy, scoped secrets, durable task evidence and promotion controls that remain visible when a task reconnects or fails. It also means being honest about the limit: a sandbox cannot make a production action harmless when the operator has deliberately granted production authority.

The product connection comes after the lesson. More people should be able to turn an idea into working software. They should also be able to see which permissions, money and irreversible actions sit between a convincing demo and a system they are willing to operate.

That is the fence worth building.

← All writing