Evaluating Enterprise Platforms Built to Detect MCP-Native Threats at Runtime

An enterprise MCP security and governance platform must watch the full agent session, tie identity and policy decisions to each tool call, and step in before harmful actions finish. Testing these platforms means checking how well they do those things against tool poisoning, prompt injection, intent drift, and exfiltration. Authentication and static scanning provide useful protection, but neither can establish whether an authorized agent’s behavior remains safe as its session unfolds.

Why MCP threats are structurally invisible to static and perimeter-based tools

Traditional API security inspects a bounded exchange. A client calls, a server checks credentials, data returns, and the transaction closes. MCP turns that exchange into part of a longer decision chain because an LLM can discover tools, call APIs, read resources, and trigger workflows across systems. A request can look acceptable on its own while contributing to an unauthorized outcome across the session.

Checkmarx’s MCP security analysis describes the full chain of delegation as the user, the acting client, the called server, the token, the accessed resource, and the authority for that action in context. A perimeter tool does not see that chain as a unit. Individual exchanges still happen, but their boundaries do not contain the whole security decision. Faster inspection of isolated events cannot supply the missing relationship between them.

That mismatch extends across five risk planes, including transport and communication, authentication and identity, context integrity and confidentiality, authorization and privilege management, and supply chain security. Each protects a different boundary in the workflow. Securing transport does not establish that context is trustworthy, while establishing identity does not establish that a sequence of actions serves the authorized task. The unobserved layer remains open to abuse.

The four MCP-native threat classes that unfold dynamically inside a live session

Tool poisoning targets instructions. MCP tool descriptions enter the agent’s context as trusted content, so an attacker controlling a description can bury directions the model treats as legitimate guidance. Code review and signature verification do not establish whether those directions are adversarial.

Prompt injection through context poisoning exploits what happens next. Corrupted context moves through the workflow and feeds bad inputs to downstream agents that use it. The instruction travels inside content that is otherwise legitimate, so the attack does not need a malformed request. Schema validation therefore does not establish that the content is safe to follow, and a web application firewall lacks the context needed to judge its role in the agent’s decisions.

Rug-pull attacks take advantage of the trust a server earned before an update. A server passes review, gets installed, and later changes its instructions to misuse the access it already has. Invariant Labs demonstrated the cross-server danger with a “random fact of the day” MCP server containing hidden instructions aimed at a legitimate WhatsApp MCP server connected to the same agent. Encryption did not stop the exfiltration that followed because it happened above that layer, within what looked like normal agent activity. The specification has no built-in way to track tool-definition changes or require approval again.

Intent drift develops across a sequence of decisions. An agent starts with an authorized goal, then shifts toward unauthorized behavior as context accumulates. Progressive movement through customer records illustrates why nominally permitted calls need a session-level judgment. Supply chain compromise can bring these threats straight into systems with production access. The Cloud Security Alliance’s May 2026 research note describes an architectural flaw disclosed by OX Security in April 2026 across a supply chain of more than 150 million package downloads.

Why authentication improvements and static scanning each cover only part of the problem

Authentication answers an essential but narrower question. It establishes who can connect and under what authority. An agent with a valid, correctly scoped token can still retrieve an entire spreadsheet of customer records. A legitimate credential does not settle whether that retrieval belongs in the current workflow.

The MCP specification launched in November 2024 without an authentication framework. Its 2026-07-28 revision hardens authorization and rewrites the session and transport model. The CSA note describes the OAuth 2.1 profile as optional and the base specification as lacking a standardized audit trail format. It also documents a July 2025 scan identifying at least 1,862 publicly accessible MCP instances responding to unauthenticated requests. These are real identity gaps, separate from the behavioral risks that remain after authentication succeeds.

Static scanning serves another useful, bounded purpose. It can flag suspicious patterns before deployment, but a matching phrase does not prove hostile intent. Standard tool instructions and adversarial directions can share the same wording. A scanner also cannot inspect a malicious definition that replaces the approved version later. These limits call for additional layers alongside authentication and pre-deployment checks.

What a platform must do architecturally to detect MCP-native threats as they unfold

Runtime detection requires continuous observation of the decision chain, attribution at each tool call, and the ability to intervene mid-session. A platform that can watch but cannot step in records behavior it has no way to stop. Intervention without session context risks treating each call as an unrelated event. Both capabilities need the same view of the agent’s accumulated actions.

That history must inform authorization before sensitive actions. An agent that retrieves one customer record poses a different risk from one whose earlier calls show progressive lateral movement, even when both requests fall within their permissions. The platform therefore needs to connect the proposed action to the task and the session trajectory. A token check alone cannot make that distinction.

Tool definitions also need comparison across sessions. Onboarding review establishes what was approved then, while change tracking reveals what the agent is being told now. To make those decisions auditable, the platform must record the applicable identity, authority, and policy when it allows or blocks an action. A later reconstruction cannot reliably replace the context available at that moment. Detection and governance depend on this same decision-time evidence.

