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

On April 20, 2026, CIS published its MCP Security Companion Guide — a set of controls co-authored with Astrix and Cequence that extends CIS Controls v8.1 into MCP environments. The finding that prompted it: MCP formally expands an agent's identity, access control, logging, and application security surfaces in ways that most enterprise governance frameworks don't yet cover. Four days earlier, The Register reported that security researchers had documented a design flaw in the official MCP implementation that, according to their analysis, puts as many as 200,000 servers at risk, with 10 high- and critical-severity CVEs filed. If MCP governance wasn't on your radar six months ago, it is now.

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). For a broader definition of the governance plane that MCP sits within, see What is agentic governance →.

Before MCP, agents were powerful but bounded. What they could do in the world was limited by whatever tools a developer explicitly wired up — dangerous if the tools were dangerous, but bounded. 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. That dynamic extensibility is what makes MCP valuable, and what makes governance non-optional.

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.

MCP adoption is moving faster than most security teams anticipated. Claude Code ships an MCP client. Developer tooling is shipping MCP integrations. Enterprise platforms are building MCP servers for internal systems. Most production agents in sophisticated deployments will have access to significant tool ecosystems via MCP within the next 12–18 months — if they don't already.

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. The CIS guide introduces the concept of "Non-Human Identities" (NHIs): each MCP connection is a non-human identity with its own access scope, and most organizations don't have a registry for them or policies governing what they can do.

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. In March 2026, Oasis Security researchers demonstrated a complete attack pipeline — dubbed "Claudy Day" — that chained invisible prompt injection with data exfiltration, showing that conversation history could be stolen from a default, unmodified claude.ai session. No special configuration. No elevated permissions. The injection was embedded as invisible HTML tags inside Claude's ?q= URL pre-fill parameter — invisible to the user in the chat box, but transmitted in full to the model when they pressed Send. Delivered via a Google Ads campaign exploiting an open redirect on claude.com, Claude was then instructed to exfiltrate conversation history to an attacker-controlled Anthropic account via the Files API. This wasn't a breach; it was a demonstration of what's possible when content entering agent context goes uninspected. For a deeper technical breakdown of how prompt injection enters agents through tool call results, post 43 covers the mechanism in full.

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 call sequences. An agent with access to database query tools and communication tools could 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 within a session, not just individual invocations. This is what the CIS guide calls "auditable interactions across the protocol layer."

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 gets into a loop involving expensive tools, can run up costs quickly. Without budget enforcement 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 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 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. The GitHub coding agent prompt injection case — where instructions embedded inside repository files were retrieved and acted on by an agent without disclosure — is a sharp example: GitHub AI Agent Prompt Injection: What No CVE Disclosure Looks Like.

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 individual events.

Under EU AI Act Annex III (enforcement deadline: August 2, 2026), deployers of high-risk AI systems must retain automated logs for at least six months and implement human oversight mechanisms. A November 2025 European Commission proposal to delay this deadline was not enacted into law — the Digital Omnibus trilogue failed on April 28, 2026 — and August 2026 remains the operative enforcement date. MCP tool call sequences are exactly what those audit trail requirements are designed to capture, and most existing governance stacks don't log them at that level.

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 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 only within a specified set of tables, or to call an email tool only when a specific approval condition is met. Waxell Runtime ships with 26 policy categories out of the box that cover these scoping decisions, applying them pre-execution without requiring agent rebuilds.

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.

For teams governing MCP servers they didn't build — marketplace servers, vendor-provided integrations, third-party data connectors — Waxell Connect governs those agents with no SDK and no code changes required. The MCP STDIO design flaw that put 200,000 servers at risk is a clear example of why governance of external MCP servers can't depend on the servers themselves implementing controls.

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 CIS MCP Security Guide was published precisely because organizations are deploying MCP and running into a predictable set of problems: audit trails, SSO-integrated auth, gateway behavior, and configuration portability. The guide exists because there was demand for it. That demand reflects real production deployments hitting real governance gaps.

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, the incidents have accumulated, and the EU AI Act Annex III enforcement machinery is operational.

There's a general principle 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.

How Waxell handles this: Waxell has first-class MCP support built into its policy engine — tool-level allowlisting and scoping, tool result inspection (scanning for injection patterns and PII before results enter agent context), and session-level sequence analysis. Waxell Runtime enforces these rules at every invocation pre-execution, with 26 policy categories out of the box and no agent rebuild required. For MCP servers you didn't build — vendor integrations, marketplace connectors, third-party tools — Waxell Connect governs them with no SDK and no code changes required. Request early access →

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. In March 2026, Oasis Security demonstrated the "Claudy Day" attack chain — showing that invisible prompt injection plus data exfiltration was achievable against a default claude.ai session without any special configuration, using a URL parameter injection delivered via Google Ads. Defense requires inspecting all content before it enters agent context, whether from tool results, URL parameters, or any other source.

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.

What does the CIS MCP Security Guide (April 2026) recommend?
The CIS MCP Security Guide, published April 20, 2026 in partnership with Astrix and Cequence, extends CIS Controls v8.1 into MCP-based environments. Key recommendations include: governing Non-Human Identities (NHIs) created by each MCP connection, implementing secure tool access controls with explicit permission grants per capability rather than broad access, ensuring auditable interactions across the protocol layer, and addressing four priority risk areas — data leakage, unbounded agent autonomy, credential misuse, and unsafe tool execution.

Sources

• Center for Internet Security (CIS), Astrix, and Cequence, CIS, Astrix, and Cequence Release New AI Security Companion Guides (April 20, 2026) — https://www.cisecurity.org/about-us/media/press-release/cis-astrix-and-cequence-release-new-ai-security-companion-guides

• The Register, MCP 'design flaw' puts 200k servers at risk: Researcher (April 16, 2026) — https://www.theregister.com/2026/04/16/anthropic_mcp_design_flaw/

• Oasis Security, Claude.ai Prompt Injection Vulnerability ("Claudy Day") (March 2026) — https://www.oasis.security/blog/claude-ai-prompt-injection-data-exfiltration-vulnerability

• Palo Alto Networks Unit 42, New Prompt Injection Attack Vectors Through MCP Sampling (2026) — https://unit42.paloaltonetworks.com/model-context-protocol-attack-vectors/

• EU AI Act Service Desk (European Commission), Timeline for the Implementation of the EU AI Act — https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act

• EU Artificial Intelligence Act, Annex III: High-Risk AI Systems Referred to in Article 6(2) — https://artificialintelligenceact.eu/annex/3/