A Secure Local Workspace for Google's AI Agents

There is no product called a Google AI agent workspace

The phrase is a reasonable way to describe what a developer wants, but Google does not sell it under that name. Three real things get described this way, and they behave very differently from a security standpoint.

Gemini CLI and the Agent Development Kit, usually shortened to ADK, both install and run on a developer's own machine. Firebase Studio, the renamed Project IDX, runs in Google's cloud no matter what you do with it.

Knowing which of the three you actually mean changes every security decision that follows, so start there before picking a setting to change.

• Gemini CLI: an open source terminal agent that runs locally.
• Agent Development Kit (ADK): an open source framework for building your own agents, also local.
• Firebase Studio (formerly Project IDX): a cloud workspace, never local.

Gemini CLI: the one that actually runs on your machine

Gemini CLI is Google's open source terminal agent, released under the Apache 2.0 license, that brings Gemini into a developer's own shell. It runs in your current directory by default and can include additional directories through a flag, and it supports both interactive sessions and scripted, non-interactive runs.

Its sandboxing is genuinely broad. On macOS it can use Seatbelt through sandbox-exec, with a profile such as permissive-open that confines writes to the project directory while still allowing broad reads and network access. On Linux it can run inside a container through Docker or Podman, or inside gVisor, which the project describes as the strongest isolation it offers because it runs containers inside a user-space kernel. On Windows it uses a native sandbox built on the icacls command to set integrity levels on writable paths.

What is not automatic is the full-process sandbox. Tool-level sandboxing, which isolates individual risky tool calls, is on by default, but wrapping the whole CLI process needs an explicit choice: the -s or --sandbox flag, the GEMINI_SANDBOX environment variable, or a sandbox setting in settings.json.

• Enable it with -s, GEMINI_SANDBOX=true, or "sandbox": true in settings.json.
• macOS: Seatbelt via sandbox-exec. Linux: Docker, Podman, or gVisor. Windows: icacls-based isolation.
• Trusted Folders lets you set a different execution policy per project folder.

Agent Development Kit: build your own, run it anywhere

ADK is Google's open source framework for building custom agents, available in Python, TypeScript, Go, Java and Kotlin. You install it locally with a single package command in whichever language you use, and you can build and test an agent entirely on your own machine before it ever touches a cloud account.

Its own description calls this deploy anywhere: you can containerize the agent and run it on your own infrastructure, or use Google's one-command deployment to options such as Cloud Run, GKE, or its managed Agent Runtime. Nothing in the framework forces the cloud path; it is an option you choose once local development is done.

• ADK runs and tests entirely on your machine during development.
• Deployment to Google Cloud is optional, not required.
• Available in five languages, so it is not tied to Python.

Firebase Studio is not a local workspace

Firebase Studio, the product Project IDX became, is described by Google as an agentic cloud-based development environment. Every workspace is a full virtual machine that Google runs on your behalf, accessible from wherever you sign in, which is the opposite of local.

Your use of it is governed by Google's Terms of Service, and generative AI features inside it fall under a separate Generative AI Prohibited Use Policy. You can stop your prompts and responses from being used for model training by not using the App Prototyping agent or Gemini assistance inside the product, but that setting changes what Google does with your data, not where the machine runs.

• Every Firebase Studio workspace is a Google-run cloud VM, not a local process.
• You can opt out of some AI training uses, but you cannot make the workspace local.

Securing the piece that is actually yours

Once you know Gemini CLI is the local piece, securing it is a short list. Pick a sandbox mode that matches your operating system and turn it on explicitly, because the default only covers individual tool calls, not the whole process.

Use Trusted Folders to scope which directories a session is allowed to touch, rather than running every project with the same wide-open policy. Keep the Gemini API key out of a plain shell profile or a committed file, the same rule that applies to any other credential a terminal agent can read.

None of this is specific to one project. Set the sandbox mode and the key handling once, in your shell configuration or in settings.json, and every new Gemini CLI session you start picks it up without you repeating the setup by hand.

• Turn on full-process sandboxing; do not rely on tool-level sandboxing alone.
• Scope folders per project with Trusted Folders.
• Keep the API key in a credential store, not a shell profile.

Where Forkbench fits

Forkbench is a desktop app for the Mac that runs coding agents, including Gemini CLI, in real terminals. If you run Gemini CLI inside a Forkbench Thread, you can lock that Thread to its project folder using the macOS kernel sandbox, and keep the Gemini API key in the Vault so Gemini CLI uses it by name without the value sitting in your shell profile or appearing in the transcript.

This sits alongside Gemini CLI's own sandbox, not instead of it. Know the limit: the folder lock is opt-in and does not restrict the network, so a locked session can still send out anything it is allowed to read, and an unpinned Vault key can still be read by the program it was handed to. Forkbench itself is a Mac app today; Windows and Linux are in development, with no date, so this layer is not yet available on either.

If you are building with ADK instead of running Gemini CLI directly, the same idea still applies to the surrounding work. You are usually editing that agent's Python, TypeScript, Go, Java or Kotlin code with a coding agent of your own, and that coding agent is the one Forkbench actually locks down and hands keys to, not the ADK agent you are building.

• Forkbench runs Gemini CLI like any other agent, in its own locked terminal.
• Folder lock does not restrict the network; it is an addition to Gemini CLI's sandbox, not a replacement.
• Windows and Linux builds of Forkbench are in development, with no date.