What platforms detect tool poisoning and prompt injection in MCP environments?

Microsoft’s approach to identity and governance brings agents into systems for conditional access, lifecycle automation, and directory-level audit. CrowdStrike added AI agent identity and continuous authorization to Falcon after it acquired SGNL in February 2026. These approaches are strongest in identity and access management, including just-in-time authorization and approval flows. Those controls should not be mistaken for semantic analysis of tool instructions or session behavior.

Holistic AI uses a different division of responsibilities. Its Guardian Agents include Sentinel Agents that passively observe and log agent actions against policy, paired with Operative Agents that intervene and remediate when thresholds are crossed. Of the model-governance approaches described here, it comes closest to runtime control. That architecture alone does not show that it covers every MCP-native attack class.

Keycard brings session context into tool-call authorization. It evaluates the agent’s stated reasoning together with the cumulative session trajectory, then grants or withholds credentials for the call. Aembit instead intercepts outbound access requests, cryptographically attests workload or agent identity, applies policy, and issues short-lived credentials for the interaction. Its focus is credential lifecycle and identity. The distinction is between evaluating behavior and controlling the credentials that enable it.

Palo Alto Networks adds MCP security within Cortex Cloud WAAS. Its stated coverage includes MCP communication validation and API-based attack prevention for teams using that platform. That addresses the communication boundary but does not, by itself, establish trajectory-aware detection or tool-definition change tracking. None of these approaches is interchangeable with the others. Their fit depends on which boundaries the enterprise needs the platform to observe and enforce.

The precision problem and why detection needs semantic analysis

False positives are a real obstacle to runtime detection. Pattern matching can flag ordinary instructions such as “You MUST call this function first” because the wording resembles an injection attempt. Yet the same phrase may describe a tool dependency that is legitimate. A security team cannot keep up with a workflow that requires it to work through large numbers of these alerts by hand.

Detection needs context for its observations. Semantic analysis asks whether an instruction’s purpose is adversarial in the situation where the agent receives it. Trajectory-aware analysis asks whether the accumulated actions have departed from the authorized goal, while comparison across sessions asks whether a tool definition has changed meaningfully. Old Dominion University’s TrustShiftProbe research characterizes staged trust attacks and proposes trajectory-aware defenses.

Pattern rules still provide a useful signal. Configuration-drift scanning and supply-chain scanning check other layers that those rules cannot cover. A platform either combines these signals into a coherent assessment or leaves the team to correlate separate alerts. Semantic analysis should improve that assessment. Confidence depends on distinguishing benign instructions from malicious intent without losing the sequence that makes the distinction possible.

The compliance and audit requirements that now make runtime detection a governance obligation

For regulated enterprises, that sequence also becomes audit evidence. The EU AI Act’s enforcement beginning August 2026 brings lineage-backed auditability and human oversight requirements for high-risk AI systems. Penalties for high-risk violations can reach a significant share of global annual turnover. The 7% limit applies only to prohibited AI practices under Article 5. Buyers need to distinguish the applicable obligation from the headline penalty.

Across SOX, HIPAA, the EU AI Act, and DORA, the governing audit question is why an action was allowed, under which policy, and by whose authority. Access logs alone do not answer it. The permissions architecture described in the brief includes unique agent identity, accountable ownership, task-scoped access, runtime authorization before sensitive actions, and short-lived credentials. It also includes approval gates for high-impact operations and records of every delegation, policy decision, and tool result.

Checkmarx identifies why attribution becomes difficult across these boundaries. The user, AI host, MCP client, MCP server, exposed tools, and downstream systems may operate with different assumptions about identity, consent, permissions, and intent. Blurred boundaries produce blurred accountability. Runtime evidence connects an action to the authority that permitted it, giving governance teams a basis for explaining the chain rather than reconstructing it from disconnected events.

How to evaluate a platform’s runtime detection claims against the actual capability requirements

For a procurement or build-versus-buy decision, test six capabilities behind the “runtime” product category. First, establish whether the platform observes the full session or inspects calls in isolation. Seeing intent drift and cross-server exfiltration requires observing the full session. Second, check whether it tracks tool definitions across sessions and sends alerts when they change. An onboarding-only review cannot detect a later rug pull.

The third test concerns evidence at decision time. The platform should tie identity to each tool call and preserve the policy and authority behind the decision. Fourth, test whether semantic analysis separates adversarial instructions from ordinary tool patterns.

The fifth test is breadth across all five risk planes. Coverage concentrated on identity or transport needs to be evaluated as such, without assuming protection for context integrity, authorization, or the supply chain. Sixth, check whether enablement and control work in one platform or require links across a separate agent builder, gateway, and security tool. A fragmented stack leaves the enterprise responsible for those connections. The buying decision should turn on demonstrated coverage of the live decision chain, including the ability to stop it when authorized access becomes unauthorized behavior.