On June 23, 2026, Snyk published telemetry from an analysis of nearly 10,000 real developer environments, and the numbers describe a workflow that has quietly outrun its own security model. Snyk's research team, publishing under the byline of Ricardo Miguel Silva to coincide with the launch of its Evo Agentic Development Security product, found that 43% of developers now run two or more AI coding tools simultaneously — Claude, Cursor, Windsurf, Gemini, Copilot, and Kiro among them — with 37% running three or more, and the top 1% juggling as many as 13 Model Context Protocol (MCP) servers at once. MCP adoption has already cleared the halfway point of that population, at 50.8%, and Snyk found that one in seven of those developers had turned up at least one security finding among their installed servers, with one in twelve landing a high-or-critical-severity issue. This matters because every one of those tools was granted, by design, some combination of filesystem read/write, shell execution, and outbound network access — the same permissions a human developer has, handed to software that follows natural-language instructions embedded in files it did not write. Snyk paired that live-environment telemetry with a companion study, ToxicSkills, that scanned thousands of public agent skills and found more than a third already carrying an exploitable flaw — evidence the exposure described below is already shipping in marketplaces developers pull from today.
What did Snyk actually measure across those 10,000 environments?
Snyk instrumented real developer machines and design-partner enterprise environments to catalog which AI coding tools, MCP servers, and agent skills were installed and running concurrently, rather than surveying developers about stated habits. That distinction matters because self-reported tool usage chronically undercounts shadow adoption — a developer who added a Cursor extension for one task and forgot about it doesn't mention it in a survey, but it still shows up in telemetry with live filesystem access. Snyk's dataset captured 43% of developers running 2+ AI coding tools concurrently and 37% running 3+, with a long tail: the top 1% of environments had 13 or more MCP servers active at the same time. Each additional tool is a separate trust boundary with its own permission surface, update cadence, and supply chain, and Snyk's framing is that nobody — not the developer, not the security team — has an inventory of what's actually installed, let alone what each one can reach. That absence of inventory is the precondition for everything that follows.
What is an MCP server and why does its adoption rate matter?
MCP, the Model Context Protocol, is the mechanism by which coding agents like Claude Code and Cursor connect to external tools, databases, and services through a standardized interface, and Snyk found it installed in 50.8% of the developer environments it analyzed. An MCP server is effectively a plugin that an agent can call mid-task — to query a database, hit an internal API, or read a ticketing system — and because the protocol is new and largely unaudited, Snyk's scans found that one in seven developers running an MCP server had picked up at least one security finding, with one in twelve turning up something high or critical. Unlike a vetted package from a curated registry, an MCP server's tool descriptions are text the agent reads and can act on, meaning a malicious or careless MCP author can embed instructions that manipulate agent behavior rather than exploiting a traditional code vulnerability. With adoption already past 50% and the top decile of developers running over a dozen servers at once, this is not a fringe integration pattern — it is becoming the default way developers extend agent capability, arriving faster than any review process built to vet it.
How do agent skills and plugins expand the blast radius further?
Agent skills and plugins — distributed through marketplaces like ClawHub and skills.sh — extend an agent's behavior with packaged instructions and code, and Snyk found at least one such skill running in 22.8% of the environments it scanned. Across that corpus, Snyk's researchers turned up 392 cases where a tool description itself carried an embedded prompt-injection payload, plus 98 tool or skill files containing confirmed malicious code. The mechanism is what makes this dangerous: a skill's description is not sandboxed documentation, it is context the agent treats as instructions, so a poisoned skill can direct the agent to read credentials, exfiltrate files, or run shell commands under the same authority the developer already granted it — no separate exploit chain required, just a plausible-sounding tool description sitting in a marketplace listing.
What does the ToxicSkills research show about real-world exploitation?
Snyk didn't stop at telemetry from live environments — a companion study called ToxicSkills went and scanned 3,984 public skills pulled straight from ClawHub and skills.sh, rather than relying on what developers say they've installed. It found that 13.4% of those skills carried at least one critical-level security issue, 36.82% had a flaw of some severity, and 28% exposed the agent to third-party content it had no independent way to verify before acting on it. Read alongside the 392 prompt-injection and 98 malicious-code findings from the live-environment corpus, the pattern holds across both datasets: an agent with shell and filesystem access encounters an instruction or a code path from a source it was never designed to independently verify — a tool description, a skill file, a README a maintainer added last week — and executes it with the same privilege as the developer who invoked the agent. This is a fundamentally different failure mode than a classic dependency CVE, because the agent isn't running vulnerable code so much as following attacker-authored instructions that arrived through a channel nobody was screening for that purpose. Traditional SCA and SAST tooling, tuned to detect known-bad code patterns and CVE matches, were not built to catch a sentence in a tool description telling an agent to read ~/.ssh/id_rsa.
What's actually at stake when an agent has broad filesystem and shell access?
What's at stake is that every credential, config file, and internal script an agent's process can touch becomes reachable by anything that can influence the agent's behavior — a compromised dependency, a malicious skill, or an MCP server with a high-severity finding. Developers routinely keep AWS credentials in ~/.aws/credentials, SSH keys in ~/.ssh, and npm auth tokens in ~/.npmrc precisely because those files are meant for tools running on their own machine with their own trust — an assumption that breaks down the moment an AI agent with equivalent filesystem access is also parsing untrusted tool descriptions and dependency metadata as part of its normal operation. Snyk's 1-in-12 high/critical MCP finding rate (among developers running MCP servers) and its 98 confirmed malicious skill-file patterns describe exactly the kind of exposure that turns a routine npm install or agent task into a credential leak, without a single line of code the developer wrote being at fault. Codebases that never had a secrets problem before adopting agentic tooling can develop one overnight, simply because the number of untrusted inputs an agent processes on a developer's behalf has multiplied far faster than anyone's review process.
How Safeguard helps
Safeguard doesn't scan third-party MCP servers or agent skill marketplaces directly, but it closes the two exposure paths Snyk's data makes concrete. Secrets scanning covers source code, git history, and build logs for exactly the credentials an agent with filesystem access could read or commit — AWS keys, GitHub PATs, Anthropic and OpenAI API keys among them — and verifies each finding against the issuing service so a leaked-but-revoked key doesn't sit in a queue as a false alarm; teams can also install safeguard install-hook --hook pre-push so a credential an agent stages for commit never leaves the machine in the first place. Eagle, Safeguard's malware classification model, scores every package pulled into a build for the same credential-harvesting indicators the ToxicSkills findings illustrate — reads from ~/.aws, ~/.ssh, and ~/.npmrc — catching the compromised-dependency half of the attack chain before it reaches an agent's execution context. Guardrails policy can then make either finding a hard block at commit, CI, or registry admission, so the growing population of AI coding tools on a developer's machine doesn't get a free pass just because a human didn't type the risky command themselves.