Design a sandbox for an unattended coding agent

security, agents, sandboxing, blast-radius

Prompt

Your company wants to give a coding agent shell and file-system access to run unattended overnight against a staging environment, generating and merging small PRs. Design the sandbox and the controls around it.

Interviewer's answers to clarifying questionsopen after you have asked your own

Scope of access requested? Full shell, file read/write, and git push to a staging-tracked branch; no direct production credentials.
Volume? ~20 overnight runs/night, each budgeted at $5 and 150 agent steps.
Trigger? Runs start automatically from a queue of small, well-scoped tickets (dependency bumps, test-flakiness fixes).
What's the actual blast radius if it goes wrong? Worst case discussed so far is a runaway loop burning API budget, or a destructive file operation in staging.
Review requirement? Every PR must be reviewed by a human before merge; the agent cannot merge its own PR.
Today's control? The team wants to add --trust-all-tools --no-interactive flags to speed up the pipeline, removing the one approval prompt that currently exists.

Follow-upsafter your high-level design

The agent reports a file deletion was "irreversible." Do you trust that claim, and how would your design let you verify it independently?
A dependency update the agent pulled in is later found to be poisoned. What's the actual blast radius of --trust-all-tools in your current environment?
A retry loop starts triggering on a flaky test with slightly different error text each time, so naive duplicate-detection never fires. How does your design stop it before it burns the night's budget?
Someone wants to extend this agent to touch production during business hours, "just for read-only diagnostics." What changes, and what doesn't?

Answer first: out loud, on paper, or with the interview prompt above. Then compare with the rubric.