Under the hood: how we sandbox AI-written code
Letting an AI agent write and run code against a real repository is only safe if you're deliberate about what it can touch. Here's what actually happens between "ship it" and a pull request landing.
Credentials never enter the sandbox
The trusted supervisor — not the agent — clones your repository, using a short-lived, single-repository GitHub App installation token. That token, and every other credential (AWS, KMS, your GitHub App key), stays on the supervisor side of the boundary. The sandbox the agent actually runs in gets a working copy of your files and nothing else: no Git history, no push access, no AWS credentials beyond a Bedrock-only token scoped to a single job and expiring in minutes.
One job, one container, then it's gone
Each job gets its own container, launched fresh and torn down completely afterward — no state, no cache, no leftover files from a previous customer's job. Network access is deliberately open only for what the agent actually needs (reaching the model and fetching dependencies), and every run is bounded on time, memory and CPU so one runaway job can't starve the next one.
The working tree is the only thing we trust
We don't trust the agent's own claims about what it did. After it finishes, the actual file contents in the sandbox are compared against a baseline using Git, and only real, present differences are treated as a change. If the agent claims success but nothing actually changed, that's a failure, not a delivery.