Gemini Managed Agents adds support for developer-owned sandboxes

• Gemini Managed Agents can now execute tools in developer-controlled sandboxes, following ivanleomk's announcement, while Google retains the model and agent loop.
• Seven launch partners span sandbox services and cloud platforms, according to Google's rollout announcement: Vercel, Modal, Daytona, Fly.io, Google Cloud, Cloudflare and E2B.
• Per-interaction isolation and ready-made environments are available through the integrations shared by Daytona and E2B.

Google's runtime documentation labels direct local-host execution “unsafe.” E2B's integration gives the worker placeholder credentials and injects the real keys into outbound requests.

Execution: Google-managed Linux sandbox → developer-selected container, VM or microVM. Google still operates the model, agent loop and interaction stream, as Daytona's architecture guide explains.

The developer-controlled environment can contain private packages, preloaded data and mounted volumes. A sandbox can also be inspected while an interaction runs.

Google's reference runtime ships inside the open-source gemini-api CLI. Connections use outbound HTTPS exclusively, with no inbound firewall ports required.

The connection sequence has three steps:

1. The application calls POST /v1beta/environments with {"mode":"self_hosted"}. The response contains an environment ID and an environment-scoped key, which is returned only once.
2. A worker starts gemini-api environments connect inside the execution environment, authenticating with GEMINI_ENVIRONMENT_KEY. The project-wide Gemini API key can remain with the application.
3. The application passes the bare environment ID, without an environments/ prefix, when creating an interaction. Daytona's example uses API version v1beta, where the environment parameter is accepted.

Google holds the interaction queue; the registered environment itself supplies no compute. The worker leases interactions, executes tool calls and streams results back, according to Daytona's guide.

Daytona supports both a shared worker and a fresh sandbox for each interaction in its reference implementation.

Switching from connect to the split poll plus serve topology changes three boundaries:

• Lifetime: long-lived worker → newly provisioned sandbox per interaction, deleted when the interaction ends.
• Filesystem state: files persist between interactions → each interaction starts with a clean sandbox.
• Credentials: long-lived environment keys inside the execution sandbox: 1 → 0, -1 long-lived key. The external poller retains the environment key; the sandbox receives only a short-lived, interaction-scoped lease token.

The poller invokes a provisioning command and maintains the lease while the sandbox boots. Per-interaction credentials are the strongest part of the design.

Daytona says fresh provisioning adds a few seconds of startup time. Running both worker topologies against the same environment makes them compete for interactions.

E2B packages its integration as the prebuilt gemini-e2b template, with this launch command in its guide:

The template supplies:

• Toolchain: a pinned, checksum-verified gemini-api CLI alongside Git, Python and Node.
• Credential injection: Gemini API and environment keys remain in E2B Secrets. A network rule inserts them into requests to generativelanguage.googleapis.com; the sandbox holds placeholder values.
• Workbench: a browser UI on port 8000 displays streamed replies, tool calls and generated files.
• Access control: a per-sandbox token protects workbench API calls. The token arrives in the URL fragment, which browsers omit from server requests, and is then removed from the address bar.

Compared with passing both Gemini credentials as environment variables, vault-backed injection changes readable secret values inside the sandbox: 2 → 0, -2 readable keys.

Daytona and E2B demonstrate execution placement with functional smoke tests in their respective Daytona walkthrough and E2B walkthrough:

• Daytona: the agent creates hello.txt; the hostname returned by uname -a matches the Daytona sandbox ID.
• E2B: the agent creates the same file, and uname -a reports Linux e2b.local .... The walkthrough checks the generated file at /home/user/workspace/hello.txt.

Neither provider reports comparative task-success rates, latency distributions or cost results in these walkthroughs.

Workers expose seven built-in tools in Google's runtime reference:

• execute_bash: shell commands.
• view_file: file reads.
• list_dir: directory listings.
• grep_search: content searches.
• find_by_name: filename searches.
• write_to_file: file creation and writes.
• replace_file_content: file edits.

Structured file tools use os.Root to enforce --root-dir, blocking traversal and escaping symlinks. Shell commands execute arbitrary model-generated code outside that confinement; their security boundary comes from the container, VM or microVM.

The runtime supports --disable-bash and caps shell output at 4 MiB. Google excludes the sample configurations and deployment recipes from official product support.

E2B's secret injection is host-based, so any sandbox process can make authenticated Gemini API requests. Other outbound traffic remains open by default, according to E2B's documentation.

Daytona documents separate provisioning and execution deadlines in its guide:

• Provisioning handoff: the poller defaults to a two-minute deadline. The reference allows 60 seconds for sandbox creation and 45 seconds for worker attachment.
• Failed dispatch: an expired handoff kills the provisioning command and records a failure; the interaction can be leased again later.
• Sandbox lifetime: after attachment, the reference sandbox has a two-hour TTL, independently configurable from the handoff deadline.

E2B's example increases the sandbox timeout: 5 → 60 minutes, +55 minutes, comparing the default with the configured session in E2B's guide. Its outbound-only worker cannot trigger auto-resume on a paused sandbox, so expiration can interrupt an active task.