Why Whack-a-Mole MCP Governance Fails and What Continuous Behavioral Visibility Actually Looks Like at Scale

Shadow MCP usage detection and remediation needs a live inventory of connections that employees create, distinct agent identities, and controls that check and stop tool calls before they run. Patching alone fails because excess permissions, injected instructions, and credential misuse arise during normal operation. Continuous behavioral visibility connects each MCP interaction to its agent, tools, credentials, and expected behavior so security teams can detect drift and enforce policy before a downstream system accepts the action.

Why the MCP governance problem is structural, not incidental

Anthropic released MCP in late 2024, and the protocol moved quickly from a way to connect agents to tools into shared infrastructure. The Linux Foundation’s December 9, 2025 announcement placed it within the Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI. Organizations were no longer managing an isolated integration, but a growing set of connections between agents and enterprise systems.

The original specification did not require an authentication framework when it shipped. Its trust model treated MCP servers as benign and tool outputs as coming from well-behaved systems. That assumption left a consequential gap because descriptions and outputs could influence what an agent did next. A connection was therefore more than a route to data. It was also a route through which outside content could shape an agent’s actions.

A stronger authorization model helps only when servers and gateways enforce it, and connections already in use may keep their earlier permissions and trust assumptions. The structural problem sits between what the protocol permits, what deployments enforce, and what agents actually do.

How the whack-a-mole response pattern forms and why it persists

A disclosed vulnerability gives an organization a bounded task. Patch the server, rotate the credential, or close the exposed port, and the response has a clear endpoint. That is a rational way to handle the immediate defect. The mistake is treating completion of that task as evidence that the surrounding agent environment is governed.

Between disclosures, agents can accumulate access and teams can add tools without reviewing their runtime behavior. Engineering teams can also create MCP connections without security review, leaving integrations outside the inventory. Those connections escape the patch process itself.

The way organizations reward work adds to this pattern because each fix has a clear owner and end date, while ongoing oversight has no finish line. Each incident becomes another project with an end date, even as it shows that the organization needs a control that stays in place. No bad faith is required. The response process is simply narrower than the exposure it is meant to address.

The strongest objection is straightforward. “We patch promptly and have had no incidents.” But an absence of detected incidents cannot establish that unmonitored agents are behaving safely. Indirect prompt injection and credential drift may use legitimate access without a software defect to fix. Teams still need to patch, but patches cannot show what happened between them.

The three runtime exposures that no CVE patch ever reaches

Over-scoped permissions are the first exposure. Developers use broad credentials to avoid authorization errors, and those permissions can persist into production. The Supabase Cursor incident in June 2025 showed the consequence. An agent with service-role privileges processed a support ticket containing instructions to query the integration_tokens table, then posted live credentials into a public thread. The attack worked without stolen credentials or a software vulnerability because the agent already had the access. OWASP names privilege escalation via scope creep as its own category in the MCP Top 10.

Behavior drift is the second exposure, and it begins when outside content becomes an instruction. The GitHub MCP incident in May 2025 used a hidden payload in a GitHub Issue to redirect an agent into exposing private repository contents through an auto-created pull request. The task changed without a user authorizing that change. Tool poisoning exploits a related trust boundary through altered tool descriptions, while a “rug pull” changes tool behavior after approval. A patch inventory cannot show whether the agent’s next action still does the work it was given.

Credential sprawl is the third exposure. API keys in environment variables, tokens in configuration files, and long-lived service credentials extend the reach of a compromised server. The Sandworm_Mode campaign in February 2026 used npm typosquatting to install rogue MCP servers in AI coding environments. Those servers used prompt injection to collect and locally cache SSH keys, AWS credentials, and npm tokens, with separate infrastructure handling network exfiltration. Across a tool-call chain, authenticated requests can look legitimate even when an injected instruction from several steps earlier set them in motion.

Why conventional security controls cannot see these threats

A well-formed, authenticated request does not explain why an agent sent it. WAFs, API gateways, DLP tools, and SIEMs inspect useful evidence, including HTTP envelopes, payload signatures, and known-bad patterns. But those checks do not establish whether a tool call follows user intent or an injected instruction.

A gateway that does not parse MCP semantics cannot distinguish these cases from the HTTP envelope alone. Authorization proves that an identity may perform an action. The control must evaluate what the agent is about to do and how that action relates to the work it was given.

Reviewing the interaction afterward leaves the same gap in time. An audit record can explain a disclosure or destructive action without making it reversible. The decisive test is therefore whether the control can stop a tool call before the downstream system accepts it. Conventional controls remain useful, but they do not close this semantic gap merely by receiving more logs.

What continuous behavioral visibility actually requires in practice

