Sandboxing and Permission Models for AI Coding Agents

An AI coding agent that can read files, write code, and run shell commands is powerful precisely because it doesn’t need to ask permission for every step. That same property is what makes an ungated agent risky: it can also delete something, push something, or run something destructive without a human catching it until after the fact. The fix isn’t turning autonomy off, it’s deciding deliberately what should run freely, what should require approval, and what shouldn’t be automatable at all.

Three Tiers Worth Distinguishing

Safe to run automatically. Read-only operations: searching code, reading files, running tests that don’t touch production data. These have no destructive side effect if the agent’s reasoning is wrong, so gating them behind manual approval just adds friction with no safety benefit.

Should require explicit approval. Anything that changes state outside the local working copy: pushing to a remote branch, deploying, sending an email or Slack message, modifying a database that isn’t a disposable local instance. These are recoverable if wrong, but the cost of being wrong is real enough that a human should see the specific action before it happens, not just the general task description.

Should never be automatic, full stop. Destructive git operations (force push, hard reset on a shared branch), anything touching production secrets or credentials, and anything that disables the safety mechanism itself. If an agent can turn off its own sandboxing as a step within a task, the sandboxing was never actually a boundary.

Sandboxing vs. Permission Prompts

These solve different problems. Sandboxing (running the agent in a container, VM, or restricted filesystem scope) limits the blast radius if something goes wrong, the agent simply can’t reach production infrastructure because it isn’t network-accessible from where it’s running. Permission prompts add a human checkpoint before a specific risky action, regardless of environment. A well-configured agent setup uses both: sandboxing as the hard boundary, permission prompts for the judgment calls inside that boundary.

Common Mistakes

• Treating “the agent asked and I said yes once” as a policy. A one-off approval for a specific action is not the same as deciding that class of action should always be pre-approved. Scope approvals narrowly, to the specific action, not broadly, to everything the agent does from that point forward.
• Running agents with full production credentials “to save time.” If an agent’s task doesn’t require production access, it shouldn’t have production credentials available to reach for, even accidentally. Scope credentials to what the task actually needs.
• No audit trail. If an agent takes an action, there should be a log of exactly what command ran and why, in enough detail to reconstruct the decision later. Without this, diagnosing an incident caused by an agent action is guesswork.
• Assuming a capable model won’t make a destructive mistake. Model capability and safe defaults are separate concerns. A highly capable agent following flawed instructions, misreading a task, or working from stale context can still take a destructive action; the permission model exists precisely for the cases where reasoning goes wrong, not just the cases where it’s obviously insufficient.

Where to Draw the Line for Your Team

There’s no universal answer, a solo developer prototyping locally can reasonably tolerate more automatic behavior than a team with agents running against shared infrastructure. The actual exercise worth doing is writing down, explicitly, which of the three tiers above every action in your workflow falls into, before an agent is running unsupervised long enough that the gap gets found the hard way.