Running an autonomous coding or ops agent directly on your laptop feels like a superpower for the first few minutes. It reads your local repository, runs bash commands in your terminal, and fixes a failing test while you grab a drink.
Then reality sets in. A hallucinated shell command wipes a local folder, a dependency script hangs your machine, or an indirect prompt injection hidden inside a GitHub issue quietly reads your ~/.ssh keys and cloud credentials. And simply wrapping the agent in a standard docker run container does not solve it: standard containers share your host machine's operating system kernel, inherit whatever API keys you pass into them, and cannot stop a tricked process from leaking data.
If you are moving autonomous agents off your laptops into production cloud environments, here are 7 practical ways to lock down your agent sandboxes:
1. Use real kernel isolation (gVisor or microVMs), not standard Docker. Standard Docker containers isolate processes on the surface, but every container shares the underlying host operating system kernel. If an agent runs untrusted code that triggers a kernel bug, it can break out onto the host server.
In production, choose between two stronger isolation options based on your workload:
User-space kernel sandboxes (gVisor): Used by Cloud Run and GKE Sandbox. gVisor acts like a security checkpoint proxy between the container and the host OS, inspecting every file and network request before it ever touches the real hardware. It starts in milliseconds and works with normal container images, though tasks that create thousands of tiny files (like npm install or large git checkouts) run slightly slower because the proxy inspects every single file operation.
Lightweight microVMs (Firecracker / KVM): Instead of inspecting requests through a proxy, a microVM uses hardware virtualization to boot a tiny, separate Linux kernel for each agent in about 125 milliseconds. Pick microVMs (or Compute Engine Confidential VMs) when your agent needs full sudo/root permissions or runs heavy builds. If you just need a managed sandbox to run model-generated Python or bash scripts without managing servers, use the Gemini Enterprise Code Execution Sandbox.
2. Keep raw API keys and secrets outside the sandbox. A common mistake is grabbing a temporary 10-minute token from a secret manager and passing it into the agent's container as an environment variable (process.env). To a prompt-injected agent, 10 minutes is an eternity, a single curl command can steal and send that key to an external server in 200 milliseconds. Never put real credentials inside the container. Keep your keys stored safely in Google Cloud Secret Manager, and route the agent's outbound API calls through an external gateway proxy like Apigee AI Gateway. The gateway authenticates the agent via IAM Workload Identity and attaches the real API key on the way out only when the agent is calling an approved destination URL.
3. Lock down outbound network access across every step. Recent security audits of cloud coding agents found two common blind spots:
Setup script leak: Many platforms block internet access while the agent is reasoning, but leave the internet wide open during the initial npm install or pip install setup step, allowing a malicious package script in a repository to steal data before the agent even starts working.
Bash only trap: Sandboxing the bash terminal tool while letting file-reading tools, browser tools, or MCP servers run unrestricted on the host machine. Block outbound internet access by default across the entire lifecycle (VPC Service Controls and egress firewall rules). Pull code packages from a private, pre-scanned cache (Artifact Registry) instead of the open web, and only allow the sandbox to talk to an explicit list of approved domains.
4. Track cumulative actions across turns, not just single tool calls. Pre-execution hooks (like Antigravity PreToolUse hooks and ADK 2.0 tool callbacks) are essential for checking one command at a time, such as blocking rm -rf or enforcing a $50 limit on a refund tool. But single-step rules have no memory. As Google Cloud's engineering team recently demonstrated, a tricked agent will bypass a $50 limit simply by calling issue_refund($20) six times in a loop to drain $120. Pair single-step parameter checks with session-level budgets and anomaly detection at the gateway (Model Armor) so your system tracks the total impact across the whole conversation and stops the loop when behavior drifts off course.
5. Run file edits in isolated workspaces and protect CI/test files. If a coding agent can edit its own unit tests or CI/CD pipeline files (.github/workflows, cloudbuild.yaml, .git/hooks), it might "pass" a failing test simply by deleting the test assertion or slip a command into the build config that runs outside the sandbox when a human reviews the pull request. Give the agent an isolated copy of the workspace (like the isolated git worktrees in Google Antigravity), mount your test suites and CI configuration folders as read-only, and automatically block any pull request where the agent tried to modify build pipelines or security rules.
6. Avoid paying for idle compute while waiting on the LLM. An AI agent uses compute very differently than a normal web server. During a 10-minute debugging session, the sandbox might use 100% CPU for 2 seconds to run a test, and then sit 70% to 85% of the time doing nothing while waiting for the LLM to stream tokens back or waiting for human approval (Upstash 2026 Sandbox Benchmark). If you run agent sandboxes on standard 24/7 virtual machines, you pay 5x for idle CPU and memory. Use serverless runtimes with active-CPU billing like Cloud Run, where you pay for CPU only during the seconds a command is actively running and save session progress externally in Gemini Enterprise Agent Platform Sessions so idle sandboxes can shut down between turns.
7. Send audit logs outside the sandbox in real time. If you store your execution logs inside the same container where the agent has terminal access, a crashed container or a rogue command can wipe the logs before you ever see them. Stream your telemetry directly from the outside host into Cloud Trace and Cloud Audit Logs as the agent runs. For every turn, record four simple things under a single run ID:
1) what the agent asked to do,
2) whether your security rules allowed or blocked it,
3) what files or network URLs were actually touched, and
4) confirmation that the temporary container and its permissions were wiped clean when the task finished.
We shouldn't let probabilistic agents run unquarantined on our laptops or shared kernel containers. Isolate the kernel with gVisor or microVMs, keep real API keys outside the container, lock down setup-script internet access, and enforce budgets across the entire multi-turn loop.
How are you isolating your AI agents in production today? gVisor, microVMs, or external gateway proxies? Let's discuss in the comments below!
Top comments (0)