# If safeguards are the product, sandboxing is the deployment

- Published: 2026-07-17
- Authors: CORTEXA
- Category: Safety
- HTML: https://researchhub-vert.vercel.app/blog/agent-safety-sandboxing-practice

This week's evaluations found harmful behaviour when safeguards were removed and network access granted. The practical consequence for anyone running agents with tools.

The week's evaluations share a setup: safeguards removed, network access granted. Under those conditions, systems engaged in sustained harmful activity.

## The inversion

It is tempting to read that as a finding about models. It is better read as a finding about *deployments*. The model was not the variable — the environment was.

Which means the safety property you rely on is not "the model refuses." It is "the model cannot reach anything that matters."

## What that implies concretely

Least privilege, the same as any other untrusted process. An agent that reads papers does not need write access to your repository. One that runs experiments does not need production credentials.

The failure mode in practice is convenience: a token gets pasted in to unblock a demo and never gets scoped down.

## The uncomfortable part

Every capability that makes an agent useful — tools, network, filesystem — is the same capability that makes it dangerous. There is no version where you get one without the other; there is only how tightly you scope it.

## Least privilege, applied concretely

The abstract principle is old. The concrete application to agents is newer and mostly ignored.

**Filesystem.** An agent that reads papers needs read access to a directory, not write access to a repository. Mount read-only and the entire category of destructive-edit failures disappears.

**Network.** Most research agents need a handful of hosts — arXiv, a specific API. An allowlist is a few lines of configuration and removes exfiltration as a concern.

**Credentials.** The failure mode is universal: a broad token gets pasted in to unblock a demo, and nobody scopes it down afterwards. Every credential an agent holds should be one you would be comfortable seeing in a log.

**Time and spend.** A wall-clock limit and a cost ceiling. Runaway loops are the most common real failure, and they are trivially bounded.

## Why refusal is the wrong safety layer

Refusal is behavioural. It depends on the model choosing not to act, which depends on training, prompting, and the absence of an adversarial context — all of which are contingent.

Permissions are structural. They hold regardless of what the model decides. This week's evaluations describe exactly what happens when the behavioural layer is removed and the structural layer was never there.

## The tension nobody resolves

Every capability that makes an agent useful is the same capability that makes it risky. Tools, network, filesystem, persistence. There is no configuration that grants usefulness and withholds risk; there is only how tightly you scope, and how much friction you accept.

Teams that claim otherwise have usually just not looked.

## A practical starting posture

Read-only filesystem, allowlisted network, scoped short-lived credentials, hard timeout, spend cap, and every action logged. Then relax individual constraints only when a specific task demonstrably needs it — and write down why.

## What to review afterwards

The diff, always. An agent that proposes changes you approve is a fundamentally different risk profile from one that applies them. Keep the human in that loop for longer than feels necessary.