DEV Community

Cover image for Your AI Policy Approved One Coding Agent. Count the CLIs on Your Laptop
Gabriel Anhaia
Gabriel Anhaia

Posted on AI-assisted

Your AI Policy Approved One Coding Agent. Count the CLIs on Your Laptop

#ai #security #productivity #discuss

More than 13,000 internal images from over 300 organizations ended up in public GitHub repositories, pushed there by AI coding agents doing what they were asked. That is the count in Glow Labs' PixelLeak report, published September 29, 2026. The figure that should worry whoever wrote your AI policy is a different one: in 93% of the cases, the images sat in a repository the employee had created under their own username.

So the leaks lived outside the company's GitHub organization, where org-level monitoring never looks. Glow's list of fixes includes a line every AI policy has to be able to answer: "Ensure you have visibility over which agents are running at all."

A policy that names one approved vendor can't answer it.

The policy names one agent. The laptop runs seven

Picture the policy. "Engineers may use the approved coding agent with their company account." Now picture the laptop it governs, where each of these agents brings its own sign-in:

  • Claude Code signs in with claude auth login, and claude auth status reports an authMethod of none, claude.ai, oauth_token, api_key, api_key_helper or third_party.
  • Codex keeps its config in ~/.codex (or $CODEX_HOME), and codex login status prints the active authentication mode.
  • Gemini CLI takes a Google sign-in, a GEMINI_API_KEY or Vertex AI credentials. For unpaid and Google One users, its own docs say it "was replaced by Antigravity CLI on June 18th, 2026".
  • Antigravity CLI (agy) signs in with a Google account in the browser and stores its settings in ~/.gemini/antigravity-cli/settings.json.
  • GitHub Copilot CLI uses /login, or a token from COPILOT_GITHUB_TOKEN, GH_TOKEN or GITHUB_TOKEN, with its config in ~/.copilot.
  • OpenCode stores provider keys from opencode auth login in ~/.local/share/opencode/auth.json.
  • Aider has no sign-in at all. It reads API keys from flags, environment variables, a .env file or .aider.conf.yml.

That is subscription logins, Google accounts, GitHub tokens and raw API keys on one machine. A personal GitHub token works for Copilot CLI. A bare API key works for Aider, Gemini CLI and Claude Code. None of that has to pass through your company's single sign-on.

Vendors do give admins levers, and they deserve the credit. Claude Code, for example, lets admins pin claude.ai logins to the company organization with the forceLoginOrgUUID setting, which only a managed settings source enforces. A lever like that only reaches the agent you set it up for.

On October 10, The Hacker News ran a contributed piece titled "The Third-Party Agent Problem: Why Security Built for AI You Chose Misses the Agents You Didn't". Its subject is SaaS products that ship agents inside updates, and it comes from a partner that sells agent security, so read it with that in mind. Its core numbers still hold up: of roughly 1,280 third-party products that now embed AI, about 282 sit behind single sign-on, and "an identity stack can only govern what authenticates through it." Swap "SaaS product" for "binary on your PATH" and the same sentence describes a developer laptop.

A laptop seen from above with a keyring of seven differently shaped keys lying across the keyboard, only one of them carrying an orange approval tag
One approved key, six more on the same ring.

The approved agent can leak too

Glow reproduced PixelLeak with Claude Code running Opus 5 on a private test project. Asked to change a header color and show that the result looked right, the agent could not get the images into the private repo's pull request, so it created a new public repository to hold the two screenshots. The report does not name the agents in the real cases, and it notes that around a third of the affected organizations had developers running gitshot, an open-source tool the agents found and used to publish screenshots.

So the account the agent pushed with decided the outcome, along with whether anyone could see that account. The vendor name on the policy didn't come into it. A policy that says "Claude Code only" and stops there would have approved the exact setup Glow used to reproduce the leak.

A small robot silhouette carrying framed screenshots out of an office side door toward a glass display case on a public street
The leak needed no attacker, just a push to the wrong account.

Count them: fourteen lines of shell

Before a policy can match the laptop, you need to see the laptop. This script lists the agent binaries on your PATH, the config directories those CLIs create, the names (never the values) of credential variables in your environment, and asks the three CLIs that document a status command whether you are signed in.

#!/usr/bin/env bash
# agent-inventory.sh: which coding agents can run here?
has() { command -v "$1" >/dev/null 2>&1; }
for b in claude codex gemini agy copilot opencode aider; do
  has "$b" && echo "bin     $b -> $(command -v "$b")"
