Your Developer's Laptop Is Now the Supply Chain: What Snyk Found in 10,000 Agentic Dev Environments

AppSec teams have spent a decade learning to scan repositories, lock down pipelines, and audit dependencies. Now the attack surface has quietly moved upstream — into the developer’s own machine, into the AI tools they installed last weekend, and into instruction files nobody’s ever code-reviewed. Snyk just scanned nearly 10,000 developer environments and the picture is uncomfortable: the software supply chain now starts before a single line of code is committed, and most security programs are blind to it.

The Developer Environment Is the New Attack Surface

According to Snyk’s research across nearly 10,000 developer environments, 43% of developers run two or more AI coding environments simultaneously — Claude, Cursor, Windsurf, Gemini, Copilot, Kiro, VS Code extensions, and more. Each of those environments carries its own configurations, integrations, and permissions. That’s not a rounding error; it’s a governance crisis dressed up as productivity.

Why it matters: traditional AppSec assumes a chokepoint. Code enters a repo, hits CI, gets scanned, ships. Agentic tooling breaks that mental model because risk now materializes on the laptop, before the commit. If your security team can’t answer “which AI environments are installed and what are they connected to?” then SAST and SCA are guarding a door that’s no longer the entrance.

Imagine you’re the AppSec lead at a 500-engineer fintech. Half your team uses Cursor with a personal Anthropic key, a quarter runs Copilot through the enterprise contract, and a growing faction has quietly installed Windsurf because they like the agent mode. Each tool talks to different MCP servers, each carries different permissions, and none of it shows up in your asset inventory.

Our take: within 18 months, “AI tooling inventory” will be a required control in SOC 2 and ISO 27001 audits, and companies that don’t have one will fail their first assessment cycle.

Why MCP Servers Are the Supply Chain Layer Nobody Inventoried

Snyk found that 50.8% of developers already have at least one Model Context Protocol server installed, and 1 in 7 developers with MCP servers had at least one security finding. Snyk also identified 392 confirmed prompt injection findings embedded in tool descriptions inside environments that were live at the time of the scan.

Why it matters: MCP servers aren’t dependencies in the traditional sense — they’re access-layer components that determine what an agent can reach and what it’s allowed to do. They get installed locally, configured outside centralized review, and often granted access to code repositories, browser automation, and internal documentation before any security gate runs. A poisoned tool description is essentially a rootkit for the agent’s decision-making. The agent reads the malicious instruction, treats it as legitimate context, and acts on it.

If your team ships supply chain and logistics software where auditability is the product, an MCP server on a developer laptop that can silently exfiltrate customer shipment data is a compliance incident waiting for a court date. That risk is sharper for regulated verticals like healthcare software where a compromised agent context could touch PHI on the way to generating code.

Our take: MCP servers will get their own SBOM-equivalent standard within a year, and the vendors who move first will define the format everyone else has to comply with.

Agent Skills Are Instructions That Behave Like Code

Snyk’s data shows 22.8% of developers had at least one skill installed, and a separate Snyk study of the public skills ecosystem — ToxicSkills — analyzed 3,984 skills from ClawHub and skills.sh. The results: 13.4% contained at least one critical-level security issue and 36.82% had at least one security flaw. Human review confirmed payloads engineered for credential theft, backdoor installation, and data exfiltration.

Why it matters: skills are instruction files, not executables, which is exactly what makes them dangerous. They slip past traditional dependency scanners because they don’t declare themselves as packages. They shape agent personas, workflows, and defaults — meaning a malicious skill doesn’t need to run code to cause harm. It just needs to convince the agent to run code on its behalf, or to leak a secret while “helping” the developer. Snyk also flagged 98 confirmed malicious code patterns in agent skill files across active environments.

For teams building custom AI agents for internal use, treat every skill file the same way you’d treat a signed npm package: provenance, review, allow-list, and revocation path. Pulling a “cool workflow skill” off a public marketplace should require the same friction as installing a Chrome extension with access to all sites.

Our take: the first major breach attributed to a malicious agent skill will happen before the end of 2026, and it will be a credential theft incident traced back to a marketplace download.

What Traditional AppSec Actually Has to Do Now

SAST, SCA, IaC scanning, container security, and pipeline controls aren’t obsolete — Snyk is clear they remain essential. They’re just no longer sufficient. Agentic development introduces risk before code exists, which means security has to move earlier in the workflow than most teams have ever operated.

Why it matters: this changes budgeting, staffing, and tooling procurement. Snyk’s recommended actions include inventorying AI coding environments, MCP servers, and skills; treating agent configuration as supply chain; extending policy to cover MCP and skills; putting guardrails inside the agent execution loop; and connecting agentic security back to existing AppSec programs rather than spinning up a parallel silo. The teams that get this right will look a lot like the ones who nailed cloud posture management in 2018 — early movers who built visibility first and enforcement second.

Practical scenario: if you’re a platform engineering team, this means your golden-path developer image should ship with an approved MCP server allow-list, a signed skill registry, and telemetry that reports what agents are actually being used. It should feel less like DLP and more like a package registry with policy hooks.

Our take: Agentic Development Security (ADS) will be a distinct Gartner category by 2027, and the winners will be whichever vendors integrate cleanly with existing AppSec platforms rather than trying to replace them.

FAQ

Q: What is an MCP server and why is it a security risk? A: Model Context Protocol servers give AI coding agents a way to connect to external tools and data sources — repositories, browser automation, docs, local files, issue trackers. They’re a security risk because they’re often installed locally, configured outside centralized review, and can grant agents access to sensitive systems before any code hits a repo or CI pipeline. Snyk found 1 in 7 developers with MCP servers had at least one security finding.

Q: What are agent skills and how are they different from dependencies? A: Skills are instruction files that shape an agent’s behavior, personas, workflows, and reusable capabilities. Unlike traditional dependencies, they don’t declare themselves as packages, which means dependency scanners often miss them entirely. Snyk’s ToxicSkills research found that 36.82% of 3,984 analyzed public skills had at least one security flaw, including payloads for credential theft and data exfiltration.

Q: Does this mean SAST and SCA are dead? A: No. Snyk is explicit that SAST, SCA, IaC scanning, container security, and pipeline controls remain essential. What’s changed is that they’re no longer sufficient on their own. Security programs now need to extend visibility and policy to the AI tools, MCP servers, skills, and configurations that shape code before it’s ever committed.

Key Takeaways

• Build an AI tooling inventory this quarter — if you can’t name every AI coding environment, MCP server, and skill running on developer laptops, your AppSec posture has an unmeasured blast radius.
• Treat MCP servers and skills as first-class supply chain components with allow-lists, provenance requirements, and revocation paths, not as personal developer utilities.
• Push guardrails into the agent execution loop, not just into CI — by the time a malicious skill’s payload reaches your pipeline, it may have already exfiltrated a token.
• Expect regulators and auditors to catch up fast; agentic tooling inventory will become a compliance line item, not a nice-to-have.
• Fold agentic development security into your existing AppSec program rather than standing up a parallel team — the organizations that create a governance silo here will end up with two half-blind programs instead of one coherent program.