What nearly 10,000 developer environments reveal about agentic development risk

Key findings

• AI coding tool sprawl is common: 43% of developers run two or more AI coding environments.

• MCP adoption is already widespread: 50.8% of developers have at least one MCP server installed.

• MCP risk is showing up now: 1 in 7 developers with MCP servers had at least one security finding.

• Agent skills add another risk layer: 22.8% of developers had at least one skill installed.

• Prompt injection is present in active tooling: Snyk found 392 confirmed prompt injection findings in tool descriptions.

For years, application security teams have focused on a familiar set of questions: Is the code secure? Are the dependencies vulnerable? Is the build pipeline protected? Are issues being caught before they reach production?

Agentic development adds a new question: What systems, tools, instructions, and permissions helped produce this code?

AI coding agents are no longer just suggesting snippets or completing lines of code. They are increasingly connected to MCP servers, skills, integrations, and other parts of the software development environment. They can retrieve context, call external services, execute actions, and generate code in ways that existing security processes were not designed to see or govern.

That means the developer environment is becoming part of the software supply chain teams need to understand and govern it. And according to new Snyk Research, this shift is already visible across real developer environments.

Snyk analyzed nearly 10,000 developer environments and ADS early adopter environments, and found measurable exposure across AI coding tools, MCP servers, and agent skills. The data suggests a shift that AppSec teams can no longer treat as theoretical: agentic development is creating a new software supply chain layer, and most security programs were not designed to see or govern it.

AI coding tools are becoming connected development environments

AI coding tools are now part of the everyday development workflow, but in many organizations, adoption is not limited to one approved tool or one standardized environment. Developers may use multiple AI coding environments simultaneously, including Claude, Cursor, Windsurf, Gemini, Copilot, Kiro, and VS Code extensions. Each tool may have its own configuration, integrations, context sources, and permissions. For AppSec teams, that creates a visibility challenge.

AI tool sprawl becomes a security concern when each environment can connect to external systems, consume instructions, and influence how code is created. The more tools in use, the harder it becomes to answer basic governance questions:

• Which AI coding environments are installed?

• What are they connected to?

• What permissions do they have?

• What instructions are shaping their behavior?

• Are they operating inside or outside approved security controls?

In traditional AppSec, teams can often start with the repository, the build pipeline, or the deployed artifact. In agentic development, risk can emerge earlier, inside the developer environment, before code is ever committed.

MCP servers are becoming a new supply chain layer

MCP, or Model Context Protocol, gives AI agents a way to connect to external tools and data sources. In practice, that can include code repositories, browser automation, documentation, local files, issue trackers, design tools, and other services across the software development lifecycle. That makes MCP servers more than a convenience layer, helping define what agents are able to access and do.

These are active configurations that can allow agents to interact with external tools and services directly from developer machines.

In traditional software development, the supply chain is often understood in terms of packages, dependencies, containers, and artifacts. Those components can be scanned, inventoried, governed, and monitored through established processes.

But MCP servers operate differently and act as part of the access layer, determining what agents can see and do. They are often installed locally or configured outside centralized review. They may also give agents access to sensitive systems before any code reaches a repository, CI pipeline, or standard security gate. Risk signals are already appearing in agentic development environments.

In practice, this risk may not look like a vulnerable package imported into an application. Instead, it may look like an MCP server or agent configuration that influences what an agent does, which systems it can reach, or which instructions it follows.

For example, prompt injection risks can appear in places traditional scanning may not inspect. Snyk found 392 confirmed prompt injection findings embedded in tool descriptions, and 98 confirmed malicious code patterns in agent skill files — in environments that were already active at the time of the scan.

Tool configurations can create unexpected access paths, agent behavior can be shaped by instructions that live outside code repositories, and in high-autonomy workflows, an agent may act before a human has reviewed the result. This means organizations need to secure the environment in which those tools operate.

Agent skills create another layer of risk

A separate analysis of enterprise design partner environments looked at a second supply chain layer: agent skills. Skills are instruction files that shape an agent’s behavior, defaults, personas, workflows, and reusable capabilities. They can help teams standardize agent behavior, but they also introduce another supply chain layer: instructions that may be shared, modified, pulled from third-party ecosystems, or executed outside normal code review.

Skills can introduce risk in several ways:

• Fetching instructions from external sources

• Exposing agents to uncontrolled third-party content

• Mishandling secrets

• Including hidden instructions that manipulate agent behavior

And because skills are often shared or pulled from third-party ecosystems, they can operate like a supply chain component even if they do not look like a traditional dependency.

Separate Snyk research into the public agent skills ecosystem shows how this risk can appear in the wild. In the ToxicSkills study, Snyk researchers analyzed 3,984 skills from ClawHub and skills.sh and found that 13.4% contained at least one critical-level security issue, while 36.82% had at least one security flaw. Human-in-the-loop validation also confirmed malicious payloads designed for credential theft, backdoor installation, and data exfiltration.

When external instructions can shape agent behavior, securing the generated code is only part of the job. Organizations also need to understand the instruction layer that influences how the agent works.

Why traditional AppSec controls need to expand

Traditional AppSec was designed around code, repositories, pipelines, and artifacts. Agentic development introduces risk earlier — inside the tools, instructions, and configurations that shape code before it exists.

AI coding agents may introduce risk before code is committed. For example, MCP servers may be installed on developer machines outside the centralized inventory, skills may shape behavior without being reviewed, as with source code, and agents may connect to tools and take actions while operating outside the traditional boundaries of SAST, SCA, CI/CD, or repository-based controls.

That does not make existing AppSec obsolete. SAST, SCA, IaC scanning, container security, and pipeline controls remain essential, but they may no longer be sufficient on their own. In order to keep up with evolving software development, security teams need to expand their programs beyond securing code artifacts to securing the systems that produce them.

That includes the agents, tools, integrations, instructions, and configurations involved in AI-assisted development. The core issue is visibility; if security teams cannot see which agents are in use, what they are connected to, and what instructions they consume, they cannot effectively govern the risk.

5 steps security teams should take now

Agentic development is moving quickly, but the answer is not to block AI adoption or slow developers down. Security teams need to bring visibility and governance into the workflows developers are already using, starting with five steps.

1. Discover what developers and agents are using: Inventory AI coding environments, MCP servers, skills, and integrations across developer environments. Teams cannot govern what they cannot see.

2. Treat agent configuration as part of the software supply chain: Security review should extend beyond code and dependencies to include the tools, instructions, and external components agents rely on.

3. Extend policy to MCP servers and skills: Organizations need a way to define what is allowed, restricted, requires approval, or should be blocked based on risk.

4. Evaluate guardrails for agent actions: As agents gain more autonomy, security controls need to operate closer to the moment of action, not only after code is produced.

5. Connect agentic development security to existing AppSec programs: This should not become a disconnected governance silo. It should be an expansion of AppSec for the way software is now being built.

These are the capabilities Snyk's Agentic Development Security approach is built around — from discovering and governing MCP servers and skills before they enter agent workflows, to applying guardrails inside the agent execution loop, to validating AI-generated code as it's created.

Securing the systems that help build software

AI-generated code security is necessary, but it is no longer enough on its own. As agents become more deeply embedded in software development, security teams need to understand not only the code agents produce, but also the tools, instructions, integrations, and permissions that shape that output. The software supply chain includes the agentic systems that help build software in the first place.

The full report contains the complete findings: which MCP servers are most widely installed and their associated risk profiles, a breakdown of skill finding types across enterprise environments, the full prompt injection and malicious code pattern data, and a detailed recommended actions framework for security teams. Download to learn more today.