Google · CLI agent

Gemini CLI

Google's open-source terminal agent — highly extensible, which makes its configuration the governance surface that matters.

What you are actually governing

Gemini CLI is open source and built to be extended, which is genuinely useful and shifts the governance question from vendor controls to configuration management. Behaviour comes from context files, settings files and extensions on the machine — so whoever controls those controls the agent, and in most organisations that is each individual engineer.

Context files follow the pattern the ecosystem has converged on: `GEMINI.md` is loaded automatically to give the agent project instructions, resolving hierarchically so global and project-level files combine. This is the same artifact class as `CLAUDE.md` and `AGENTS.md`, with the same property — a Markdown file that silently steers an agent and does not appear in any dependency scan.

Extensions and MCP support are where capability arrives. Because the tool is open source and easy to extend, the local extension surface is wide and the friction for adding something is low. That is a real productivity advantage and a real inventory problem: an extension is code, installed by an engineer, running with their permissions, with no central record.

The honest read on any open-source agent is that configurability is symmetric. It means a platform team *can* build precisely the controls they want, and it means nothing stops an engineer from reconfiguring past them. Which of those dominates is decided by whether configuration is distributed and verified centrally or left on each laptop.

Artifact classes this surface loads

Each of these changes what the agent does, and each arrives through a channel with no dependency review. This is the inventory a governance programme has to cover — not a feature list.

  • GEMINI.md context files
  • Settings files
  • Extensions
  • MCP servers
  • Custom commands

What Google genuinely controls

Documented controls worth configuring fully before buying anything. Every one is cited to Google's own documentation below.

  • Settings hierarchy

    System, user and project settings files layer, so a system-level file can establish defaults for a machine.

  • Tool permission configuration

    Which tools and commands the agent may use is configurable rather than fixed.

  • Sandboxing options

    Execution can be run inside a container or restricted environment rather than directly on the host.

  • Open source auditability

    The implementation can be read and verified, which is a real advantage over closed agents for a security review.

What is still open once those are configured

Not criticism of the product — the honest boundary of a per-machine configuration model. These are fleet questions, and local settings were never designed to answer them.

  • Local configuration, local trust

    Settings live on the machine. Nothing natively verifies that a laptop's configuration matches organisational policy.

  • Extensions are unvetted code

    Easy extension means easy installation of third-party code running with the engineer's permissions, with no central record.

  • Context files are unreviewed instructions

    GEMINI.md steers every session and is invisible to dependency and code scanning.

  • No cross-surface inventory

    MCP servers connected here are the same ones other AI surfaces use, governed independently in each.

Frequently asked

Is an open-source agent easier or harder to govern?
Both, and which one wins is a process question. Open source means you can audit and configure it precisely; it also means an engineer can reconfigure past your policy. The deciding factor is whether configuration is distributed and verified centrally or left on the machine.
How does GEMINI.md differ from CLAUDE.md or AGENTS.md?
Only in filename and resolution details. All three are Markdown instruction files loaded automatically to steer an agent, and all three are invisible to dependency scanning while being fully capable of changing behaviour.

Sources

Compiled from Google's own documentation on 2026-07-25. Products in this category change quickly — verify against the source before a decision depends on a specific mechanism.

Other surfaces

Concepts on this page

Govern Gemini CLI the same way you govern everything else

Vincosha Registry distributes reviewed, version-pinned artifacts to Gemini CLI and every other surface your company runs, from one source. Vincosha Assay scans them before they land, and Vincosha Ledger shows which versions were active in which session.