AI Security
Google's Gemini CLI adds security checkpoints before modifying build files
Version 0.61.0 requires explicit developer approval before the AI agent edits build configurations or runs commands with potentially untrusted arguments.
The New Stack
Google has rolled out a significant security update to its Gemini CLI that forces the autonomous coding agent to pause and ask for permission before taking certain risky actions. The tradeoff reflects an ongoing tension in AI development tools: the more autonomy you grant an agent, the more damage a compromised agent can inflict.
Gemini CLI 0.61.0, released this week, introduces mandatory confirmation prompts in three scenarios—before modifying build configuration files, executing build or test commands after such changes, and running shell commands that incorporate content sourced from external tools or web searches.
Why build files are an attack vector#
Build configuration files like package.json, Makefile, pyproject.toml, and Bazel BUILD files are attractive targets for attackers because changes to them can silently introduce dependencies or trigger execution of arbitrary code. An AI agent armed with web search and external tools can fetch documentation that secretly contains malicious instructions. It might edit a build file to add a postinstall script, run tests to verify the project still works, and inadvertently execute malicious code—all without the developer explicitly running any command.
The team behind Gemini CLI addressed this vulnerability head-on. Pull request #29250 prevents what security researchers call "indirect prompt injection via build file modifications." Now when the agent wants to modify recognized build files, it must get explicit sign-off from the developer. The tool tracks all build file changes during a session and holds any subsequent build or test command for approval as well. Crucially, confirmation dialogs now display full diffs rather than truncated versions, giving developers complete visibility into what's changing.
Sandboxing the untrusted content problem#
A second security layer addresses command arguments. Content pulled from web fetches, MCP server responses, Google Docs, or Google's internal issue tracker (Buganizer) is now treated as untrusted. Before the agent runs any shell command whose flags or arguments come from those sources, it asks the developer for approval. Notably, these confirmation prompts do not offer a "always approve this action" option—each time requires fresh authorization.
The implementation uses token matching rather than full-chain provenance tracking, which reviewers noted was crucial to get right. During development, Google's automated reviewer caught several potential bypasses: quoted arguments, environment-variable prefixes, shell redirections, and Windows path quirks, all of which were patched before the change shipped on September 11.