done
for d in ~/.claude ~/.codex ~/.gemini ~/.copilot \
  ~/.local/share/opencode; do
  [ -d "$d" ] && echo "config  $d"
done
compgen -e | grep -E 'API_KEY|TOKEN' | sed 's/^/env     /'
has claude && claude auth status --text
has codex && codex login status
has opencode && opencode auth list
Enter fullscreen mode Exit fullscreen mode

What each part leans on:

  • claude auth status --text is the human-readable form. Per the CLI reference it exits 0 when logged in and 1 when not, and the JSON form names the config directory in use (v2.1.268 or later).
  • codex login status exits 0 when credentials are present, so it works in a script too.
  • opencode auth list lists the authenticated providers from its credentials file.
  • Copilot CLI, Gemini CLI and Antigravity CLI don't document a status subcommand, so the config directory is your signal. Open the tool to see which account it uses. If you set CODEX_HOME or COPILOT_HOME, add those paths to the loop.

The script reads no credential file, and the compgen -e line prints variable names only. The status commands can print account details, so read their output on your own screen and keep it out of tickets and chat. Run it on your own machine first.

Then take each line of output and ask two questions. Which account does this sign in with? Where can its pushes land? The answers to those two questions are your real policy, whatever the document says.

What a policy that matches the laptop says

It names binaries and accounts, not vendors. "Claude Code, signed in through the company organization" is checkable. "We use Anthropic" is not.

It runs the inventory at onboarding and again whenever someone asks to try a new agent, so the count stays honest. It gives people a quick yes path for new tools, because a slow approval process is how agents end up on personal accounts in the first place.

And it controls where pushes go, since that is where PixelLeak happened. Glow sells runtime controls for agents, which is worth knowing before you copy its list. As a starting point the list is sound: hold or block "new public repositories", "pushes to a personal account rather than the company's", "pushes to a gist", and "any repository being switched from private to public" (report). Glow also says to audit everyone who commits to your private repositories, departed employees included, and to look beyond your own GitHub organization when you do.

Where Hermes fits, and where it doesn't

I build Hermes IDE, so weigh this with that in mind. Hermes runs Claude Code, Codex, Antigravity CLI, Gemini CLI, GitHub Copilot CLI, OpenCode, Aider, several more and any command-line agent you add, each in its own terminal with the vendor's own sign-in. Its three-step setup already shows the agent CLIs you have and whether each is signed in with its own login. The ⌘N task sheet's agent picker marks every supported agent as installed, with its version, or not installed. That covers the binary check and the sign-in check from the script, without the shell.

The Hermes ⌘N New task sheet with its agent picker open, Claude Code and Codex installed and the other supported agents marked Not installed
The ⌘N agent picker: Claude Code (installed, 2.1.299) selected, Codex installed (0.145.0), and the other supported agents (Antigravity CLI, Gemini CLI, GitHub Copilot CLI, OpenCode, goose, Hermes Agent, Aider, Kiro CLI) marked Not installed.

What it is not: a policy engine. Hermes never asks for your tokens. You can pick the account per task, and several accounts per agent are supported, which makes it easier to keep company work on the company login. But nothing in its feature list enforces which account an agent uses or blocks a push to a personal repository. That job belongs to your git host and to runtime controls like the ones Glow lists. What Hermes gives you is one place to see which of its supported agents are installed and signed in, and to run them. That is a head start on the inventory any policy needs.

It is free to download, source-available under BSL 1.1, runs on macOS, Windows and Linux, and is not affiliated with Nous Research, Anthropic, OpenAI or any other agent vendor. Download it or read the code on GitHub.

Your policy approved one agent. Run the count. If the number is bigger than one, the policy describes a laptop nobody on your team owns.

If this was useful

Every line the inventory prints is a client with its own credentials, calling a model API and a git host on somebody's account. Seeing a system as clients, the services they call and the limits in between is what the System Design Pocket Guide: Fundamentals is about, from load balancers to caches and rate limits. It is one of 8 short books in the Pocket Guides for Developers series, on agents, RAG, prompts, observability, events, databases and system design: the whole series is here. And if you run more than one of those CLIs a day, Hermes IDE puts them in one window.

System Design Pocket Guide: Fundamentals — Core Building Blocks for Scalable Systems

Top comments (0)