People often suggest running an agent in a sandbox, but that can defeat the purpose when the agent needs to work with staging or production systems. Right now, the safety process is mostly reviewing each command before approving it, and that becomes unreliable after enough repetitions. Production is read-only, while staging uses a brokered and recorded shell session with real dependencies, but there is no command-level enforcement beyond human approval. Are there systems that can detect and block dangerous commands automatically while still allowing the agent to perform useful operational work, or are strict permissions, limited tools, and human review still the practical answer?
4 Answers
The safest pattern is to avoid giving the agent unrestricted shell access. Give it a small set of narrowly defined tools, such as deploying a specific service, reading logs, or restarting an approved workload. Each tool should be ordinary code with validation and business-rule checks outside the model. Model instructions are not a security boundary because the model is probabilistic; the enforcement needs to happen in the tool layer or execution broker.
A sandbox does not have to mean an isolated toy environment. It can mean the agent has access only to explicitly allowed resources and operations. For example, it could deploy to staging, inspect production, or open a proposed production change without being able to merge or execute it. The normal change-management process still applies; the agent should not bypass the controls that protect production.
Permissions and deployment controls are still the standard answer. Keep production read-only for the agent, have it prepare a change or pull request, and let CI deploy only from a protected branch or signed tag after another approval. For staging, use the same principle where possible: broker the session, record it, limit credentials, and separate read access from mutation access.
That is basically where we have ended up for production. It works, but it also means the agent can investigate the exact problem without being able to fix it, so the human still has to type the risky command. The gap is allowing useful action while blocking irreversible operations automatically.
A general-purpose agent connected directly to a production shell is effectively an untrusted operator with a very powerful tool. A better design is to put it behind an execution gateway that understands the command or, preferably, exposes structured operations instead of Bash. The gateway can reject destructive commands, enforce allowlists, require approvals for high-risk actions, and log everything. Even then, it is defense in depth rather than a guarantee, so production access should remain narrowly scoped.
That is the distinction I keep coming back to. If the restriction only exists in the agent's instructions, it is just a suggestion. The actual block has to happen outside the model, and I was wondering whether people are running that kind of command or tool-level enforcement in practice.