How to Sandbox AI Coding Agents

Letting an autonomous process execute code against a real codebase is a different risk profile than letting a human do it, even when the process is well-intentioned and usually correct. Sandboxing is the general term for the set of boundaries that make that risk acceptable. It's not one technique; it's a few, and skipping any of them changes what "sandboxed" actually means.

Execution isolation

The most literal form of sandboxing: running the agent's code execution somewhere that can't affect anything outside itself if something goes wrong. In practice this usually means container or VM-level isolation with kernel-level enforcement (technologies like gVisor exist specifically because container isolation alone can share more kernel surface than teams expect). The question worth asking about any "sandboxed" system is what happens if the sandbox is misconfigured or unavailable: does execution fail closed, or silently fall back to something less isolated?

Credential scoping

Execution isolation doesn't help if the isolated process still holds broad credentials. A worker that can reach every customer's database, even from inside a sandbox, is not meaningfully contained. Real credential scoping means each execution context gets only the access it needs for its specific job, ideally enforced by the credential itself, not by a promise that the code won't misuse broader access it technically has.

A single, narrow API boundary

The most robust pattern is one where the isolated worker doesn't get a database connection at all; it talks to a single, narrow API that itself enforces authorization, and nothing else. That collapses a large attack surface (every table, every query) into one boundary that's easier to reason about and audit.

Per-tenant separation

For any multi-tenant system, isolation has to hold across tenants, not just between the agent and "the outside world." A worker credential that can technically reach another customer's data is a shared-infrastructure risk regardless of how well any individual job is sandboxed.

A control outside the sandbox: human review

Sandboxing limits what can go wrong during execution. It doesn't evaluate whether the resulting change is correct; that's a different problem, and the most reliable solution to it is still a human reviewing the output before it ships anywhere that matters.

How RepoFixer implements this

Specifically, and only for RepoFixer: agent build and deploy work runs inside gVisor-sandboxed containers, with no fallback to unsandboxed execution if the sandbox isn't available. Each worker authenticates with its own per-server bearer token and talks only to RepoFixer's Worker API, never directly to MongoDB or Redis, and worker credentials are scoped so no worker can reach another customer's data. None of that replaces the review step: every agent-produced change still ships as a pull request a human decides on. The full breakdown, including the admin/customer auth separation and the Environment Vault, is on the security page; the infrastructure framing for platform and DevOps evaluators is on the platform & DevOps solutions page.