A September 2026 study scanned 3,171 public repositories and found that 16% of AI coding agent setups carry a confirmed security defect. Almost none of them are exotic. The most instructive one is a single permission line that reads as narrow to every reviewer who has ever approved it.
Your engineering organization has a dependency review process. Somebody built it after an unfamiliar package turned up in a production build, and it works, mostly.
It does not cover the files that configure your coding agents.
CLAUDE.md, AGENTS.md, .mcp.json, copilot-instructions.md, a cursor rules directory, a skills folder. These get committed like any other source file, pulled by every engineer who clones the repository, and read by an agent that can run commands, edit files across the tree, and reach external services. They are dependency declarations and permission grants wearing the costume of documentation, and in most organizations, they receive the same review as documentation.
On September 7, 2026, researchers at Red Hat and Ben-Gurion University of the Negev published the first prevalence measurement of that surface. "Scanning the Harness" analyzed 3,171 public GitHub repositories, split into 2,660 setups that assemble two or more component types and 511 published skill collections. Previous work in this area demonstrated that the attack surface exists. This one counts how often it is actually misconfigured in code people are recommending to each other.
What Did the Scan Actually Find?
Defects at a rate that would trigger a review in any other dependency class. Across 2,660 agent setups, 16% carry a confirmed security defect, with a 95% confidence interval of 14.6 to 17.4. Three classes account for it: 9.8% install an MCP server with no version pinned, 3.8% carry a skill that pre-approves the shell for whoever installs it, and 3.1% pre-approve arbitrary execution behind a grant that only looks scoped.
None of those three is a novel attack. Each is a familiar supply chain failure that has simply arrived through a door nobody assigned an owner to. An unpinned dependency, an over-broad permission, and a distributed component that carries its own privileges along with it.
The skill finding has a second half worth sitting with. That same class ships inside 3.7% of published skill collections, meaning it is present in material that has been packaged for distribution, listed in a marketplace, and installed by people who did not write it. The paper has a line for this: recommendation is not review.
Why Does a Permission Like Bash(python:*) Pass Code Review?
Because it reads like a narrow grant and is not one.
This is the single most useful finding in the study and the one worth taking to your next architecture review. The paper is precise about it: 3.1% of setups pre-approve arbitrary command execution through a permissions entry that reads as narrowly scoped. The examples it gives are Bash(awk:*), Bash(python:*), Bash(find:*) and Bash(sed:*).
Look at any of those the way a reviewer looks at a pull request at four in the afternoon. It names one tool. It is not a wildcard. It appears to say "this agent may run Python," which sounds like a scoped capability in the same family as "this service may read from this bucket."
Python runs arbitrary code. So does awk. So does find, via its exec flag. So does sed on many systems. Each of those entries is functionally equivalent to granting unrestricted shell access, written in a syntax that actively conceals it. The reviewer was not careless. The interface told them something untrue, and they believed it.
That is why this belongs in a process conversation rather than a tooling one. No amount of care from an individual reviewer can fix a permission vocabulary that does not explain what its entries mean. The paper's own recommendation is that clients should render Bash(python:*) as "any command" in the interface, which is the correct fix and is not yours to make. What is yours is the review rule that follows from knowing it: treat every entry in a permissions allow list as unrestricted until someone can demonstrate the named tool cannot execute code.
The same reasoning extends to a setting the paper flags separately. A configuration option that bypasses permission prompts entirely was honored in project-scoped settings in one popular client until version 2.1.257, but is now ignored in that scope. The argument for the change is one every platform team will recognize: a project setting is written by one person and executed by everyone who clones the repository.
How Does an Unpinned MCP Server Become a Supply Chain Problem?
The same way an unpinned npm dependency does, with a shorter path to consequence.
In 9.8% of setups, an unpinned MCP server declaration is the most common defect the study found. A server declared without a version resolves to whatever the registry serves at the time the agent starts. Whoever controls that package controls a component your agent invokes with your credentials, inside your repository, with whatever tool permissions the surrounding configuration granted it.
Your existing controls do not see this. The server is not in your package manifest, it is not in your lockfile, and it did not pass the review that catches new production dependencies. It arrived in a Markdown file.
The two problems on this layer compound. Separate research into internet-facing MCP servers found the majority of audited servers running without authentication, and an unpinned declaration of such a server means you cannot say which version of the weak link you are running. The paper's recommendation is the obvious one, which is also the one nobody has implemented yet. Server declarations need the equivalent of a lockfile and, at minimum, a client that warns when an install command lacks a version.
What About the Scanner Output You Are Already Looking At?
Treat it as a starting point rather than a finding, because the gap between raw output and confirmed defects is large.
Running the study's rules across the corpus without validation produced a raw rate of 25.5% of setups. After each candidate was independently re-derived from the repository at its pinned commit and adjudicated, the confirmed rate across all six gating rules was 18.4%. Roughly a quarter of the raw signal did not pass the check.
The pattern holds across this whole category. A Fudan University study across 64,611 unique MCP servers found that scanners flagged 96.89% of them as risky, while fewer than half of the sampled alerts were true positives, with an average precision of 45.53%. The generalizable point is the same in both cases: a prevalence figure derived from unaudited detector output is a measurement of the detector.
The practical version for your team is to resist the urge to buy a scanner and call the problem handled. What actually reduces exposure here is a review rule and a check that runs at the pull request introducing a component, which is the paper's own recommendation and requires no procurement cycle.
What Should a Team Do About This on Monday?
Four things, in rough order of how much they buy you per hour spent.
Inventory what your repositories actually declare. Not what your approved tools list says. Grep the tree for agent configuration filenames and MCP server declarations, and read what they grant. Most teams find components they did not know were there, which is the same finding that made the integration layer worth auditing in the first place.
Add agent configuration to code review with a specific rule. Any change to a permissions allow list, a skill definition, or an MCP server declaration gets read as a privilege change, not a documentation change. The one question to ask is whether each granted tool can execute arbitrary code, and the default answer is yes. This is the same adjustment reviewers already made for testing software when agents write half of it, extended one file type further.
Pin your server declarations and keep them pinned. Until clients warn on this, it is a convention your team enforces, or it does not happen.
Run the checks where the component enters. The study released its instrument, which runs in seconds and emits SARIF, so it integrates with code scanning like any other dependency check. Configuration-level checks belong at the pull request that introduces a component, and frontmatter checks belong at publication time for anyone distributing a collection.
None of this is a large program. It is an afternoon of inventory and a review rule, sitting alongside the governance work most organizations have already started for agents in production. If you are building tailored AI agents rather than only consuming them, the same discipline applies to what you ship to your own customers.
How Much Should You Trust These Numbers?
Enough to act on, with three caveats the authors state themselves, and we would rather state than have you discover.
The figures are a lower bound. The paper is direct about it: the authors do not know what their six gating rules miss, and every headline figure is a lower bound on the defects the instrument can express.
The validation was done by language models rather than people. The adjudication of disagreements and the re-checking of counted pairs both ran on models with a released prompt, and the paper states plainly that no human scoring of the verdicts has been done. That is an unusual thing to disclose, and it deserves credit, but it means the confirmed rates carry model error.
The corpus is deliberately skewed, and the skew is the point. Repositories were discovered through topic queries, README references, thirty curated lists, and the plugin marketplaces of one major client and its community. The authors acknowledge that this over-represents repositories advertising their agent tooling, and then explain why that is the population they wanted: these are the configurations that get recommended and installed. Your private repositories are not described by this study. The configurations your engineers copied from a curated list are as follows:
One more scoping note. The consequences in the paper are stated against platform documentation current as of September 2026. Clients change what a field does. A rate measured against one version of a client means something slightly different against the next, which is an argument for re-running the check rather than filing the number.
Common Questions About AI Coding Agent Configuration Security
What is an AI coding agent configuration file?
It is a file in your repository that tells a coding agent what context to load, which external servers it may call, and which commands it may run without asking. Common names include CLAUDE.md, AGENTS.md, .mcp.json, and copilot-instructions.md, along with skill and rules directories. They function as dependency declarations and permission grants, not documentation.
Why is Bash(python:*) considered a security defect?
Because it grants unrestricted command execution while appearing to name a single narrow tool. Python can run arbitrary code, as can awk, find, and sed, all of which appeared in the study's examples. The September 2026 scan found this pattern in 3.1% of the 2,660 agent setups it analyzed. Treat every allow list entry as unrestricted until proven otherwise.
How common are security defects in agent configurations?
In the largest measurement to date, 16% of 2,660 public agent setups carried a confirmed security defect, with a 95% confidence interval of 14.6 to 17.4. The authors describe that as a lower bound and note that the corpus over-represents repositories that publish and recommend their agent tooling.
Do MCP server declarations need version pinning?
Yes, and 9.8% of the setups studied had none. An unpinned declaration resolves to whatever the registry serves at startup, which means the component your agent invokes with your credentials can change without any commit in your repository. Existing lockfile and dependency review controls do not cover these declarations, because they live in configuration files rather than package manifests.
Will a security scanner find these problems?
Partly, and with noise. The same study's rules produced a raw rate of 25.5%, which, after validation, was confirmed at 18.4% across all rules. Separate research on MCP scanners found that fewer than half of sampled alerts were true positives. Scanners are a useful input. The control that works is a review rule applied when a component enters the repository.
If your engineers are running coding agents, you already have this surface, whether anyone has looked at it or not. Talk to the Golabs team about auditing what your repositories currently grant and setting the review rule once, so the next twenty configuration changes are a checklist rather than a discovery.