Snyk launches Evo ADS to secure AI coding agents with real-time governance

AI coding agents are no longer novelties — they generate and ship production code, unsupervised, inside enterprise environments. Security has not kept pace. Yesterday's scanners watch code after it lands. Agents, though, call arbitrary tools, invoke skills from uncertain sources, and walk through internal APIs with no human watching. That is the new perimeter. Snyk's answer is Evo Agentic Development Security (Evo ADS): a governance layer that operates inside the agent workflow, in real time, before code or damage lands. Snyk's announcement positions Evo ADS as the enforcement layer for the AI agents now building enterprise software — governing what agents use, what they do, and what they generate.

The headline idea: govern, not just scan. For the developer or security lead watching agents run inside the firewall, the shift from post-hoc review to in-the-loop enforcement is the overdue part. This retrofit grounds every number below in Snyk's own published release wording, and where the original draft over-claimed, it now says so.

What Snyk Evo Agentic Development Security is

Evo ADS is a security governance layer for autonomous AI coding agents, announced in Boston on June 23, 2026 as an extension of Snyk's AI security platform to what the company calls the AI workforce powering modern software development. Instead of passively scanning output, Evo ADS enforces rules around the tools, connections, and code actions agents attempt during workflow execution. The focus is not just the code but the entire perimeter: which MCP servers agents touch, the skills they install, and what outbound connections they make.

What sets Evo ADS apart from legacy security tools is placement in the loop. It operates as a continuous control layer inside the agent workflow rather than downstream of it, across three layers of the agentic development lifecycle, per the release: secure the agent supply chain (discover and assess the MCP servers, skills, and external tools agents pull in before agents interact with them), govern agent behavior (monitor and enforce real-time policy on what agents do while they operate, blocking destructive actions before they execute), and ensure trusted output (scan and fix AI-generated vulnerabilities at the moment of creation rather than in post-production review). Snyk's own contrast is with internal AI gateways, which can route and log traffic but cannot determine whether an MCP server is malicious, whether a skill carries hostile instructions, or whether generated code is actually exploitable — that, Snyk argues, requires an independent enforcement layer. Full product detail lives on Snyk's Evo ADS page.

One wording note: the original draft called Evo ADS "the first tool designed to control" the agent perimeter. The release itself does not make a first-ever claim — it frames Evo ADS as closing a governance gap most organizations currently leave open. This retrofit uses Snyk's framing, not the superlative.

Why autonomous AI coding agents are a security challenge

Autonomous agents do not just write code. They operate — acting as developers or ops, calling shell tools, installing packages, and connecting via MCP servers to a web of skills and third-party APIs. A single agent may reach dozens of MCP-integrated tools in a shift. Security moves from static code analysis to active workflow governance, because the thing being secured is behavior, not artifacts.

Snyk's published telemetry — anonymized data from nearly 9,700 developer environments, also written up in the company's state-of-agentic-supply-chain report — makes the scale concrete. Forty-three percent of developers run two or more AI coding environments simultaneously, and more than half have MCP servers installed, with the most instrumented environments running more than 80 MCP servers at once. These connections create live access to code repositories, browsers, internal tools, and production systems, with no security controls between them.

The risk inside that supply chain is measured, not hypothetical. One in 12 developers with MCP servers has a high or critical finding. A separate analysis of early ADS enterprise design-partner environments found that nearly one in four developers has at least one skill installed, averaging 18 each, with more than one in ten skills referencing external dependencies or externally hosted instructions. And publicly documented attacks have already demonstrated working exploits through the agent toolchain itself, from malicious MCP servers to prompt injection embedded in the dependencies agents consume. Existing security tools scan code after it is written; they have no visibility into MCP configurations, skills, or what agents do at runtime.

The Model Context Protocol is the connective tissue here — the open standard letting agents reach tools and data — which is exactly why MCP servers are the shadow supply chain. Skills can reference arbitrary dependencies or fetch code from external instructions, often invisible to the primary dev team. That is the sprawling, dynamic attack surface Evo ADS is built to govern.

How Evo ADS protects AI coding workflows

The release describes enforcement at three layers, each mapped to an AI agent pain point. This is not post-hoc scanning; enforcement happens in the workflow.

