There's a before-and-after line in the history of AI agent deployments, and Model Context Protocol is it.

Before MCP, agents were powerful but bounded. They could reason, retrieve, and respond. What they could do in the world was limited by whatever tools a developer explicitly wired up, in whatever deployment environment those tools could reach. Dangerous? Sure, if the tools were dangerous. But bounded.

MCP governance is the practice of defining and enforcing policies on AI agents that use Model Context Protocol to connect to external tools and services. Because MCP dramatically expands an agent's capability surface — connecting it to file systems, databases, APIs, and communication platforms through a standardized protocol — it proportionally expands the attack surface and the governance requirements. MCP governance operates at three layers: tool allowlisting and scoping (which tools can be called, under what conditions), tool result inspection (scanning responses before they enter agent context), and sequence-level policy evaluation (tracking cross-tool patterns within a session). (See also: What is agentic governance →)

After MCP, the story changes. MCP is a standardization layer that lets agents connect to an expanding universe of tools, services, and data sources through a common protocol. File systems, databases, APIs, code execution environments, communication platforms — anything that implements the MCP server interface becomes available to any agent running an MCP client. The capability surface expands dramatically, dynamically, and in ways that may not be fully visible to whoever is nominally in charge of the agent.

That's genuinely exciting from an engineering standpoint. It's also the setup for a governance problem most teams aren't ready for.

What MCP Actually Changes

The key shift is this: before MCP, an agent's capabilities were determined at deploy time by whatever tools a developer explicitly configured. After MCP, an agent's capabilities can be dynamically extended by connecting to MCP servers — some of which the developer chose, some of which may have been added by other users, other systems, or the agent ecosystem itself.

This is not a hypothetical. MCP adoption is moving fast. Claude Code implements an MCP client. Developer tooling is shipping MCP integrations. Enterprise platforms are building MCP servers for their internal systems. Within the next 12-18 months, it's reasonable to expect that most production agents in sophisticated deployments will have access to significant tool ecosystems via MCP.

Here's the governance implication, stated plainly: when your agent had five explicitly configured tools, you could reason about what it might do with those five tools. When your agent has access to dozens of tools via MCP — some installed by you, some added by others, some with capabilities that have changed since you last reviewed them — the reasoning problem is fundamentally different.

How Does MCP Expand the AI Agent Attack Surface?

Every tool an agent can access is a potential attack surface. Not because the tool is malicious, but because any tool can be invoked in ways that cause unintended consequences, and the space of invocations an LLM might generate is large.

Prompt injection via tool results. This is the one that should keep security teams up at night. If an agent retrieves a document via an MCP tool, and that document contains text designed to alter the agent's behavior ("ignore your previous instructions and..."), the document contents are now in the agent's context — and may influence its subsequent behavior. This isn't a bug in MCP. It's an inherent property of how LLMs process input. The governance response is pre-execution scanning of tool results for injection patterns.

Unauthorized tool invocation. An agent that has access to a "send email" MCP tool can send emails. The question is: under what conditions should it be allowed to? If the agent's legitimate scope is answering product questions, and it has access to an email tool for a narrow set of notification purposes, what prevents it from invoking that tool in other contexts? Without an explicit policy that defines when the tool may be called, the answer is "the model's judgment." That's not a policy. That's a hope.

Data exfiltration through tool calls. An agent with access to database query tools and communication tools could, in theory, retrieve sensitive data and transmit it externally — not through a single dramatic action, but through a sequence of plausible-looking operations that individually wouldn't raise flags. Defending against this requires visibility into sequences of tool calls and cross-tool patterns, not just individual invocations.

Cost explosions from unconstrained tool use. Some MCP tools are expensive to call. Code execution environments, large data retrievals, external API calls with per-request pricing — an agent that calls these tools more aggressively than expected, or that gets into a loop involving expensive tools, can run up costs quickly. Without budget governance at the tool call level, you won't know until after.

Why Existing Agent Governance Doesn't Fully Address MCP

If you have governance infrastructure in place — policies on LLM calls, input/output scanning, session-level budget guardrails — you have a foundation. But MCP introduces governance requirements that that foundation may not cover.

Dynamic tool availability. Static governance policies assume a known, fixed set of tools. MCP's whole point is that the tool set is extensible. Your governance layer needs to handle tool calls against tools that weren't in scope when the policy was written — which means you need policies that can generalize across tool categories, not just name-specific allowlists.

