al-ice.ai

Google Cloud Run Sandboxes Put Agent-Generated Code Behind Deny-by-Default Egress

Security by al-ice.ai Editorial

Google Cloud has put Cloud Run sandboxes into public preview, introducing an isolated execution boundary for untrusted binaries and code produced by AI agents. The important security choice is not merely process isolation: credentials, metadata access, outbound networking, and filesystem writes are constrained separately.

What changed

  • A Cloud Run service can enable the sandbox launcher at deployment and start short-lived sandboxes from application code with the mounted sandbox command.
  • Sandboxed programs cannot read the parent Cloud Run service's environment variables or call the Google Cloud metadata server, according to Google's announcement.
  • Outbound network access is denied by default. A developer must explicitly use --allow-egress when a workload needs external connectivity.
  • The sandbox sees the container filesystem as read-only. Writes go to a temporary in-memory overlay that is discarded when execution ends, although applications can explicitly import or export archives.
  • Google says the lightweight boundaries start in milliseconds and run on the service instance's existing CPU and memory. The capability is currently public preview, not general availability.

Why it matters

Agent code execution turns model output into an infrastructure input. A prompt injection, compromised dependency, or simply incorrect generated program can become a credential theft or data-exfiltration path if it inherits the agent host's authority. Cloud Run sandboxes address several of those paths at the runtime layer rather than relying on a model to recognize hostile instructions.

The default-deny egress policy is particularly consequential. Many code-execution products isolate processes while still allowing arbitrary outbound connections, leaving an attacker a direct channel for exfiltration. Blocking that channel by default makes an unsafe opt-in visible in deployment and invocation code. Credential and metadata isolation similarly reduces the value of code execution inside the boundary.

This does not make generated code inherently safe. Explicitly enabled egress can restore an exfiltration path; imported files may contain sensitive data; exported archives cross the disposable boundary; and the surrounding service still decides what input and output the sandbox receives. Preview status also calls for measured adoption and independent testing before high-assurance use.

Defensive engineering guidance

  • Keep egress disabled unless a narrowly defined task requires it. If networking is necessary, place destination controls outside the sandbox rather than treating --allow-egress as sufficient policy.
  • Pass only task-scoped files and values into the boundary. Do not mount broad datasets and assume process isolation compensates for excessive data access.
  • Set execution timeouts and resource limits, and treat stdout, stderr, exported files, and browser results as untrusted before returning them to an agent.
  • Log sandbox creation, arguments, egress decisions, imports, exports, timeouts, and failures so investigators can reconstruct agent actions.
  • Use the sandbox as one layer in an agent control plane that also includes tool allowlists, least-privilege identities, prompt-injection defenses, and approval gates for consequential actions.

Sources: