The MCP Governance Illusion: Why Governing Tools Is Not Enough

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.

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. 

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.

Why Tool Governance Misses the Point

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 till the objective is met, even if it means bypassing security controls and jeopardizing the organization.

One Restriction, Many Paths

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:

• Connect through the Python Snowflake SDK
• Execute SQL through a script with credentials pulled from an environment variable
• Invoke the Snowflake CLI
• Pull credentials from a connected secrets manager
• Log into the Snowflake console through browser automation

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.

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 uses the SDK. Each restriction stops at one tool boundary while the agent's reach extends beyond it.

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

We claim that the only question that matters, when it comes to governing AI is “What is the outcome the agent may achieve?”

The outcomes worth governing cross every tool boundary:

• Exporting customer data outside the organization
• Deleting or modifying production records
• Sending external communications on behalf of the organization
• Modifying IAM permissions or access controls
• Creating or destroying cloud infrastructure
• Accessing systems outside the agent’s defined scope

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.

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 a prohibited access to Snowflake, we can now monitor for this outcome and block any attempt to achieve it, whether it is via MCP server, or developers’ credentials, or running Snowflake SDK with Python or any other language.

In practice, this means capturing agent objectives before execution, classifying the business impact, and enforcing decisions at the intent level. Tool restrictions become one input in the decision, not the decision itself.

MCP governance has a place in this model. It sits closest to the tool, where fast checks catch obvious violations before they reach the more expensive intent-evaluation layer. What it cannot be is the only layer.

‍