Securing AI Coding Agents and CLIs: The Complete Guide for Security Teams (2026)

Every security team in 2026 faces the same decision: you can block AI coding agents and watch developers route around you, or you can govern them - and most teams have no inventory to govern from. Securing AI coding agents is no longer an edge case, because the 2025 Stack Overflow Developer Survey put adoption at 84% of developers using or planning to use AI tools, with 51% using them every day. That is the install base; the exposure is that the same survey found 46% do not trust the output. This guide is the practitioner's playbook for that gap: what the risk actually is, why your existing controls miss it, how the same attack patterns repeat across every vendor, and how to inventory, govern and audit the agent and CLI layer. The first move is to see what you have - and as Anomity's fleet visibility shows, you cannot govern what you cannot see.

The scale is still climbing. Gartner projects that 90% of enterprise software engineers will use AI code assistants by 2028, up from under 14% in early 2024. Bottom-up adoption at that rate is the same dynamic that made AI agents and MCP servers the new shadow IT: tools arrive through individual developers, not procurement, and no security tool reports them by default. Treat this guide as the companion to the sibling pillar on MCP server security - the agents below are the clients that consume those servers.

Throughout, every claim is anchored to a real disclosure. The thirteen advisories in this cluster - covering Amazon Q, Claude Code, Cline, Cursor, Gemini CLI, GitHub Copilot and OpenAI Codex - are the evidence that the patterns are not theoretical. Where a control matters, it links to how Anomity implements it, and to the specific advisory that proves the case.

What is an AI coding agent, and why is it an endpoint and not an app?

An AI coding agent is a tool that reads your code and context, plans a change, and then acts - running shell commands, editing files, calling networks and invoking MCP servers - usually on a developer laptop or a CI runner. That last word, acts, is the whole problem. A chatbot returns text you choose to use; an agent executes. The moment a tool can run npm install, write to disk or open a network connection on its own, it is an endpoint with the developer's privileges, not a passive application.

This reframes the security question. You are not asking "is this app vulnerable?" - you are asking "what is this autonomous process allowed to do on this machine, and who decided?" The Anomity model treats the coding agent and its CLI as one of eight AI artifact types it inventories per endpoint - AI agents, MCP servers, extensions, skills, plugins, secrets, hooks and CLIs - because the risk is distributed across all of them, not concentrated in a single binary.

The practical consequence: a control that watches the network or the disk arrives too late, because the agent's own approved tool call is the exfiltration path. Governance has to sit at the point of action - the tool call - which is where Anomity's allow/deny/log operates.

Why don't my existing controls - EDR, DLP, network - catch this?

Because the malicious action wears a trusted uniform. When Google Gemini CLI before 0.1.14 chained ; env and ; curl past an allowlisted grep prefix, the environment variables left the machine through the agent's own approved tool call. EDR saw a signed binary doing its job. The network saw ordinary outbound HTTPS. DLP saw nothing at rest. Tracebit disclosed this two days after Gemini CLI's June 25, 2025 release, and it shipped with no CVE - see the Gemini CLI silent code execution advisory for the full chain.

Each existing control was built for a different layer. EDR watches processes and won't flag a coding agent it is told to trust. DLP watches data at rest and in motion, not the semantics of a tool call. Network tools watch traffic, not which AI artifacts exist on an endpoint. None of them inventory the agent layer or evaluate whether a specific tool call should run. Anomity is explicit that it complements, not replaces Network, EDR, DLP and GRC tooling - it covers the artifact layer those tools were never designed to see, which is exactly the outcomes gap this cluster keeps exposing.

What attack patterns actually repeat across vendors?

The vendor names change; the patterns do not. Across the thirteen advisories in this cluster, five families recur, and recognizing them is more useful than memorizing CVEs - because the next disclosure will be a new instance of an old shape. The throughline is prompt injection, which OWASP ranks LLM01, the top LLM risk for the second consecutive edition.

Allowlist and auto-approve bypass

Agents let users mark commands or modes as "always allow," then fail to re-check what actually runs. Gemini CLI matched only the start of a command, laundering chained env/curl past an approved grep. GitHub Copilot's YOLO-mode flaw, CVE-2025-53773, turned auto-approve into remote code execution - detailed in the Copilot VS Code YOLO-mode RCE advisory.

MCP trust bypass

Coding agents trust their configured MCP servers, and that trust is swappable. Cursor's MCPoison (CVE-2025-54136) let an approved MCP entry be silently replaced with a malicious one for persistent code execution; CurXecute (CVE-2025-54135) turned an MCP prompt injection into RCE. See the MCPoison and CurXecute advisories.

CI token theft via attacker-controlled input

Agents in CI run with privileged tokens and read attacker-controllable strings. OpenAI Codex was exploited through a malicious branch name to steal a GitHub token (BeyondTrust Phantom Labs); the Claude Code GitHub Action allowed a permission bypass and secret exfiltration; and Cline's GitHub Actions compromise produced an unauthorized npm release of [email protected]. See the Codex branch-name injection, Claude Code Action bypass, and Cline npm release advisories.

Project-file and hook execution

Files the agent reads to understand a repo become an execution vector. Claude Code project-file RCE and API-token exfiltration covered CVE-2025-59536 and CVE-2026-21852; Cursor's Git-hooks sandbox escape (CVE-2026-26268) abused hooks for RCE. See the Claude Code project-file RCE and Cursor Git-hooks escape advisories.

Supply chain and fake installers

When tools arrive off-policy, the installer itself is the threat. An SEO-poisoning campaign (EclecticIQ) delivered fake Gemini CLI and Claude Code installers carrying an infostealer; the Amazon Q Developer VS Code extension shipped a wiper-style prompt injection (GHSA-7g7f-ff96-5gcw); and the Comment-and-Control campaign weaponized GitHub comments for credential theft across Claude Code, Gemini CLI and Copilot. See the fake-installer, Amazon Q wiper, and Comment-and-Control advisories.

How do IDE agents on laptops differ from CLI agents in CI?

Same software family, different blast radius. An IDE agent on a laptop runs with a developer's interactive trust and often an auto-approve mode, but a relatively small token surface. A CLI agent in CI usually holds a privileged publish or cloud token and processes input an external contributor controls - branch names, PR titles, comments - which is why CI flaws in this cluster reached the highest severities. The Gemini CLI run-gemini-cli CI flaw was scored CVSS 10.0 (GHSA-wpqr-6v78-jr5g); see the run-gemini-cli RCE advisory.

• Laptop / IDE agents - interactive approval and auto-approve modes are the weak point; govern file writes outside the workspace and unexpected outbound calls, and inventory extensions and skills, not just the core agent.
• CI / CLI agents - privileged tokens plus attacker-controllable input are the weak point; treat branch names, PR titles and comments as untrusted, and never let an agent's tool call reach a publish token without a decision at the hook.
• Both - run the same inventory-then-govern model; the difference is which tool calls you deny and what a leaked credential can reach, captured in the 90-day audit trail.

How do I choose and roll out controls without blocking developers?

The instinct to ban these tools backfires. A blanket block pushes usage to personal accounts and sideloaded binaries - exactly the conditions the fake-installer campaign exploited - and at 84% adoption you are not blocking a fringe behavior, you are blinding yourself to a mainstream one. The better posture is to sanction specific tools, inventory every install (sanctioned or not), and govern behavior at the tool call. Anomity collects metadata only and redacts secrets on the endpoint, so visibility does not mean reading developers' code.

Use a simple selection matrix. Score any candidate control against whether it can enumerate the artifact layer, decide before a tool call runs, keep a queryable record, and do so without changing the developer's workflow. Controls that only react after the fact - alerting on an exfiltration already in flight - fail the first test that matters.

For the framework to slot this into a broader program, the AI security framework report and the agentic AI governance guide map these controls to policy and ownership, and the docs cover deployment specifics.

Where do the secrets and tokens actually leak?

Follow the credential and the leak path becomes obvious. Coding agents sit next to the most valuable secrets a developer holds - the agent's own API key, environment variables, cloud credentials, and in CI a publish token - and every exfiltration in this cluster moved one of them through a channel the agent was already allowed to use. Gemini CLI read environment variables with env and shipped them with curl; the Claude Code GitHub Action leaked secrets through a permission bypass; Codex stole a GitHub token via a poisoned branch name. The pattern is consistent: the secret never has to be stolen from a vault when the agent will read it from the environment and send it through an approved tool call.

• The agent's own API key - a project-file injection that turns the agent against itself can exfiltrate it, as the Claude Code project-file finding showed.
• Environment variables - the default loot, because they are readable by any process the agent spawns; redact them on the endpoint so a captured context carries no credentials.
• CI publish and cloud tokens - the highest-value target, reachable when an agent's tool call in a pipeline is not gated; this is what produced the unauthorized [email protected] release.
• MCP server credentials - trusted transitively, and swappable, as MCPoison demonstrated.

