Gemini Managed Agents: Self-Hosted Sandboxes, Trust Boundaries, and What Coding Teams Should Log

Google AI Studio's Environments in managed agents documentation now includes a self_hosted path: Managed Agents on the Gemini API can execute tools inside compute you control while Google continues to run model inference and the agent harness. The pattern is a split trust boundary—easy to misread as "fully private agents" if you only skim partner setup guides built around the open-source Gemini API CLI. Orchestration and planning still flow through Google's Interactions API; only bash execution, installed packages, and files on disk move to your sandbox worker. If your team already runs Claude Code or Codex on laptops beside cloud experiments, this option adds another place secrets and outbound network policy must be governed.

explainx.ai covers the product announcement timeline alongside other Gemini API launches this week; the security mechanics below come from Google's published agent environment docs and the Agents overview.

TL;DR

What Google shipped: hosted vs self-hosted environments

Managed Agents already provisioned Google-hosted Linux sandboxes—Ubuntu-based images with Python 3.12 and Node.js 22, seven-day inactivity expiry, and optional network allowlists (Agents overview). The environment parameter accepts "remote", a reused environment id, or a config object with sources and network rules (agent environment docs).

The documentation's self_hosted mode works like this:

1. Call POST /v1beta/environments with {"mode": "self_hosted"} to receive an environment id and a one-time environment_key.
2. Inside your sandbox, run gemini-api environments connect from the open-source google-gemini/gemini-api-cli repository with that key.
3. Pass the environment id in the environment field when calling interactions.create.

Google states the worker connects with outbound HTTPS only—no inbound firewall ports required on your side. Deployments can use Docker, rootless Podman, provider workers, or local test mode.

Feature split that trips up security reviews

Google documents an explicit compatibility cliff:

Hosted-sandbox options (sources, network, env, and /files snapshots) apply only to Google-hosted environments. Self-hosted environments reject them with 400 INVALID_ARGUMENT.

Practical consequences:

Teams moving to self-hosted to satisfy compliance often lose Google's packaged guardrails unless they reimplement them in the worker image.

Local test mode is a coding-agent risk

The same doc page warns:

Local mode runs execute_bash directly on your host unless you pass --disable-bash.

That is materially the same trust decision as leaving Claude Code or Codex on an unscoped developer laptop—but the planner runs in Google's cloud while commands land on metal. Treat local connect mode as high risk: separate OS user, no corporate VPN routes, no .kube or cloud CLI credentials in PATH, and time-boxed API keys.

Connecting the worker: what the CLI actually does

Google routes self-hosted execution through the google-gemini/gemini-api-cli package—the same CLI surface that exposes environments connect, environments poll, and environments serve. Architecturally, your sandbox runs a long-lived or on-demand worker that:

1. Authenticates outbound to Google with the one-time environment_key during setup.
2. Maintains a session tied to the environment id you pass into later interactions.create calls.
3. Accepts execution jobs from Google's agent runtime and returns stdout, stderr, and exit metadata the model reads on the next turn.

That is different from MCP over stdio on a laptop: the planner never runs inside your VPC, only the effectors do. Security reviews should ask who can create environments in the Google Cloud project, who can read interaction transcripts, and whether VPC endpoints expose internal admin panels to the worker subnet.

Provider guides such as Daytona's Gemini Managed Agents walkthrough describe wiring this worker into container platforms for concurrent sandboxes. Your SRE checklist still includes per-tenant isolation, image signing, and kill switches—Google's preview docs do not absolve you of compromise response on the worker fleet.

How orchestration still works

The Agents overview describes Managed Agents as a single API call that provisions reasoning, code execution, file management, and browsing inside a sandbox. Important defaults for defenders:

• OS-level isolation for each environment.
• Unrestricted outbound network by default, restrictable with an allowlist on Google-hosted environments.
• Managed credentials for external tools: secrets are stored as credential IDs and injected by an egress proxy so they are not exposed inside the sandbox—but the agent may still use anything you grant.

When execution is self-hosted, Google still selects tools and issues execution requests to your worker. Your logging must capture both sides: Google Cloud/API audit (where available) and worker stdout, syscall, and egress logs.

Preview limits that affect security design

Google's environment documentation lists preview constraints worth copying into your threat model:

• Inactive offline environments expire after seven days with TTL cleanup; stale environment_id values return 404.
• New Google-hosted environments can take up to ~5 seconds to provision—self-hosted latency depends on your autoscaler.
• Agents currently read text and image files inside environments; binary file support is not yet available (which may push teams to fetch binaries via execute_bash and curl instead).
• interactions caps include up to 1,000 managed agents per the overview table—self-hosted fleets need their own quota guardrails.

These limits change in preview; pin doc revision dates in your internal runbooks when auditors ask what you verified.

What this means if you run AI coding agents

Many organizations run cloud Managed Agents for demos and desktop coding agents for daily work. The new sandbox path affects three collision points:

1. Secret sprawl across three stores

