People often say to run an agent in a sandbox, but the useful work I want it to do is in staging and sometimes production. If it cannot reach the systems that matter, it cannot help with the problem.
At the moment, the safety mechanism in staging is me reviewing each command before approving it. That works for a while, but I am not confident I will carefully inspect every command after the tenth approval. Production is read-only for the agent, so it cannot make changes there, but that also means I still have to type and execute the fixes myself.
Our sessions are brokered and recorded through a privileged-access-management layer, but once connected the agent has a regular shell rather than being limited to tools such as Terraform, kubectl, or a cloud API. Normal change controls work well when a human is involved because that person is accountable and understands the consequences. An agent has no accountability or track record to rely on.
Is anyone using a control that evaluates commands or actions and blocks dangerous ones automatically, rather than relying on the operator to approve everything? Or are strict permissions, read-only production access, and pull-request-based deployment still the practical answer?
4 Answers
A command-level safety layer can help, but it should not be treated as a complete guarantee. Intercept the shell or tool calls, classify risky operations, restrict paths and resources, require explicit approval for destructive actions, and log every decision. Even better, avoid arbitrary shell access and force the agent through typed APIs with validation and business rules. Model instructions alone are not an enforcement mechanism.
Permissions are still the main control. Keep production read-only for the agent and give it narrowly scoped tools everywhere else. A general shell is too powerful; expose small, boring operations instead, such as restarting one approved service, reading a known log set, or creating a change request. Put the validation in ordinary code outside the model so the model cannot override it.
The safest pattern is to separate what the agent can do from what reaches production. Let it deploy automatically to staging, but have production changes go through a pull request, CI checks, and a second approval. Production deployments should only come from a protected main branch or a signed tag.
The exact execution path matters. A shell-based agent is much harder to control than one that can only call Terraform plans, deployment APIs, or carefully scoped operational functions. Put the policy at the broker or tool boundary, where it can inspect the requested action, identity, target, and change history before execution. Then keep the usual human review and rollback mechanisms for anything that can affect production.
Our privileged-access layer records and brokers the session, but the agent still gets a normal shell inside it. Replacing that with narrowly defined tools seems more promising than adding more instructions to the agent.
That is where I have landed for production too, but read-only means the agent can diagnose the issue without fixing it. I am looking for the middle ground where it can act while an external policy layer blocks irreversible or out-of-scope commands.