GitHub Actions에서 AI 작성 코드 샌드박싱

This post describes developing a novel approach to sandboxing untrusted PRs generated by AI agents in GitHub Actions, and using Claude to pentest the result. Writing often helps crystallize ideas and discover gaps in one’s thinking. When writing the last blog post about agentic AI security, I realized that Airut’s security model had a weakness: giving the agent access to push to GitHub enabled it to run arbitrary code in the GitHub Actions environment, which allowed a network sandbox escape. Oops. Despite a number of security reviews, neither Opus 4.6 nor Gemini 3.1 Pro realized this vector until I pointed it out myself. During the development of the solution here, Claude also repeatedly failed to correctly capture the exact scope and nuances of the vulnerability; reasoning across system boundaries, especially when the configuration and interaction surface is complex, is hard for LLMs as well. The escape has two paths, both of which must be closed. The agent can push a workflow file that runs attacker-controlled code directly on the runner. Or, more subtly, it can modify code that existing workflows execute (test suites, build scripts, linters) without touching the workflow file at all. The second path requires nothing beyond normal git push access and a workflow trigger the agent can activate. This is an instance of the lethal trifecta where GitHub Actions provides unrestricted external communication. I brainstormed several potential fixes for the problem and found many restrictions in the GitHub Actions model that make it tricky to secure against agentic AI. As I wrote in the last blog post: Existing systems not designed with agentic AI in mind compound the problem. I almost asked Claude to implement a new CI system that would provide the necessary security model. However, I realized that with very careful configuration of repository rules and GitHub Actions, I could run the core Airut sandbox within the Actions environment in a way the agent couldn’t tamper with. The result of that discovery is airutorg/sandbox-action , which uses Airut’s sandbox library and a new airut-sandbox command to securely run code from untrusted PRs. This effectively extends Airut’s sandbox from the service itself to the GitHub Actions environment. Airut Sandbox Airut’s sandbox runs each task in a dedicated rootless Podman container on an internal network with no direct internet access. All HTTP(S) traffic is transparently routed through an mitmproxy instance that enforces a domain allowlist — no HTTP_PROXY environment variables are needed, so the interception works with all tools regardless of language or framework. A custom DNS responder returns the proxy’s IP for all queries and never forwards upstream, blocking DNS exfiltration. Credentials are never exposed to the container: masked secrets are replaced with format-preserving surrogate tokens that the proxy swaps for real values only on requests to scoped hosts, and AWS signing credentials are re-signed by the proxy so the secret key never enters the container. The security rests on a key architectural property: the configuration that governs the sandbox (network allowlist, container image definition, secret masking rules) is always read from the repository’s default branch, not from the agent’s working directory. The agent can propose changes to these files via pull request, but a human must review and merge before changes take effect. Extending to GitHub Actions GitHub Actions runners are ephemeral, but ephemerality alone does not make them a sandbox. Standard runners give workflow steps full outbound network access and expose repository secrets as environment variables — a malicious PR that modifies test scripts or build steps can exfiltrate those secrets to any external server. The core of the solution is airut-sandbox , a standalone CLI that exposes the same container isolation, network allowlisting, and credential masking as the Airut gateway, without any coupling to its email or Slack handling. It reads sandbox configuration from .airut/ in the working directory, builds or reuses a container image, starts the network proxy, and runs the given command inside the container. airutorg/sandbox-action is a GitHub Action that wraps airut-sandbox for pull request workflows, handling base-branch checkout, PR SHA fetching, and sandboxed execution in a single uses: step. The action’s execution follows a careful trust boundary. It installs airut-sandbox from PyPI on the runner (trusted code), checks out the base branch to load trusted .airut/ configuration (Dockerfile, network allowlist, secret masking rules), and fetches the PR commit objects on the host — so GitHub credentials never need to enter the sandbox. Only then does it invoke airut-sandbox , which builds the container, starts the network proxy, and runs the CI command. The PR code is checked out and executes inside the container under the full set of sandbox restrictions. The secure configuration requires three external