# Evo ADS Govern Agent Behavior Goes GA: Bringing MCP Usage Under Control > Source: > Published: 2026-09-30 04:00:00+00:00 # Evo ADS Govern Agent Behavior Goes GA: Bringing MCP Usage Under Control September 30, 2026 0 mins read Today, we're announcing that **Govern Agent Behavior**, the capability within [Evo Agentic Development Security (ADS)](https://snyk.io/blog/agentic-development-security-ads/) that controls what AI coding agents are allowed to do at runtime, is generally available, starting with **MCP Governance**. Since introducing [Evo ADS](https://snyk.io/evo/agentic-development-security/) in June, we've built toward a simple idea: [agentic development introduces risk across three surfaces,](https://snyk.io/lp/three-places-ai-agents-introduce-risk-in-dev/) and each needs its own form of control: 1. What agents **use** : the MCP servers, skills, and tools they pull in, which need discovery and assessment. 2. What agents **generate** , which needs validation at the moment of creation. 3. And what agents **do** : The actions they take once they've decided to act, which need to be enforced in real time. Govern Agent Behavior is how Evo ADS answers that third question, and MCP Governance is the first use case shipping under it. In practical terms, MCP Governance gives security and platform teams a way to discover all the MCP servers across their estate, define which MCP servers are allowed for use, see the moment an agent steps outside that policy, and log or block MCP usage at the moment of execution, live, across Claude Code, Cursor, Codex, and GitHub Copilot. Governing which tools an autonomous agent can call is foundational: the kind of control most security teams assumed already existed, until they went looking for it and found nothing. MCP Governance closes that gap natively, within the same workflow where the agent supply chain is discovered and AI-generated code is validated, rather than as a separate tool bolted on. ## Why governing MCP matters now The [Model Context Protocol (MCP)](https://snyk.io/articles/what-is-mcp-in-ai-everything-you-wanted-to-ask/) is the standard that enables AI coding agents to connect to external tools, data sources, and systems, including repositories, databases, cloud infrastructure, and internal APIs, through a common interface. It's a big part of why agents increasingly feel less like autocomplete and more like coworkers: [an agent with MCP access](https://snyk.io/articles/snyk-mcp-cheat-sheet/) doesn't just suggest a line of code, it can query a ticketing system, pull records from a production database, or call an internal service, all inside the same session. That power is also the problem. MCP standardizes *how* agents connect to tools, but it says nothing about *which* tools should be trusted, or what an agent should be allowed to do with the ones it can reach. Every MCP server an agent connects to is, functionally, a new piece of your software supply chain. Except, unlike a dependency pinned in a manifest, it's often introduced dynamically, by a developer installing it in a few seconds, with no review process behind it. [That exposure isn't hypothetica](https://snyk.io/lp/six-ways-ai-agents-act/)l, and it isn't new; it's the same [malicious-package problem](https://docs.snyk.io/scan-fix-and-prevent/fix/prioritize-issues-for-fixing/malicious-packages), now running through a different door. A compromised MCP server can read local files, exfiltrate credentials, or reach internal systems the moment it's run, before a security team even knows the server exists, let alone has a chance to review it. The risk materializes on the developer's machine, at the moment it's called, so that's where it has to be caught. The scale is bigger than most security teams assume. Snyk's own scan data, drawn from nearly 10,000 developer environments, found 4,524 unique MCP servers in active use, with the most heavily instrumented machines running 13 or more simultaneously. More than half of developers already have live MCP connections into production tools and systems. And when we looked at the security posture of those connections, 1 in 12 developers with an MCP server installed had a confirmed high or critical finding today. None of this shows up in a traditional AppSec pipeline since MCP servers aren't artifacts scanned in CI or dependencies reviewed before merge. Instead, they're introduced live, at runtime, frequently outside any process security ever sees. Without a way to say which MCP servers are acceptable and enforce that at the moment an agent tries to use one, "adopting AI agents" and "expanding your unmanaged attack surface" become the same sentence. ## How MCP Governance works in Evo ADS MCP Governance is Evo ADS's answer to that gap and a direct extension of the visibility that Evo ADS already provides into the agent supply chain. It does three things: ### 1. Feeds Snyk your list Security and platform teams define which MCP servers are approved, pulling from an existing inventory, a manually curated list, or the servers Evo ADS has already surfaced through discovery. This becomes the baseline policy every agent on the fleet is measured against. This can be done manually or simply by prompting Evo in the chat! ### 2. Observes out-of-policy usage Once policy is in place, Evo ADS continuously monitors MCP activity across your developer machines and surfaces every instance of an agent reaching for a server that isn't on the approved list, whether that's a one-off local install or a pattern showing up across the fleet. Nothing has to be blocked for this visibility to be useful; for many teams, simply knowing what agents are actually connecting to is the first real inventory they've had. ### 3. Governs usage at runtime This is where visibility becomes control. Evo ADS can log unauthorized MCP usage for audit, or block it outright, directly on the endpoint, at the moment an agent tries to connect, not after the fact, and not dependent on the agent choosing to comply. MCP Governance runs wherever your agents already do. It's available today across Claude Code, Cursor, Codex, and GitHub Copilot, enforced through lightweight hooks that sit alongside the agent rather than routing its traffic through a separate proxy or gateway. This is the same approach Evo ADS uses for secure-at-inception code scanning, meaning teams don't need to change how agents connect to tools, stand up new infrastructure, or accept a new point of failure in the agent's execution path. Policy lives centrally; enforcement happens locally, at the point where the decision to use an MCP server is actually made. ## What's next for agent behavior governance We're deliberately calling this the first use case, not a finished story. MCP Governance answers, "Is this agent allowed to reach this tool?" It’s a necessary question, but not the only one. An agent working entirely inside an approved MCP server can still run a destructive shell command or move sensitive data somewhere it shouldn't, and MCP Governance alone won't catch that. That's where Evo ADS goes next. In the coming weeks, we're extending enforcement beyond MCP allowlisting to cover and block agents performing. We're moving the MCP policy itself from a static list to something teams can feed directly from a git repo or Confluence page using the Evo MCP, and toward risk-based enforcement, so policy reflects how risky a server actually is rather than a fixed allow or deny. Beyond that, over the rest of the year, we're expanding ADS's coverage to govern unauthorized access to sensitive data, [__prompt-injection protection__](https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/), and [__secret exposure__](https://snyk.io/blog/snyk-secrets/) in agents. We’re also bringing the same discover-classify-enforce model MCP Governance introduced to [__Agent Skills__](https://snyk.io/blog/snyk-tessl-partnership/). Governing what agents use is necessary. Governing what they do, at the moment they do it, is what makes that governance real. MCP Governance is the first proof point, and it's live today. Want to see MCP Governance in action? [__Schedule a demo__](https://snyk.io/evo/schedule-a-demo/), or explore [__Evo Agentic Development Security__](https://snyk.io/evo/agentic-development-security/) to learn how Evo ADS secures what agents use, do, and generate across the AI-driven development lifecycle. BOOK A LIVE DEMO ## Secure AI adoption at scale Evo helps organizations safely adopt and scale AI by providing visibility, governance, and security across AI-driven development and AI applications.