AI coding agent security

What is AI coding agent security?

A coding agent is more than a chatbot that suggests code. It runs as a process on a developer machine or a CI runner, with the developer’s shell, filesystem, and tokens. In its 2026 Developer Ecosystem Survey, JetBrains found that 90% of professional developers use AI coding agents at work at least weekly, and 68% use them daily. That is an installed base of privileged automation, and it arrived faster than the controls around it.

Coding agent security is distinct from two neighboring disciplines, application security and model safety.

AppSec secures the result of software engineering: the code, the dependencies, the running application. Coding agent security secures the actor that produces these artifacts. Code review catches outputs, not actions, and by the time code written by an AI agent reaches review, the agent may already have read secrets, altered or deleted production data, rewritten configuration, and pulled in dependencies nobody chose. AppSec still applies to everything the agent writes, but it has no coverage of how the writing happened.

Model safety concerns what an LLM will say or refuse to say. Coding agent security concerns what the surrounding harness will execute after receiving instructions emitted by a model. In the Nx s1ngularity attack, malware ran installed AI CLIs with permission checks off and told them to find secrets. Claude sometimes refused. The credentials leaked anyway, because the malware’s own code stole the tokens. Refusal behavior is unreliable and is not a control boundary.

So the discipline comes down to constraining what an agent can execute, what it can reach, and what it can be told to do by content it did not write. It is the sharpest case of what the wider market calls AI agent security or agentic AI security, because coding agents get a shell and developer credentials by default.

The attack surface of a coding agent

The surface has four parts, and the harness connects the other three: it launches MCP servers, loads skills, and reads the configuration files that supply chain attacks plant. Each part still fails in its own way, and each often has a different owner.

The harness

The harness is everything around the model that makes it an agent: the loop, tool and shell executors, context and memory, approval gates, and the sandbox. Its controls are permission modes, trust prompts, deny rules, and hooks, all configured through settings files. It decides whether a generated command reaches bash -c, and it is where the most structural failures have been found.

Our GuardFall research found the boundary between agent and shell exploitable in 10 of 11 popular open source coding and computer use agents, in four different ways. The guards that fail inspect raw command text, and bash rewrites that text before running it. The filter sees r''m; bash removes the empty quotes and runs rm. Adding patterns to a denylist does nothing about that gap. Continue came closest to closing it.

Trust prompts and permission systems show the same shape: a control that looks present but stops enforcing. Our TrustFall research found four agentic CLIs running a repository’s self-approved MCP servers the moment a developer accepts the folder trust prompt, all defaulting to “Yes/Trust”. Our deny rules research found Claude Code silently dropping deny rule enforcement once a command chain passed 50 subcommands. A rule reading "deny": ["Bash(curl:*)"] held for a bare curl, but put 50 true && prefixes that do nothing in front of the same curl and the rule fell back to an approval prompt.

Further reading: What is an agent harness · TrustFall · GuardFall · Deny rules

MCP servers and tools

MCP is how an agent reaches systems beyond the repository, and every connected server is both a capability and an instruction source. The failures so far fall into three classes.

Some are architectural. In May 2025, Invariant Labs demonstrated a toxic agent flow against the official GitHub MCP server: a prompt injection planted in a public issue coerced an agent into pulling private repository content and publishing it through an automatically created pull request. Every component stayed within spec. The server relayed data, the agent acted on it, a single broadly scoped token spanned both trust zones, and nothing limited which repositories the agent could read.

Others come from how an approval is bound. MCPoison (CVE-2025-54136, patched in Cursor 1.3) worked because Cursor tied the approval to an MCP server entry’s name rather than the command it ran, so an approved entry could be swapped for a malicious one afterward.

The install path can fail too. Our DeepJack research bypasses Cursor’s fix for CVE-2025-54133: a crafted cursor:// deeplink pads the command with tabs so the payload scrolls out of the install dialog’s visible field, and the user approves a command they cannot see (observed on Windows).

Further reading: DeepJack · MCP security whitepaper · Top 25 MCP vulnerabilities

Skills and extensions