Tool result trust. Your existing scanning may evaluate inputs from users. MCP tool results come from servers, not users, and deserve their own trust evaluation. A tool result can contain malicious content even when the tool itself is legitimate and the server is trusted. The content-as-attack-surface problem requires governance at the tool result layer, not just the user input layer.

Cross-tool sequence analysis. Individual tool calls may be benign. Sequences of tool calls may not be. A governance layer that evaluates each tool invocation in isolation misses the pattern-level risks. This requires session-level analysis — tracking what tools have been called, in what sequence, with what payloads — and applying policies to sequences rather than just individual events.

What MCP Governance Actually Looks Like

Practically speaking, MCP governance operates at three layers:

Tool allowlisting and scoping. Define explicitly which MCP tools the agent is permitted to call, under which conditions, with which parameter constraints. This is the analog of RBAC for tool access — not just "can the agent access this tool" but "under what circumstances." An agent might be permitted to read files but not write them, or to query a database but only within a specified set of tables, or to call an email tool only when a specific approval condition is met.

Tool result inspection. Every tool call response that gets appended to the agent's context should pass through an inspection step before it's processed. Scan for injection patterns. Check for PII that shouldn't be entering the context. Validate that the response conforms to expected schemas. Flag anomalies for review.

Sequence-level policy evaluation. Track tool call sequences within a session and evaluate them against session-level policies. A policy might say: if more than three different external endpoints are called within a single session, flag for review. Or: if a database read is followed within N turns by any outbound call, require approval. These are session-level governance decisions, not call-level decisions.

Why Is Now the Right Time to Establish MCP Governance?

MCP is early enough that the tooling ecosystem around it is still being built. Including governance tooling. The organizations that establish MCP governance practices now — while the tool ecosystem is still relatively small and the attack surface is still relatively bounded — will be in a fundamentally different position than the organizations that establish MCP governance practices in 18 months, when the ecosystem is larger and the incidents have started accumulating.

There's a general principle here worth stating: the right time to build governance for a capability is when the capability is being adopted, not after the first incident that makes its absence visible.

MCP is being adopted right now. Governance time is right now.

How Waxell handles this: Waxell has first-class MCP support built into its policy engine — tool-level allowlisting, tool result inspection (scanning for injection patterns and PII before results enter agent context), and session-level sequence analysis. You define which MCP tools each agent is permitted to call and under what conditions; Waxell enforces those rules at every invocation. See what runtime governance looks like →

Frequently Asked Questions

What is MCP governance? MCP governance is the practice of enforcing policies on AI agents that use Model Context Protocol to access external tools and services. It covers which tools an agent is permitted to call (allowlisting), what conditions must be met before a tool is invoked (scoping), whether tool results are safe to enter agent context (result inspection), and whether a sequence of tool calls within a session is consistent with policy (sequence-level analysis).

How does Model Context Protocol change the AI agent attack surface? Before MCP, an agent's capabilities were fixed at deployment time — a developer explicitly configured each tool. With MCP, an agent's capabilities can be dynamically extended by connecting to MCP servers, some of which may have been added by other users or systems. This expands the attack surface from "five tools you explicitly chose" to "an ecosystem of tools with capabilities that may have changed since you last reviewed them." Governance requirements scale with that expansion.

What is prompt injection via MCP tool results? Prompt injection via tool results occurs when an MCP tool returns content that contains instructions designed to alter the agent's behavior — for example, a retrieved document containing text like "ignore your previous instructions and..." That text enters the agent's context window and may influence subsequent reasoning. It's not a bug in MCP; it's an inherent property of how LLMs process input. Defense requires scanning tool results for injection patterns before they're appended to context.

How do you govern AI agents that use MCP tools? Effective MCP governance requires three layers: tool allowlisting (explicitly defining which tools the agent may call and under what conditions), tool result inspection (scanning every tool response for PII, injection patterns, and schema anomalies before it enters context), and sequence-level monitoring (tracking cross-tool patterns within a session and triggering policies based on sequences, not just individual calls). Static policies based on named tool allowlists need to generalize across tool categories as the MCP ecosystem grows.

Why doesn't existing agent governance fully cover MCP? Most existing governance infrastructure was designed for known, fixed tool sets. MCP's value proposition is a dynamically extensible tool ecosystem — which means static name-based allowlists become inadequate. Additionally, MCP introduces tool result trust evaluation as a distinct concern: a tool can be legitimate and its server trusted, but its results can still contain malicious content. Governance layers that only evaluate user inputs miss this vector entirely.