Secure the supply chain first. Before agents interact with anything, Evo ADS discovers and assesses the MCP servers, skills, and external tools agents pull in — surfacing prompt injection, malicious code patterns, and supply-chain risks up front. The payoff Snyk's CTO names directly: asked for a complete inventory of the AI agents, MCP servers, and skills running across developer machines, most organizations cannot produce one. Discovery of what is actually installed is step zero, and most teams have never done it.

Govern behavior at runtime. As the agent runs, policy is enforced on what it does while it operates — blocking destructive actions before they execute, governing which systems agents access and which workflows they run. The conceptual shape is a policy sketch like this (illustrative example, not Snyk syntax):

# Illustrative sketch of an agent runtime policy — conceptual only
policies:
  - action: block
    when:
      agent_calls: unapproved_mcp_server
  - action: require_approval
    when:
      agent_calls: external_package_install

The point is hard-stop enforcement with real-time alerts, not best-effort auditing hours later.

Validate output at creation. As the agent emits code, vulnerabilities are scanned and fixed at the moment of creation — security at inception rather than post-production review. The engine targets known vulnerable patterns and risky code before it ships, not after the merge.

The combined advantage is putting controls in the loop, not after it. The attack surface never widens past the agent boundary, and compliance, incident response, and rollback stay tractable because every phase is observed by the same layer.

How developers adopt it

Snyk frames adoption as staged rather than rip-and-replace: Evo ADS can wrap existing agent deployments or sit alongside legacy scanning, covering the agent-specific areas older tools ignore. The practical sequence for a team looks like this.

First, establish the inventory the release keeps emphasizing — which agents, MCP servers, plugins, and skills are running across the fleet. Without that baseline, policy has nothing to attach to. Second, define trust policies for the highest-risk surfaces: unvetted MCP servers, skills with external dependencies, and outbound connections to unapproved endpoints. Third, connect findings and policy events to the existing SIEM or security console so violations trigger the same incident workflows as any other control — block, alert, roll back.

No install commands or CLI syntax are quoted here deliberately: Snyk's release describes product mechanics, not command-line interfaces, and this retrofit will not invent terminal commands the vendor never published. Teams evaluating Evo ADS should start from the product page and the announcement rather than third-party command snippets.

What impact this has on enterprise software security

Evo ADS closes a foundational gap: live, inside-the-workflow enforcement for AI agent lifecycles. The enterprise numbers make the case for why the gap matters — one in 12 MCP environments with high or critical findings that can now be blocked before code or data is touched; skill sprawl averaging 18 installed skills per skill-using developer, turned from invisible risk into a governable inventory; unauthorized actions like outbound API calls and external code fetches becoming blockable in the loop rather than detectable days later.

Early enterprise design partners saw agent, MCP, and skill inventories for the first time — an end to the shadow infrastructure. Security teams gain one policy engine to manage, sanction, or restrict AI agent behaviors. The result Snyk claims: drops in agent-originated vulnerability surface, faster containment, and a shift from forensics to prevention. Treat that last line as the vendor's thesis to validate in a pilot, not a measured outcome — the release quotes a design partner and the company's own CTO, not independent benchmarks. The telemetry figures, by contrast, are published data and fairly quoted above.

If you deploy AI coding agents or run MCP servers, the structural lesson stands regardless of vendor: you need a perimeter that moves with the agent, inventorying what it touches and governing what it does, before harm triggers. And the code those agents operate on should itself be built for this world — OTF kits ship as readable, agent-navigable repositories with portable configuration, so the security boundary holds even as underlying models and agent platforms churn. Build on kits your agents can actually govern.

Sources

• Snyk launches Evo Agentic Development Security — announcement, telemetry figures, three enforcement layers, CTO quote.
• Snyk newsroom — release index confirming title and placement.
• Evo ADS product page — product detail and positioning.
• Model Context Protocol introduction — MCP as the agent-to-tool standard behind the risk surface.
• Related reading: AI app security checklist, Agent-readable repository structure, AI production background jobs.

Originally published at otf-kit.dev — full-stack kits your AI coding agent can actually ship to production. See the kits →