A skill is an instruction set the agent treats as authoritative, closer to a system prompt than to a library. Installing one grants a new author write access to the agent’s intent. The tooling meant to catch bad skills is not reliable yet: we ran eight open source AI skill scanners against real attacks, and a single malicious skill got past all eight, including the tool leading the Open Agent Security Benchmark (OASB) leaderboard at the time.

OWASP now maintains a dedicated Top 10 for this layer, a sign that skills are treated as a trust boundary and no longer as a packaging detail.

Further reading: Skill scanner bypass · OWASP Agentic Skills Top 10 · OpenClaw security 101

The software supply chain

In August 2025, the Nx s1ngularity compromise was one of the first documented cases of malware using AI CLI tools for reconnaissance. GitGuardian counted 2,349 distinct secrets pushed to 1,079 public repositories created in the victims’ own accounts.

In June 2026, the Miasma worm, which also hit npm and PyPI, used agent configuration as a trigger. A malicious commit to Azure/durabletask planted .claude/settings.json and .gemini/settings.json hooks that launch a credential harvesting payload when an agent session starts in the repository. Nobody had to run npm install, and no CVE was assigned, because the agents did what they were designed to do.

Our SymJack research shows the same boundary failing from inside an approved action. A file copy the user approves resolves through a symlink into the agent’s own configuration directory, so the next session starts an attacker’s MCP server. We confirmed it against six agents.

Further reading: SymJack

Real incidents and research

What has happened in the ecosystem

Date	Event	What it established
May 2025	GitHub MCP toxic agent flow (Invariant Labs)	Indirect prompt injection can cross from a public repository into private ones inside a single agent session.
Jun 2025	CVE-2025-52882, Claude Code IDE extensions	A local agent integration accepting unauthenticated WebSocket connections turns a visited webpage into file read access.
Jul 2025	Amazon Q Developer extension (CVE-2025-8217)	A CI token with too much access let an outsider commit a wiper prompt that shipped in a release of an extension with nearly a million installs. AWS says the payload failed to run.
Aug 2025	Nx s1ngularity	One of the first documented cases of malware using installed AI CLIs to find credentials.
Aug 2025	MCPoison (CVE-2025-54136) and CurXecute (CVE-2025-54135)	Approvals fail when they bind to a name instead of the command (MCPoison), or when a config write runs before the user can reject it (CurXecute).
Sep 2025	postmark-mcp backdoor	Described by Koi Security as the first malicious MCP server found in the wild. A single added line BCC’d every email sent through the server; 1,643 total downloads.
May 2026	CISA and Five Eyes agentic AI guidance	Five Eyes agencies told organizations to restrict agent privilege, start with low risk tasks, and design for reversibility and containment.
Jun 2026	Miasma worm	Agent configuration files alone can trigger execution, without any package install.
2025–2026	Nine AI coding agent incidents that ended with deleted data, over 14 months, from personal drives to a SaaS production database	None were attacks, and guardrails were on in at least three. In about half, the damage came one layer below the model’s intent: shell quoting, tilde expansion, exit code parsing, a dangerous database flag. In others, the agent chose the destructive step itself.

What we found ourselves

Our research program has concentrated on one question: does the layer between the model’s output and the operating system hold? Across a year of disclosures, it mostly does not.

Date	Research	Scope	What it established
Apr 2026	Deny rules bypass	Claude Code	A performance cap skipped deny rule analysis for commands over 50 subcommands, falling back to an ordinary approval prompt.
May 2026	TrustFall	Claude Code, Gemini CLI, Cursor CLI, Copilot CLI	All four run project defined MCP servers immediately after the folder trust prompt, and all default to trust. In Claude Code’s GitHub Action, the prompt never renders. Zero CVEs; Anthropic declined the report as outside its threat model.
May 2026	SymJack	Claude Code, Gemini CLI / Antigravity CLI, Cursor, Copilot, Codex, Grok Build	In all six, an approved file copy is redirected through a symlink into the agent’s configuration directory, installing an attacker’s MCP server for the next session.
Jun 2026	GuardFall	11 open source coding and computer use agents	Ten left the shell boundary exploitable through quoting, $IFS expansion, command substitution, encoded pipelines, or destructive flags, once commands ran without approval or outside the sandbox.
Jul 2026	DeepJack	Cursor, observed on Windows	A crafted cursor:// deeplink reaches the MCP install dialog with the command scrolled out of view, bypassing the fix for CVE-2025-54133.
Jul 2026	Skill scanner bypass	Eight open source skill scanners	None caught the same malicious skill, including the scanner then ranked first on OASB, whose leaderboard has since been withdrawn.

