The MCP Governance Illusion: Why Governing Tools Is Not Enough

Solutions

Resources

Company

CustomersPricing

Platform

Solutions

Resources

Company

Customers<br>Pricing

Back

Products

Capabilities

Services

Back

Industries

Solutions

Partnerships

Back

Resources

AI Security School

Back

About Cyera

About Us

Trust Center

Newsroom

Careers

Careers IL

Partners

Contact Us

Get a demo

Get a demo

The MCP Governance Illusion: Why Governing Tools Is Not Enough

Ehud Halamish

Guy Halevi

Jul 7, 2026

Share

There’s the old cliché that security teams work with lists while attackers use graph patterns, creating a gap that makes security harder. The security community has recognized this and is working to close the gap. Now, code-capable agents raise this problem to a new level. For example, if I want to completely block the connection between my AI stack and my Snowflake database, the naive approach is to block my organization from running a Snowflake MCP server - problem solved.<br>While this security solution may work for agents without a bash tool, since they cannot write code and bypass them, a code-capable agent (like Claude Cowork and Codex) is changing this equation completely. It will search for 5 relevant solutions like locating user credentials, finding an API key and running a Python connector, logging into another server, reading logs, whatever it can do to solve and optimize the problem.<br>Here, a simple governance program is not enough; a more robust solution is needed. In this blog, we discuss this issue thoroughly and suggest more holistic solutions.<br>Why Tool Governance Misses the Point<br>MCP governance rests on an assumption inherited from traditional software security, where the tool is the control point. When a developer uses an approved API, that API's access controls, audit logs, and rate limits govern what happens. When a user operates through an approved application, the application enforces the business rules. This is a reasonable solution for humans because they commit to between 1 and several tools and stick with them for a long period. Agents, however, operate differently, searching and discovering paths to successfully accomplish their objective at runtime. If one path is blocked, the agent evaluates alternatives and selects one until the objective is met, even if it means bypassing security controls and jeopardizing the organization.<br>One Restriction, Many Paths<br>Let’s dive deep into the first example. Consider an organization that prohibits agents from accessing Snowflake through an MCP server. The governance team reviews the restriction, approves it, and closes the ticket. However, they restricted only one execution path. What the agent can still do:<br>Connect through the Python Snowflake SDK<br>Execute SQL through a script with credentials pulled from an environment variable<br>Invoke the Snowflake CLI<br>Pull credentials from a connected secrets manager<br>Log into the Snowflake console through browser automation<br>At least five paths remain open while the MCP restriction removed only one, so accessing Snowflake is still achievable. For a human user, it’s clear this is a restriction. Some will waive this option, some will argue with the governance team and settle it, and only a few will try bypassing the restriction with clever one-offs. However, the speed and extent of searching for, finding, and applying a solution will not match that of an AI agent.<br>The same logic applies to every category of sensitive action. Block email capability and the agent will start an SMTP service, configure it, and send emails. Block Salesforce MCP and the agent will find credentials to the Salesforce API and query it directly. Block a Slack MCP server and the agent will use the SDK. Each restriction stops at one tool boundary while the agent's reach extends beyond it.<br>This is a property of code-capable agents. More capable models find more alternative paths. Tool restrictions offer diminishing returns in this environment.

Governing Intent, Not Tools<br>We claim that the only question that matters, when it comes to governing AI is “What is the outcome the agent may achieve?”<br>The outcomes worth governing cross every tool boundary:<br>Exporting customer data outside the organization<br>Deleting or modifying production records<br>Sending external communications on behalf of the organization<br>Modifying IAM permissions or access controls<br>Creating or destroying cloud infrastructure<br>Accessing systems outside the agent’s defined scop<br>Governance should permit or deny each of these based on intent, evaluated before execution, regardless of the tool the agent selects. Writing to a production table requires the same authorization whether it comes through an MCP server, a Python ORM, a raw SQL script, or a Terraform application.<br>So, if we go back to the original example. The AI agent is still trying to connect to Snowflake, if we identify the outcome, which is prohibited access to Snowflake, we can now monitor for this outcome and...