Hey everyone, picture a team that pins every npm package, rotates every API key, and still treats the coding-agent folder like a junk drawer. Skills drop in from a marketplace. MCP servers land as unpinned package names. Permission grants look scoped until you notice a pattern that quietly opens a shell. That folder is not a preference pane. It is an agent harness supply chain, and it runs with the privileges of whoever starts the agent on the laptop.
Say you are rolling out Claude Code, Cursor, Copilot, or Codex on a product squad. The model gets the attention in the bake-off. The harness gets the silent install: instruction files, skills, hooks, MCP declarations, and subagents that someone copied from a public repo. Kapner and coauthors call that assembled layer what it is: a dependency surface without a lockfile, without an install-time check, and without a shared vocabulary for what a component may do (arXiv:2609.07360).
The model is not the only dependency you installed
When you add a library, you expect a version pin, a hash story, and a review habit. When you add an agent skill or an MCP declaration, many teams still accept “it worked on my laptop” as the security review. Imagine a platform engineer who would never merge an unpinned production dependency, then pastes an MCP package name with no version into the agent config because the demo README looked friendly. That gap is the whole post.
The Kapner study scanned 3,171 public GitHub repositories and split them into 2,660 setups that assemble two or more harness component types, plus 511 published skill collections. That split matters for your week. An assembled setup is what your repo actually runs. A collection is what a marketplace or public skill pack ships for other people to install. Defect classes do not land evenly across those two surfaces.
What “scanning the harness” actually found
The researchers measured only rules decidable from bytes, then validated findings before counting them. A second implementation re-derived 8,547 findings from repositories at pinned commits. Headline rates use a small set of gating rules rather than every observation the scanners can print. That discipline is why the paper earns trust with practitioners who already distrust raw scanner dashboards.
On confirmed security defects, 16.0% of setups carried at least one (95% CI 14.6 to 17.4). Any confirmed defect under the security-plus-quality gating set sat at 16.7%. When you include the broader confirmed finding set that also covers the specification family, rates rise to 18.4% of setups and 6.8% of collections. The raw gate before that audit landed at 25.5% of setups on the same rules. The gap is the lesson: unaudited scanners inflate, and leadership will make bad policy if you only show the inflated number.
One negative result deserves equal airtime. The corpus did not yield a confirmed credential-to-network exfiltration path under the study’s rules. That is not a free pass for your private repos. It is a reminder that the ordinary defects already found are enough to justify hygiene without inventing a Hollywood breach narrative.
Three ordinary defects that skip the scary headlines
Three security classes survived confirmation on setups, and they look boring in the best possible way.
Unpinned MCP packages showed up in 9.8% of setups and 0.0% of collections. Picture a team that would never leave express floating in package.json, yet leaves an MCP server as a floating package install because the agent UI made it feel like a plugin toggle.
Arbitrary-execution grants such as a scoped-looking Bash(python:*) pattern appeared in 3.1% of setups. The grant reads narrow until you remember that “run Python” is a wide door when the agent can choose the script.
Skills that pre-approve shell access landed in 3.8% of setups and 3.7% of collections. That last number is the marketplace-facing cousin: the dangerous permission can ship inside the skill pack before your repo ever assembles the rest of the harness.
None of those defects need a novel exploit story to matter. They are configuration debt that borrows the same privileges your developers already have.
Setups and collections fail in different places
If your security review only scans published skill collections, you will miss the unpinned MCP problem that shows up in assembled setups. If you only audit the monorepo that your team uses daily, you can still inherit shell pre-approvals from a collection someone installed last Thursday. Kapner’s split is operational advice dressed as empirics: treat setup review and collection review as separate checklists with different expected findings.
The open instrument for that work is harness-eval (github.com/redhat-community-ai-tools/harness-eval). You do not need to reinvent a scanner from a blog post. You need a habit that treats harness config like production dependency hygiene, then records confirmed findings instead of raw noise.
Marketplace skills raise the stakes for install-time review
Liu and coauthors widen the lens from harness assembly to marketplace skill packages themselves (arXiv:2601.10338). Across 31,132 analyzed skills, 26.1% contained at least one vulnerability pattern. Data exfiltration patterns showed up in 13.3% of skills, privilege escalation in 11.8%, and high-severity patterns in 5.2%. Skills that bundle executable scripts were 2.12 times more likely to be vulnerable than instruction-only skills (OR=2.12, p<0.001).
Say your squad installs a “helpful” skill because it automates ticket triage. If that skill ships scripts, your install-time review should get heavier, not lighter. Marketplace prevalence does not prove your specific skill is malicious. It does prove that install-time trust is a weak control when more than one in four analyzed skills carries a vulnerability pattern.
Put the two papers on the same whiteboard without blending their claims. Kapner tells you which ordinary harness defects appear when agents are configured in public repos, and where those defects concentrate across setups versus collections. Liu tells you that the skill packages feeding those harnesses already carry a high base rate of vulnerability patterns at marketplace scale. Together they argue for review at assembly time and at install time.
A practical audit checklist for your next agent rollout
You can start this week without waiting for a new platform mandate.
- Inventory the harness the way you inventory services: instruction files, skills, hooks, MCP declarations, permission grants, and subagents, with owners and last-reviewed dates.
- Pin MCP packages and record expected versions the same way you pin application dependencies.
- Read every shell or interpreter grant as if it were IAM. Reject “scoped looking” patterns that still authorize arbitrary execution.
- Separate setup audits from collection audits, because unpinned MCP and shell pre-approval do not travel in the same packaging stage.
- For marketplace skills, prefer instruction-only packs when you can, and require extra review for skills that ship scripts, given the 2.12× odds ratio in Liu et al.
- Run a confirmed-finding workflow, not a raw-hit dashboard. Kapner’s raw-to-confirmed drop from 25.5% to the mid-teens is a warning label for anyone buying policy off a first-pass scanner.
- Keep the negative result in your brief: do not invent credential-exfiltration theater when the confirmed defects already justify pinning, least privilege, and install review.
Imagine a team demoing an agent that can open pull requests by Friday. Slip a thirty-minute harness review into the same milestone: pins, grants, skill script presence, and a one-page owner list. That is cheaper than explaining later why the “safe” agent config was the soft underbelly of your software supply chain.
Close: treat harness config like production dependency hygiene
Coding agents are tools. Tools inherit whatever dependency culture surrounds them. If your culture pins application packages and shrugs at agent skills, you have already decided that the agent’s privileges are less serious than your web framework’s. The September 2026 harness scan says roughly one in six public setups carries a confirmed security defect under careful validation, while marketplace skill research finds vulnerability patterns in about one in four analyzed skills. Ordinary configuration defects are doing plenty of work without a cinematic breach plot.
Keep shipping useful work with coding agents. Keep treating the model as a component inside a larger system. Just stop pretending the harness is decoration. Your agent harness supply chain deserves the same boring hygiene you already give npm: pins, reviews, least privilege, and separate checks for what you assemble versus what you install from a catalog.
If this article helped, drop a comment with the first workflow you want to try this week. Support the shenanigans buying me a coffee on Ko-fi, and follow Attune IT on YouTube or me on X.