Across all of it, the defense between the model’s emitted command and the shell is structurally underbuilt, and each vendor patch has been scoped to the specific setting in the report rather than to the convention underneath it.

Wider stack: the 2025 AI security incidents report collects the year’s cases across the whole AI estate, not only coding.

Coding agent risk assessment

A coding agent risk assessment is an inventory plus a blast radius calculation. Most teams can complete a first pass in a week, and most first passes surface the same three findings: nobody owns the agent configuration, tokens are broader than the task, and CI has more autonomy than the workstation.

Work through five questions, using the risk categories the Five Eyes agencies set out in Careful adoption of agentic AI services: privilege, design and configuration, behavioral, structural, and accountability.

1. What is running? Agents, versions, MCP servers, skills, IDE extensions, and CI integrations, on workstations and runners. Shadow agents are the norm.
2. What can it reach? Repositories, cloud credentials, package registries, ticketing, production data. Assume every token in the environment is reachable by the agent process.
3. What can it execute without a human? Auto approve settings, bypass permission modes, headless CI paths, and hooks that fire on session start.
4. What untrusted content enters the context? Issue text, pull request descriptions, cloned repository files, tool results, retrieved documentation. This is the injection surface.
5. What is the record? If an agent took a destructive or exfiltrating action last Tuesday, can you reconstruct the command from your telemetry today? The failure we keep seeing in incident reports is a log of the output with no record of the command.

Deeper walkthrough: Agentic AI security: key threats, attacks, and defenses. Full guide: Careful adoption of agentic AI services. AI agent observability and policy enforcement: Adversa AI platform. Standards references: the mapping below.

AI coding security audit and governance

An AI coding security audit is the assurance layer on top of that assessment: documented scope, named owner, evidence, and a review cadence. Whether it holds up depends on ownership, change gates, and evidence.

Ownership is the first gap, because coding agents fall between AppSec, platform engineering, and IT. The agent configuration files live in the repository, which makes them a code review problem, and the tokens live in CI, which makes them a platform problem. Name one owner for the policy and one reviewer for configuration changes.

Gate the four changes that create most new attack surface: adding a tool or MCP server, changing an agent instruction file, expanding permissions, and upgrading the agent. Agents update themselves, and a minor version can change default permissions, add a hook type, or alter trust prompt behavior, which makes upgrades the likeliest source of silent control regression. A 2026 CSA blog post on MAESTRO in CI/CD pipelines makes the same argument, that the threat model should be a property of the codebase, regenerated on change, rather than a document written once.

Auditors and enterprise buyers increasingly ask for evidence: agent inventory, permission baselines, injection testing results, and a decommissioning process. Have those artifacts ready before the questionnaire arrives. When you assess vendors, review compliance and agent defense separately. In the AIRQ data, vendor certifications show near zero correlation with the agent’s own technical defenses.

Compliance mapping: EU AI Act. Standards references: the mapping below.

Coding agent runtime security and detection

Testing before deployment cannot anticipate inputs that change every session. A repository cloned yesterday is clean; the issue filed against it this morning is not, which is why coverage has to continue at runtime.

The term settling around this work is AI detection and response, or AIDR: runtime detection and response for threats that target AI systems or originate from them, such as a hijacked or misbehaving agent. For coding agents the telemetry that matters is narrow, and existing tooling mostly lacks it:

• Commands the agent executed, resolved the way the shell interprets them rather than the way the model emitted them. GuardFall shows that those two strings differ.
• Tool and MCP calls: which server, which arguments, and which results reentered the context.
• Credential access and outbound network destinations from agent processes.
• Configuration changes: settings files, hooks, new MCP entries, permission mode shifts, agent version upgrades. Treat a write to any of those the way you would treat a new scheduled task.
• Sequences of events. A retrieval that pulls in disguised instructions looks harmless on its own, and a tool call to an unusual destination looks routine. The signal is the chain.

