llm-gemini 0.36 Release: What Security Teams Must Know About Governing LLM CLI Tooling in the Enterprise

Simon Willison released version 0.36 of llm-gemini, the plugin that connects his widely used llm command-line tool to Google's Gemini API. On its face, this is a routine open-source release note — not a vulnerability disclosure, not an incident report. So why does it belong on a security blog?

Because releases like this are exactly how shadow AI enters your environment. The llm ecosystem has become the de facto Swiss Army knife for developers, analysts, and engineers piping data through large language models. Every point release — new model support, new features, new dependencies — is a supply-chain event, a potential API-key handling change, and a data-egress path that most security teams have zero visibility into. If your developers are running llm with a Gemini plugin on workstations or build servers, version 0.36 just changed code on your endpoints, and there is a strong chance nobody in security reviewed it.

This post is not an attack on Willison's tooling — it is well-built, transparently developed, and I recommend it for controlled use. It is a practitioner's look at the defensive obligations that come with this class of tooling.

What llm-gemini 0.36 Actually Is

llm-gemini is a Python package (distributed via PyPI) that registers Google's Gemini model family with the llm CLI. Users authenticate with a Google AI Studio or Vertex AI API key, then send prompts — frequently containing source code, log files, documents, or clipboard contents — directly to Google's API from the terminal. Point releases in this series have historically added support for new Gemini model versions, new parameters, embedding support, and tool-use capabilities.

From a defender's perspective, the relevant properties of this tool class are:

Direct API egress: Every invocation sends user-supplied content to an external API endpoint (generativelanguage.googleapis.com or Vertex endpoints). DLP tools that don't understand this traffic will miss it entirely.
API keys on endpoints: Keys are typically stored via llm keys set gemini, persisted in a local keys file under the user's config directory (e.g., ~/.config/io.datasette.llm/). A Gemini API key on a developer workstation is a billable, abusable credential.
Logged prompt history: The llm tool logs prompts and responses to a local SQLite database by default. That database can quietly become a repository of source code, credentials pasted into prompts, and internal documents.
Supply-chain surface: Installing or upgrading via pip install -U llm-gemini pulls the package and its dependency tree from PyPI. Version 0.36 is new code executing wherever the tool is installed.

Why This Matters Right Now in 2026

Two trends make this release worth a security review cycle. First, LLM CLI tooling adoption has exploded in engineering and even SOC workflows — analysts summarizing logs, developers debugging with pasted stack traces, IR teams drafting reports. Second, AI tooling has become a proven supply-chain and credential-theft vector: typosquatted PyPI packages mimicking popular LLM plugins, infostealers adding LLM tool config directories to their collection lists, and prompt-log databases showing up in breach forensics. A point release of a popular plugin is the moment to re-baseline what is installed, what keys exist, and where the data is going.

Executive Takeaways

Inventory the tool before you govern it. Query your EDR/software inventory for llm, llm-gemini, and the associated config paths (~/.config/io.datasette.llm/, %APPDATA%\io.datasette.llm). You cannot write policy for tooling you haven't enumerated. Include build agents and shared jump hosts — these tools spread there quietly.
Treat LLM API keys as first-class credentials. Gemini API keys stored on endpoints should be in your credential-hygiene scope: rotate them, scope them to specific GCP projects with spend caps, and monitor for keys appearing in unapproved locations. Extend your infostealer-loss playbooks to cover LLM tool config directories — if a developer workstation is compromised, assume the Gemini key and the full prompt-log SQLite database are exfiltrated.
Pin and vet versions; don't allow blind upgrades. If you permit llm-gemini internally, distribute it through an internal PyPI mirror or artifact repository with version pinning, and require review of the package diff between releases (the project is open source on GitHub — the delta for 0.36 is reviewable in minutes). Auto-updating developer tooling from public PyPI is an uncontrolled code-execution pipeline.
Classify LLM API egress in your DLP and network monitoring. Add generativelanguage.googleapis.com and Vertex AI endpoints to your cloud/AI service inventory. You don't have to block them — but prompt traffic carrying source code or regulated data (HIPAA, PCI) to a personal API key is a policy violation your current controls likely cannot see.
Address the local prompt-log database explicitly. The llm tool's default logging means a searchable history of everything your staff ever prompted sits on disk. Decide whether that's acceptable, configure no-log options for sensitive use cases, and include that database path in forensic acquisition checklists — it is now relevant evidence in insider-threat and data-leak investigations.
Write the shadow-AI policy before the incident. Most organizations discover unsanctioned LLM tooling during an IR engagement, not before it. A one-page acceptable-use standard — approved tools, approved keys, prohibited data classes in prompts — costs almost nothing and gives you something to enforce when you find an engineer pasting customer records into a terminal.

Bottom Line

llm-gemini 0.36 is a routine, legitimate release from a reputable open-source maintainer. The risk isn't the package — it's the absence of governance around the entire category of tooling it represents. Use this release as the trigger to inventory, credential-scope, and egress-monitor LLM CLI usage in your environment. The organizations that get ahead of shadow AI now are the ones that won't be explaining an untracked data egress path to regulators later.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub