MCP-Specific Threat Categories Every Enterprise Governance Team Must Operationalize

An enterprise MCP security and governance platform must link detection at the tool level to policy enforcement based on identity and audit records that are tamper-proof. Securing Model Context Protocol deployments means authenticating API traffic and governing what agents read, which tools they invoke, and where data goes. The six threat categories below each need their own controls built into how agents work before deployment.

Why MCP cannot be governed as generic API risk

Enterprises are putting MCP into production before governance frameworks exist to control it. Security maturity is trailing adoption, and vulnerabilities are accumulating. Between January and April 2026, researchers disclosed more than 40 CVEs against MCP implementations across Python, TypeScript, Java, and Rust SDKs. But the trust problem remains even after those flaws are patched.

MCP standardizes tool discovery and invocation through JSON-RPC while leaving authentication, authorization, and transport security to implementers. Tool metadata enters the model’s context without built-in validation, clients discover tools at runtime, and definitions can change after approval. A reviewed connection can present new instructions without another review.

These features leave part of the attack surface out of reach of traditional perimeter controls, API gateways, and WAF rules. A valid request can contain a tool description that redirects an agent, while an authenticated response can introduce hostile instructions. Network controls still have a role. They cannot substitute for detection logic, policy triggers, and audit records that understand MCP tools and agent actions.

Tool poisoning and rug pull attacks require detection at the metadata layer, not the output layer

Tool poisoning embeds malicious instructions in the descriptions an agent reads to understand available tools. Those descriptions enter the model’s context as natural language, where the model has no native way to distinguish legitimate metadata from poisoned metadata. The instruction may never appear in the interface. Inspecting the agent’s final answer therefore misses the point where the attacker gained influence.

Microsoft’s Incident Response and Defender research teams reported a scenario in mid-2026 in which a finance agent was connected to a third-party invoice enrichment tool. The tool had been approved without a real security review. An attacker then changed its description, leaving the visible name and summary identical while burying a hidden instruction in the metadata. MCP picked up the change without another review.

That update illustrates a rug pull, which differs from poisoning present at initial registration. A third variant, tool name collision, steers the agent toward the wrong server by using names like those of approved tools. These variants need different checks. The OWASP Top 10 for Agentic Applications classifies tool poisoning under ASI02 Tool Misuse & Exploitation, giving governance teams a named category for testing and evidence.

To operationalize that category, teams must fingerprint tool descriptions at the proxy layer and detect, log, and block changed definitions before they reach an agent. Signed manifests and version pinning must bind each definition to its approved version. A change must go through re-approval before it can be accepted. Each agent also needs an explicit allowlist scoped to its function, so a familiar-looking name does not grant an unapproved tool access.

Indirect prompt injection through tool responses is a supply-chain attack, not a chatbot problem

Poisoned instructions can arrive through a support ticket, PDF, webpage, calendar invite, or agent-to-agent handoff that the agent reads during legitimate work. The attacker never needs a direct conversation with the model. Instead, external content influences an agent operating with the invoking user’s privileges.

The Sandworm_Mode campaign had weaponized npm typosquatting by February 2026, using malicious packages that mimicked popular utilities and AI coding tools to install rogue MCP servers. It targeted coding assistants including Claude Code, Cursor, Windsurf, and Continue (VS Code), using prompt injection to exfiltrate SSH keys, AWS credentials, and npm tokens. Treating the resulting instructions as merely a chatbot problem would overlook how the attacker reached the agent.

The Supabase Cursor agent incident in July 2025 exposed a different entry point. A privileged agent was tricked into leaking integration tokens while it worked through support tickets from users. Its service-role access made that outcome possible. A read-only scoped agent would not have held the credentials needed to complete the attack.

An agent that reads untrusted external content must not also hold credentials to write to sensitive systems, and tool responses must undergo input validation before entering context. When external content triggers high-consequence actions, a human must approve them. Shared memory and RAG indices need the same input controls, because a poisoned document retained there can influence later sessions and other users.

Authentication failures — confused deputy, token passthrough, and excessive permissions — share one exploitable root cause

Content attacks exploit what an agent reads, while authentication failures exploit whose authority it uses. Confused deputy, token passthrough, and excessive permissions all break the relationship between the requester, the permission granted, and the channel used. They are distinct failures with a shared root. A successful login alone does not establish that the resulting action is properly authorized.

A confused deputy occurs when an MCP server uses its elevated credentials on an agent’s behalf, giving that agent authority it did not earn. Token passthrough instead involves accepting tokens not issued to the MCP server and forwarding them downstream without proper audience validation. The MCP specification explicitly forbids token passthrough with a normative MUST NOT. Implementers still have to enforce that prohibition at runtime.

Excessive permissions often start with development convenience. Broad service accounts avoid authorization errors, then reach production without being narrowed. A warehouse account with access to every table illustrates the risk. An agent asked for revenue by customer may also get PII fields, even though it is authorized to make the tool call. Across the live server ecosystem, unauthenticated tools and static tokens also leave the authentication baseline weak.

OAuth 2.1 with PKCE must take the place of static API keys in production, and audience validation at the gateway must reject tokens issued elsewhere and block passthrough. Least-privilege credentials must be scoped to the agent’s role independently of the developer’s existing access. Sensitive calls need long-lived service account keys replaced with just-in-time, short-lived credentials scoped to the session.

Credential sprawl and shadow MCP servers multiply every other threat invisibly

Shadow MCP follows the shadow IT pattern governance teams already know, but agents have direct system access by design. An unreviewed connection can reach a production CRM, warehouse, or file system. Security cannot govern a connection it cannot see.

Unmanaged deployments also scatter credentials across server configurations. Developers put API keys in environment variables, hardcode tokens in configuration files, and reuse long-lived service accounts because those choices are easy. Shared accounts make containment harder as well. Revoking one credential can disable several agents, while the shared identity leaves attribution uncertain.

The governance response must start with continuous discovery of every MCP connection, classified as local or remote and flagged when it bypasses approved provisioning. A production server allowlist must prevent unapproved servers from receiving traffic, even when they are reachable. Centralized credential management needs SSO and SCIM integration to tie credentials to managed identities. Enforced expiry, automatic rotation, and revocation when a team member leaves must replace dependence on someone remembering where a key was copied.

Intent drift and data exfiltration require runtime behavioral detection, not just access controls

Known servers and valid credentials do not guarantee an acceptable outcome. Intent drift is the incremental departure from an agent’s intended goal over a session or across sessions. Each action may be authorized in isolation. The sequence can still produce an outcome that governance would not have approved in advance.

An agent may use an allowed tool with a valid token and still retrieve customer records outside its task. An MCP server may also make outbound HTTP requests to undeclared destinations. Without egress monitoring, the tool call can be recorded as successful while the destination of the data goes unrecorded.

To detect that gap, every invocation must record agent identity, tool name, parameters, returned data volume, and outbound requests made during the call. Behavioral baselines must be specific to each agent role. Unusual volumes, unexpected tools, and new destinations must trigger real-time alerts before an incident review. Session monitoring must also compare the sequence of calls with the stated task before the session ends.

Detection needs enforcement at the same depth. MCP servers must be restricted to outbound endpoints declared in their manifests, with undeclared egress blocked and alerted. OpenTelemetry tracing must follow the full agent-to-tool chain so investigators can reconstruct data movement. SOC 2, HIPAA, and GDPR impose audit requirements that cannot be met by recording only that a gateway accepted a request.

Audit blind spots and missing agent identity make every other control unverifiable

Fragmented records leave no coherent connection between the human request, the agent’s activity, and the resulting tool calls. A breach may be detected without a defensible account of its reach. The missing evidence is what data moved and under whose authority.

Every agent therefore needs a verified, managed identity separate from user accounts and shared service accounts. SSO and SCIM must support provisioning and management of that identity. Attribution cannot rest on an originating IP address. The agent’s identity must be cryptographically attached to every tool invocation, so the record identifies the actor.

Logs must be write-once, stored outside systems the agent can access, and retained for the period required by the applicable compliance framework. A log the agent can overwrite is not dependable evidence. Full tracing must connect the human request, agent decision, tool call, data returned, and action taken into a complete causal record.

Automated compliance reporting must query that record in forms usable for SOC 2, HIPAA, and GDPR evidence requirements. Otherwise, teams are left reconstructing events manually from disconnected systems. This is not a demand to log more indiscriminately. Identity-tied, tamper-proof, causally complete records turn detection rules and policy controls from stated intentions into verifiable facts.

How the six threat categories map to a governance architecture rather than a checklist

The six categories require three integrated control planes, which are detection, policy enforcement, and audit. Detection must inspect metadata for poisoning and rug pulls, validate tool responses for injection, discover shadow connections, and compare session behavior with the agent’s role and task. Each check observes a different part of the workflow. A network-layer tool cannot replace these checks simply because all the activity crosses a network.

Policy enforcement must use what those checks find to make decisions based on identity. Changed definitions require re-approval, unapproved servers must be denied production traffic, and token audience checks must block passthrough. Per-agent permissions and just-in-time credentials must constrain downstream authority. The audit plane must then preserve what was detected, which policy applied, and what happened through the complete agent-to-tool chain.

An agent builder, gateway, and separate security tool leave gaps when they do not share an identity model, audit record, or enforcement point. A metadata alert without a block leaves the instruction exposed. A blocked request without attributable evidence leaves the control hard to verify.

The operating program must give teams a common vocabulary and a repeatable test process. OWASP categories including ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, and Agentic Supply Chain Vulnerabilities can organize red-team exercises, evidence, and vendor evaluation. Quarterly exercises must target agentic workflows specifically. Server governance must also set the minimum trust levels for servers in production, require audits of their dependencies, and use container isolation with network egress controls.

Security must make the approved route easier to use. An approved registry, credential provisioning that runs automatically, and built-in audit give developers a path they can use without filing a ticket for every connection. New servers must go through that path before they get production credentials. If the governed route is slower and harder than the shadow route, the shadow route wins.