EDR sees the process and its connections, and the SIEM sees the logs, but neither sees the instruction behind them.

See also: AI detection and response · the platform

Secure SDLC with AI coding assistants

There are two problems here, and teams routinely solve only the first.

The first is the code the agent writes. Veracode’s 2025 GenAI Code Security Report tested more than 100 models across 80 coding tasks and found 45% of generated samples introduced OWASP Top 10 vulnerabilities, with cross-site scripting failing in 86% of relevant samples. A later retest of newer flagship models found the pass rate essentially unchanged, so more capable models do not write safer code on their own. Treat agent output as untrusted input to your existing pipeline: scan it, review it, and tag it so you can measure it separately.

The second is the pipeline the agent runs in, and that is the one left unsolved. CI is where agents get the least supervision and the most credentials. In Claude Code’s headless mode, there is no trust dialog, yet project hooks and MCP servers still load with the runner’s environment, including whatever tokens the workflow holds. Miasma then demonstrated the same idea through configuration files that fire when an agent session starts.

Minimum viable controls, in order of return:

1. Run agents inside an OS level sandbox by default, with network egress restricted to an allowlist.
2. Scope credentials to the task, not to the developer. The agent should hold its own identity, and no production database URL should be reachable from a development session. Scope data the same way: classify repositories and restrict which ones the agent may load into context.
3. Disable project scoped hooks and MCP autoload through enterprise managed policy, so a cloned repository cannot approve itself. Code review is the second layer: treat agent configuration files as protected paths, and give hooks, MCP server entries, and broad allow rules the same review as a change to a CI workflow.
4. Do not run agents headlessly on runners that handle untrusted pull requests. This removes the zero click CI path TrustFall demonstrated.
5. Give irreversible actions their own control path. Approval fatigue comes from prompting on everything; prompting on the small share of commands that cannot be undone is survivable.
6. Install skills, MCP servers, and extensions only from a curated internal registry with an allowlist, and pin versions. Scan what enters the registry, but do not treat a clean scanner result as proof.

For harness level controls, including the Rule of Two and allowlisting, see how to secure an agent harness.

Standards mapping

Coding agent security now has published reference points. Map your controls to them once and reuse the mapping in audits, questionnaires, and procurement.

Agent surface	Primary reference	What it covers
Injected instructions in repository or tool content	OWASP ASI01 Agent goal hijack; LLM01 prompt injection	Malicious input redirecting agent objectives
Shell and code execution from the harness	OWASP ASI05 Unexpected code execution	Unexpected or attacker driven code execution, up to host compromise
Approval prompts and trust dialogs	OWASP ASI09 Human-agent trust exploitation	Users approving actions they cannot see
MCP servers, skills, extensions	OWASP ASI04 Agentic supply chain vulnerabilities; ASI02 Tool misuse and exploitation	Poisoned or abused runtime components
Tokens and agent identity	OWASP ASI03 Identity and privilege abuse	Credentials letting an agent operate beyond intended scope
Settings, memory, and context files	OWASP ASI06 Memory and context poisoning	Poisoned memory, summaries, or retrieved context steering later behavior
Skill and instruction files	OWASP Agentic Skills Top 10	Prose files the agent loads and acts on
Threat modeling method	CSA MAESTRO	Seven layer threat modeling built for agentic systems
Adversary techniques for detection and testing	MITRE ATLAS	AI specific attack tactics and techniques, such as LLM prompt injection (AML.T0051)
Control baselines for deployers	NIST SP 800-53; NIST IR 8596 Cyber AI Profile (draft); NIST COSAiS overlays when published	Established security controls, with an AI specific profile and overlays on top
AI management system	ISO/IEC 42001	Certifiable AI governance process: evidence of how AI risk is managed, not proof that an agent defense holds
Enterprise adoption posture	CISA and Five Eyes, Careful adoption of agentic AI services	Privilege, design and configuration, behavioral, structural, and accountability risk

The OWASP Top 10 for Agentic Applications, released in December 2025 alongside Black Hat Europe, is the closest thing the category has to a shared vocabulary. Its mitigation guidance is generic, and the mapping above ties it to your controls. Our guides to ASI05, ASI02, and ASI03 go deeper on the three closest to coding agents.