Teams first need an inventory that they keep up to date. It must include registered agents, shadow MCP connections, and agent-to-agent communication flows, rather than only tools that passed an approval process. Each registry entry needs the tool name, version, approval status, credential bindings, and owning team. Ownership makes an unapproved connection actionable.

The second component is a distinct identity for every agent, with no shared keys or reused sessions. Credentials should be issued just in time, last on a minute-scale, and retire when the task ends. Authorization should limit both the action and the resource, with runtime attributes refining access. Gateway enforcement gives servers a shared policy boundary so each server does not have to put the same controls in place. With the stable Enterprise-Managed Authorization extension, an identity provider already in use can issue tokens for MCP access directly.

The third component is an immutable record of every tool call. It must capture the tool name, parameters, response hash, timestamp, and calling agent identity, and reside outside the agent process and any filesystem path the MCP server can access. Those records need to be checked against each agent’s behavioral baseline. Logging alone is not behavioral detection. The baseline gives an unexpected invocation meaning within the agent’s usual work.

The fourth component is enforcement before execution, the hardest requirement because it moves the control into the action path. An MCP-aware gateway must parse protocol semantics and support blocking, redacting, or quarantining a call before acceptance downstream. Detection must address tool poisoning, prompt injection, intent drift, and credential misuse. An alert after execution is not equivalent.

How a unified platform differs from assembling these controls piecemeal

Separate inventory, identity, audit, and enforcement tools can leave different accounts of the same interaction. An agent builder may know the task, an identity tool may know the credential, and a gateway may see the request without enough context to connect them. Correlation then happens after the fact. The weakness lies in those seams, where an over-scoped credential or an uninterruptible tool-call chain can escape a complete assessment.

A unified platform should be judged by how well it closes those gaps, since the number of functions on its feature list does not show that. Its inventory, credential bindings, behavioral records, and enforcement decisions need a consistent view of the agent and its tools. Shared context is the test. If an audit system records a suspicious chain but the runtime control cannot interrupt it, the organization still has separate capabilities.

NIST’s AI RMF MANAGE function calls for continuous monitoring and incident response. Agent behavior can change without a model update, so periodic reconciliation between systems is a poor substitute for that continuity. The same integration also supports adoption. Employees who are not power users need a governed route to automation that does not require them to assemble security controls for each connection.

Regulatory deadlines that turn this from best practice into a compliance requirement

The EU AI Act requires high-risk AI systems to have logging and human oversight. Article 12 requires automatic event logging for as long as the system is in use, so reliable records are required by law even when they are not needed for debugging. The Act also requires relevant logs to be kept for at least six-month retention. For MCP deployments, tool-call records provide the detail needed to connect agent behavior with consequential actions.

Article 14(4)(e) addresses the ability of human overseers to intervene or interrupt a high-risk system, as appropriate and proportionate. It describes a stop button or similar procedure that allows the system to halt in a safe state. Pre-execution enforcement supports that requirement, although blocking an individual call must sit within an oversight design that can bring the system to a safe halt.

The Act’s penalties can reach €35 million or a significant share of total worldwide annual turnover, whichever is higher. At the national level, NIST’s AI Agent Standards Initiative launched in February 2026, with an interoperability profile expected in Q4 2026. That standards timetable is distinct from a binding compliance deadline. Together with the framework’s monitoring requirements, it gives organizations a concrete reason to make agent oversight an infrastructure deliverable rather than postpone it until another vulnerability appears.

How do security teams find shadow MCP connections and move to continuous enforcement?

The transition begins with an internal inventory of agents and MCP servers, including connections created without security review. Security and platform teams should ask for that inventory before trusting overall adoption figures, then scan and register connections so downstream controls have known connections to govern. When teams register tools, they should link them to approval status, credentials, and the team that owns them. This turns shadow usage into addressable work. A count of unauthorized servers alone does not establish who owns them or what access they hold.

The next step is identity enforcement at the gateway. No agent should enter production without a distinct identity and a time-limited, task-scoped credential, making OAuth 2.1 and scoped access entry conditions. The authorization extension lets the organization use its existing identity provider without consent screens for each user. That establishes who is acting and under what limits. It also gives later behavioral records a stable identity to follow.

Teams should then invest the first weeks of instrumented production traffic in behavioral baselines. Without that reference, anomaly detection creates noise because it cannot tell ordinary work from a change that needs a closer look. Once baselines exist and logs resist tampering, the gateway can move from observing and alerting to blocking and quarantining. The sequence is deliberate. Each layer gives the next layer evidence or a control it needs.

At scale, this foundation lets teams govern changing combinations of tools, credentials, and workflows without reopening the entire security process for every connection. Approved paths give employees a way to build useful automation within known limits, while security teams can intervene when behavior departs from those limits. The goal is a production environment in which safe agent adoption is the default, and security and IT make that adoption possible across the company.