The control that holds across all four is the same: collect metadata only, redact secrets on the endpoint before anything leaves, and decide allow/deny/log on the tool call that would carry a credential out. That is the runtime governance boundary, and it is why a leaked token does not have to become a leaked release.

What edge cases trip teams up?

• No-CVE findings. Tracebit's Gemini CLI bug and the Comment-and-Control campaign shipped without a CVE, so CVE-keyed scanners miss them. Find vulnerable builds by the version installed, not by an advisory feed.
• Two CVE years in one finding. The Claude Code project-file issue spans CVE-2025-59536 and CVE-2026-21852 - a single exposure can carry multiple identifiers across reservation years; do not assume one CVE closes it.
• Trust that survives a restart. MCPoison persisted because the agent re-trusted a swapped config. Persistence means a one-time scan is not enough; you need continuous inventory.
• The installer is the malware. SEO-poisoned fake Gemini CLI and Claude Code installers mean a clean checksum of the wrong binary is worthless - provenance and source matter as much as version.
• Auto-approve as a default. Copilot's YOLO-mode RCE shows that a convenience mode can be the whole vulnerability; inventory which agents have auto-approve enabled, not just which are installed.

What should I do in the next 30 days?

Sequence the work so each step earns the next. The order matters: governance and audit are only as good as the inventory underneath them, and the no-CVE findings in this cluster mean you cannot lean on a scanner to tell you what you have.

1. Inventory the artifact layer. Enumerate every AI agent, CLI, extension, MCP server and hook across developer endpoints and CI runners - by installed version and provenance, using Anomity's fleet visibility, not an advisory feed.
2. Flag the known-bad versions. Cross-reference the inventory against this cluster: Gemini CLI before 0.1.14, [email protected], and the fixed builds for Cursor, Copilot and Claude Code. Confirm none are fake-installer binaries.
3. Turn on decisions at the hook. On agents that expose a hook, enable allow/deny/log starting in log-only mode to baseline, then deny the high-risk classes: chained shell commands, writes outside the workspace, and tool calls that touch publish tokens.
4. Audit the auto-approve modes. Find every agent with auto-approve enabled - the Copilot YOLO-mode RCE shows this is often the whole vulnerability - and require a decision instead.
5. Wire the trail to your SIEM. Route the 90-day audit trail to SIEM, Slack, email or Jira so the next disclosure is a query, not a fire drill, and map the program to the agentic AI governance guide.

How Anomity governs ai agent & cli security

Concretely, three steps on the endpoint where the agent runs - no agent rewrite, no developer workflow change.

One: inventory. Anomity enumerates the eight AI artifact types on every managed endpoint and CI runner - AI agents, MCP servers, extensions, skills, plugins, secrets, hooks and CLIs - and classifies them. That is how you answer "which endpoints run Gemini CLI before 0.1.14?", "where is [email protected]?", "which agents have auto-approve on?", and "did anyone install a fake Claude Code binary?" - by installed version and provenance, not by an advisory feed that misses the no-CVE cases.

Two: decide at the hook. On agents that expose a hook - for example Claude Code's PreToolUse - Anomity evaluates each tool call against your policy and returns allow, deny or log before the call runs. A shell command that chains ; env and ; curl past an approved prefix is evaluated on the whole command; a write outside the workspace, an MCP config swap, or an outbound call to an unexpected host is denied at the boundary. This is the control that stops a leaked CI token from reaching a publish action and a project-file injection from spawning RCE - the runtime governance layer the post-hoc tools lack. Anomity collects metadata only and redacts secrets on the endpoint, so a captured context never carries credentials off the machine.

Three: keep the record. Every install, version change, artifact and decision lands in a queryable 90-day audit trail, routed to SIEM, Slack, email or Jira. When the next disclosure lands - CVE or not - you answer which endpoints ran the affected build, which repositories fed the agent untrusted input, and what those agents were allowed to do, from a record rather than a guess. Anomity is SOC 2 Type II and complements your Network, EDR, DLP and GRC tooling. See how it works and how it compares for where it fits.

You can't govern what you can't see.The Anomity principle

The decision framework is the same one you started with, now with a third option that is neither block nor blind trust: sanction the tools, inventory every agent and CLI across the fleet, and govern each tool call at the hook with a queryable record behind it. The thirteen advisories in this cluster show the same five patterns recurring across Amazon Q, Claude Code, Cline, Cursor, Gemini CLI, Copilot and Codex - a per-tool patch is necessary but never sufficient, because the next disclosure is a new instance of an old shape. Start with the inventory, because you cannot govern what you cannot see. To see Anomity inventory and govern the agent and CLI layer across your fleet, request early access.