Developers may store Gemini API keys in shell profiles, GEMINI_API_KEY in CI, managed credential IDs in Google console, and AWS/GCP keys inside the self-hosted VM the agent can reach. GitGuardian's ARTEX-era guidance applies symmetrically: offensive loops hunt the same material your benign agent reads. Rotate keys shared between Gemini workers and local agent workspaces.

2. Network path to internal APIs

Google-hosted sandboxes default to open egress. Self-hosted sandboxes inherit your VPC routing. An agent that could only reach the public internet on Google's sandbox might reach internal.company.com when you move execution inside the corporate network. Mirror Chrome Modern Web Guidance lessons—agents misread staging hosts as production—but add VPC security groups and service mesh auth on every endpoint the worker can touch.

3. Provider scale claims vs your SRE budget

Partner integrations (container platforms and sandbox vendors documented alongside the CLI) can scale many concurrent workers, but your ops team still owns patching, idle shutdown, compromise response, and tenant isolation when workers are yours. The Agents overview also notes up to 1,000 managed agents per project on the hosted side—self-hosted shifts capacity planning to your provider bill.

4. Hooks and custom agents still live in the sandbox

Google's environment documentation points forward to Hooks for guardrails inside the sandbox and Building Custom Agents with AGENTS.md and SKILL.md. Those files are instruction surfaces—the same class Beam heuristically scans for risky patterns when they land in Claude Code skills. Review custom agent markdown before mounting it into a worker with production network reach.

How Beam handles this

Beam watches local coding agents—primarily Claude Code and Codex with hook-based PreToolUse denies, plus heuristic skill and MCP config scanning before you run instructions. It keeps telemetry on-device by default and does not sit inside Google's Managed Agent control plane.

Where Beam still helps in a Gemini + desktop agent hybrid:

• Developers who run gemini-api environments connect in local mode without --disable-bash are effectively running another autonomous shell on the same laptop as Claude Code. Beam can flag destructive commands and credential reads on Claude Code and Codex (hook-based PreToolUse deny when enforce policy is cached; fail-open when policy cache is missing) while you experiment.
• Skills and MCP JSON copied between Gemini custom agents and desktop agents should pass through Beam's scanner so obvious exfil or curl | bash patterns fail before enablement.
• Beam is not a sandbox hypervisor, not a cloud SIEM for Interactions API traffic, and not a substitute for VPC egress policy on self-hosted workers. Use Google logging plus your worker telemetry for cloud-side assurance.

Comparison to other sandbox moves

Claude Cage-style VM isolation (covered on explainx.ai) pushes network isolation for desktop Claude Code. Gemini's self-hosted option pushes execution to your cloud while keeping planning remote—the opposite split. Bay AI's hook-first runtime targets IDE-integrated agents. None of these replace the others; they stack when teams run multiple agent runtimes during preview churn.

Setup checklist (from Google docs)

Use this when approving a pilot:

1. Create self_hosted environment via POST /v1beta/environments; store environment_key in a one-time secret channel, not git.
2. Connect with gemini-api environments connect inside an ephemeral VM class, not a shared pet server.
3. Deny local mode on developer laptops unless using --disable-bash or a throwaway VM.
4. Re-implement network restrictions Google would have applied on hosted sandboxes—default deny egress, allowlist package registries only if needed.
5. Scope managed credentials to the smallest API surface; rotate after demos.
6. Log worker execution and retain artifacts outside the sandbox disk Google cannot snapshot for you on self-hosted.
7. Document which interaction outputs may contain customer data returned to Google's API for model processing—legal review, not just security.

Related reading

• Google Chrome Modern Web Guidance for coding agents (November 2026)
• Bay AI runtime hooks and what they catch locally
• Klad PAINT CLI skills and local command risk
• Wiz Cyber Model Arena: offensive coding agent benchmarks
• AgentRun open-source managed agents and sandbox boundaries
• Introducing Beam: local-first agent security
• Beam docs: MCP scanning overview

Frequently asked questions

What is the self_hosted environment mode?

Google AI Studio documentation describes self-hosted environments: create with mode self_hosted, connect with gemini-api environments connect, and pass the environment id to interactions.create.

Does self-hosting keep prompts off Google's servers?

No. Model inference and agent orchestration still run through Google's Interactions API. Self-hosting moves execution and local files to your infrastructure.

Which sandbox providers are mentioned?

Google documents the Gemini API CLI worker pattern with Docker, Podman, local mode, and partner integrations referenced in launch posts. Confirm the live provider list in Google AI Studio docs before production design.

Do hosted-only environment features work on self-hosted sandboxes?

No. sources, network, env, and /files snapshots return 400 INVALID_ARGUMENT on self-hosted environments per Google.

What is the risk of local test mode?

Local mode runs execute_bash on your host unless you pass --disable-bash. Treat it as running a cloud-directed shell on your laptop.

Can Beam monitor Gemini Managed Agents in the cloud?

No for Google's hosted runtime. Beam can still help on local coding agents and scan skills/MCP configs developers reuse across Gemini custom agents and desktop tools.

API schemas, preview limits, and partner lists are accurate as of November 11, 2026, per Google AI Studio agent environment documentation and the Agents overview. Preview features may change without notice.