Running Untrusted Code Safely in AI and CI Pipelines
AI reviewers and CI systems now execute code from strangers. We break down why sandboxing alone fails and the real principles for safe isolation.
For years, CI pipelines and developer tooling assumed the code being executed was trustworthy, because the author and the runner were the same person. That assumption breaks down with AI code reviewers, CI jobs running fork PRs, and dependency bots, all of which now execute strangers' code inside trusted infrastructure. The real danger isn't the diff itself but everything triggered around it: install-time lifecycle scripts, repo-defined test/build commands, and linter or formatter configs that can load arbitrary plugins — a vector most teams overlook entirely.
A sandbox escape becomes catastrophic when the same environment also holds cloud credentials, database strings, or integration keys, turning a contained bug into a breach affecting every tenant at once. The fix isn't a tougher sandbox but one with nothing worth stealing and nowhere to pivot. The piece lays out seven concrete principles: never execute a repo's own scripts, keep secrets entirely out of the execution environment, scope credentials to the minimum and shortest lifetime, deny network egress by default, treat tool configuration as untrusted input, make environments ephemeral and non-root with strict resource limits, and request the least privilege possible for the integration itself.
The author illustrates this with their own AI PR reviewer, which analyzes each pull request in a single-use sandbox holding no platform secrets, only a short-lived, repo-scoped read-only token, with no route to internal services. The takeaway for engineers: assume isolation will eventually fail, and architect systems so that failure remains a routine, boring event rather than an extinction-level breach.