Snyk’s Agentic Development Data Turns AI Coding Into a Supply-Chain Problem

Snyk’s scan of nearly 10,000 developer environments makes a simple point: AI coding assistants are no longer just editor features. They are becoming a new layer of the software supply chain.

In a fresh agentic development security analysis, Snyk says it found measurable exposure across AI coding tools, Model Context Protocol servers, and agent skills. The headline is not that AI-generated code may contain bugs. The larger issue is that security teams now need to understand which systems, tools, instructions, and permissions helped produce the code before it ever reaches a pull request.

That shift matters for platform teams, AppSec leaders, and engineering managers rolling out AI coding agents. If an agent can read local files, query an issue tracker, call a browser automation tool, open a pull request, or follow an instruction bundle, the development environment has become an input to the build process. Treating that environment as personal productivity tooling leaves a blind spot exactly where agentic systems gain power.

Developer machines are becoming part of the build surface

Snyk’s data describes tool sprawl that is already operational, not theoretical. The company says 43% of developers in its scan were running two or more AI coding environments, while 37% were running three or more. It also says 50.8% of developers had at least one MCP server installed and 22.8% had at least one agent skill installed.

The risk is not one approved assistant

Those numbers change the governance problem. A team may approve one coding assistant, but an individual developer can still accumulate extensions, local MCP servers, skills, prompts, and integrations around it. Each one can have its own update path, trust boundary, and access model. In Snyk’s framing, the question for AppSec expands from “is this code vulnerable?” to “what connected tools and instructions shaped this code?”

The prompt-injection finding is especially relevant. Snyk says it found 392 confirmed prompt injection findings in tool descriptions. That is not the same as a vulnerable library imported into an application. It is a risk in the layer that tells agents what tools exist, how those tools behave, and what the agent may do next.

MCP changes what security teams have to inventory

The Model Context Protocol is useful because it standardizes how agents connect to tools and data. It is risky for the same reason. The MCP Security Best Practices document calls out attack classes such as confused-deputy authorization flows, token passthrough, server-side request forgery, session hijacking, local MCP server compromise, and scope-minimization failures.

A small example: docs access versus deployment access

An MCP server that gives an assistant read-only access to internal documentation is not equivalent to one that can manipulate tickets, cloud resources, or repository settings. Both may appear to the user as “context.” Only one is also a control plane.

Low-friction does not mean low-risk

The easy mistake is to review MCP servers as convenience plugins. A better review treats them as access paths. Security teams should ask which identities they use, which scopes they request, whether approval is per client, whether sensitive outputs can be exfiltrated through tool calls, and whether logs preserve enough evidence to reconstruct an agent-assisted change.

Why old supply-chain controls miss part of the story

Traditional software supply-chain programs often start with repositories, dependencies, build systems, packages, containers, and release provenance. That is still necessary. The SLSA overview describes supply-chain security as a way to improve trust from source to binary and protect against tampering across source, build, packaging, and distribution.

Agentic development does not make those controls obsolete. It moves part of the risk earlier. If a local agent reads a poisoned instruction file, chooses an unsafe tool, or uses an overbroad credential before code enters the repository, a later build-provenance check may prove only that the wrong change was built faithfully.

That means AI coding governance needs two ledgers: the classic artifact ledger that tracks source, build, and package integrity; and an agent-environment ledger that tracks which assistants, MCP servers, skills, prompts, credentials, and network paths were allowed to influence development.

OWASP already names several failure modes

The OWASP Top 10 for Large Language Model Applications is useful here because it separates several risks that tend to blur together in agent discussions. It lists prompt injection, supply-chain vulnerabilities, insecure plugin design, and excessive agency among the LLM application failure modes.

Those categories map cleanly to the Snyk findings. Prompt injection can live in tool descriptions and instructions. Supply-chain risk can include third-party MCP servers, skills, and agent dependencies. Insecure plugin design matters when an integration exposes powerful actions without tight access control. Excessive agency appears when an assistant receives broad autonomy to act without approval gates.

What teams should measure before approving agentic development

The useful response is not to ban all agentic coding. It is to make the development environment observable enough that approvals, incidents, and release reviews are based on evidence.

• Inventory the agent stack: approved assistants, local and remote MCP servers, skills, extensions, hooks, and custom instruction locations.
• Classify tool permissions: read-only context, write access to repositories, issue-tracker actions, browser automation, secrets access, cloud control-plane actions, and deployment capabilities should not share one approval bucket.
• Require scope minimization: each connector should justify the smallest identity, token scope, network path, and data set needed for its task.
• Log agent influence: record which agent, model context, MCP servers, and skills were active for changes that reach review.
• Gate risky actions: production credentials, destructive operations, dependency changes, CI configuration edits, and generated security fixes should require human review before merge or execution.

These controls are practical because they mirror existing AppSec behavior. Teams already inventory dependencies, protect CI secrets, and review deployment permissions. Agentic development asks them to apply the same discipline to the tools that now help create code.

The takeaway for engineering leaders

Snyk’s report is a warning against treating AI coding as a purely personal productivity layer. Once agents can connect to external tools, retrieve context, and act through integrations, they become part of engineering infrastructure.

The organizations that benefit safely will be the ones that define agentic development as a managed environment: visible, scoped, logged, and reviewed. The ones that do not will discover that their software supply chain now starts on a developer workstation they never inventoried.