MCP Server Protection Is Now a Product Category: The 12-Control Buy-vs-Build Test

On October 14, 2026, Radware (NASDAQ: RDWR) launched Model Context Protocol (MCP) Server Protection — the first purpose-built MCP defense product from a listed network-security vendor. The launch cites Stacklok's State of Model Context Protocol in Software 2026 as its market frame: nearly half of surveyed software companies run MCP servers in production, 19% in broad production. A listed vendor does not productize a security surface that is empty. At the same time, the attack ledger keeps filling: Splunk's own MCP Server shipped CVE-2026-76286 in October — an SSRF that hands a user's Splunk authentication token to whatever URL the custom tool's configuration points at. So the question for engineering leaders is no longer "should we harden our MCP servers" — the 12-control checklist settled that. The question is now: what does buying MCP protection actually close, and what does it leave open?

This article maps Radware's five announced capability groups against the 12-control baseline. The count: 3 controls close at the network edge, 5 get partial coverage, and 4 — the application-layer controls that decide whether a breach is noisy or silent — remain yours to build, in every deployment, with or without the product. The decision matrix below is the artifact.

Two honesty markers before the matrix, because both matter for how you read it. First, the product's capabilities are design-intent claims from a press release — each is phrased as "designed to," and Radware's December 3 webinar is the verification venue, not the announcement. Second, the mapping below is against the announced capability list; it is a testable hypothesis about what a network-layer product can see, not a review of shipped behavior. Run your own traffic against your own hardening evidence before adding anyone's product to a purchase order.

Key takeaways

• Radware (NASDAQ: RDWR) launched purpose-built MCP Server Protection on October 14, 2026 — the first MCP-defense product from a listed network-security vendor, citing Stacklok's State of MCP 2026 survey: nearly half of software companies run MCP servers in production, 19% in broad production.
• Splunk disclosed CVE-2026-76286 in its own MCP Server on October 7, 2026 (CWE-918, CVSS 5.3, fixed in 1.2.1) — an SSRF that sends the running user's platform token to a custom API tool's configured URL; it joins a ledger that already holds the ecosystem's first CVSS 10.0 (CVE-2026-16496) and two CISA KEV listings.
• Against the 12-control hardening baseline, a network-layer MCP product closes 3 controls — network isolation, flooding and DoS, shadow-server discovery — and leaves 4 application-layer controls (provenance, STDIO hardening, context boundary, kill switch) to the operator in every deployment.
• The 5 partial rows are detection, not enforcement — authentication-attack detection, agent-identity monitoring, and network-point audit telemetry do not replace the OAuth rollout, the identity lifecycle, or the immutable per-call audit record.
• The 12 controls double as the RFP — Radware's announced list claims visibility into exposed tools and resources but not tools/list drift detection, so the fingerprint-and-diff control that catches Deadbugz-class metadata poisoning stays on the operator's build list.

A listed vendor builds where the demand claims are

Security product categories form when four preconditions are met at once: the risk classes are enumerated, the attacks are specific, the incidents have names, and the demand is measurable. MCP crossed all four lines at once this month:

• The risks are enumerated. The OWASP MCP Top 10 catalogs ten named categories — Token Mismanagement through Context Injection and Over-Sharing — in Beta v0.1.
• The attacks are specific. Four community attack classes are documented in production detail: STDIO command injection (OX Security, 150M+ downloads affected), the Postmark MCP backdoor (tool poisoning in a legitimate-looking npm package), SHA-pinning bypass, and Deadbugz runtime-gated metadata poisoning (23 pull requests in 74 minutes, malicious tool definitions that surface only after three trusted calls).
• The incidents have names and numbers. CVE-2026-16496 put the first CVSS 10.0 in the ecosystem — a session-hijacking bypass in Terraform MCP Server's stateful transport. Two MCP-adjacent CVEs reached CISA's Known Exploited Vulnerabilities catalog, the second (CVE-2026-59822, CVSS 8.8) with a September 16 federal remediation deadline. Splunk disclosed CVE-2026-76286 in its own MCP Server on October 7, fixed in 1.2.1. Zenity's AgentCorruption showed the managed-platform blast radius: one prompt to one public-facing agent exposed credentials that reached every agent in the AWS account.
• The demand is measured. Stacklok's survey puts adoption where vendors can size a market: nearly half of surveyed software companies in production, 19% in broad production — ahead of the financial-services and retail cohorts it surveyed by the same method.

The scan-based numbers close the loop on urgency: 1,467 publicly accessible MCP servers with zero authentication (Trend Micro's corrected count, 1,227 on the deprecated SSE transport) and 82% path-traversal exposure with 8.5% OAuth adoption across 2,614 surveyed servers (Practical DevSecOps). Radware CTO David Aviv stated the product thesis in one sentence: "Organizations need to know which MCP servers they have, what those servers expose, which agents are accessing them and whether those interactions are safe." That sentence is, almost word for word, the checklist's inventory and drift-monitoring controls — now a product pitch.

What the product claims — five capability groups

The announcement sits Radware MCP Server Protection beside its existing Agentic AI Protection and LLM Firewall lines, deployable as a cloud service (Cloud Application Protection Service) or cloud-augmented on-premises on Alteon and DefensePro, across public cloud, private cloud, Kubernetes, and hardware-based data centers. Five capability groups are claimed:

1. MCP attack-surface visibility — deployed servers, exposed tools and resources, agent activity, usage patterns, communication flows.
2. MCP-aware attack protection — protocol abuse, authentication attacks, tool and resource enumeration, unauthorized MCP interactions, AI-driven tool flooding, denial-of-service.
3. Governance — exposure evaluation, weakness identification, policy enforcement at scale.
4. Agent-activity monitoring — agent identities, tool-invocation patterns, behavioral anomalies, resource-consumption trends.
5. Deployment flexibility — cloud service, or cloud-augmented on-premises Alteon and DefensePro.

Read that list against the attack ledger and the match is real but partial. The protection group (2) names exactly the attack surfaces that are visible on the wire: protocol abuse, enumeration, flooding, denial-of-service — the same classes the MCP Paradox article traces to the protocol's frictionless design. What is absent from the list is equally informative: nothing claims tool-definition drift detection (the Deadbugz class), nothing claims package provenance, nothing claims context-window enforcement, nothing claims the kill switch. Those are the controls that live before and inside the module — and they are the ones this article's matrix scores as the operator's job.

The Splunk CVE shows why the distinction matters in practice. CVE-2026-76286 is a defect in tool configuration: the MCP Server sent the running user's platform authentication token to the URL configured for that tool — and if another user controlled that URL, they captured the token and acted as the user. A network control can flag the egress attempt after the fact; the fix is a configuration rule that was already in the 12-control baseline — the server validates and owns every tool-configured URL, and module egress is scoped before the token moves (CWE-918, CVSS 5.3, patched in 1.2.1). Detection at the edge and enforcement in the config are different controls, and only one of them prevents the token from leaving.

The 12-control buy-vs-build test

The matrix below is the article's working artifact. Status is scored against the five announced capability groups: Closes means the announced capability covers the control's attack class at the network edge; Partial means the product sees or detects the surface while the enforcement, lifecycle, or authoritative record stays with the operator; Not covered means the control's surface is invisible to a network-layer tool by construction — not necessarily by any specific product's fault.

#	Control	What the product can claimed-cover	Status	What stays with you
1	SSE → Streamable HTTP migration	Inventory flags deprecated-SSE servers	Partial	The migration itself — an architecture change, not a filter rule
2	Network isolation and origin validation	Boundary enforcement at L3–L7 (the vendor's home turf)	Closes	Host/Origin validation inside the SDK remains app-layer
3	OAuth 2.1 + OIDC enforcement	Detection of authentication attacks, unauthorized interactions	Partial	Token issuance, scopes, RFC 8707 audience binding — rollout is yours
4	Agent identity separation	Agent-identity monitoring, behavioral anomalies	Partial	Provisioning, attestation, revocation lifecycle (SCIM/SPIFFE) is yours
5	Tool poisoning scan / drift detection	Protocol abuse and enumeration on the wire	Partial	Approval-time scans and post-install tools/list fingerprinting (Deadbugz class) stay yours
6	Signed provenance and AIBOM	—	Not covered	Registry and npm supply chain: attacks that land before the server speaks
7	STDIO hardening	—	Not covered	localhost transport between client and subprocess; no wire traffic to inspect
8	Rate limiting (flooding / DoS)	AI-driven tool flooding, denial-of-service	Closes	Per-tool, per-agent module-level limits beyond the boundary
9	Context boundary (OWASP MCP10)	—	Not covered	What the model reads inside the session is not network data
10	Kill-switch per module	—	Not covered	Your feature flag; a network block is containment of last resort
11	Per-call audit logging	Flow and anomaly telemetry at the network point	Partial	The authoritative immutable JSON per call — with input hashes — is yours
12	Shadow-server detection	Attack-surface discovery of deployed servers	Closes	Registry vetting and drift policy that define "known-good"

Tally: 3 close, 5 partial, 4 not covered. The same structure holds for every vendor in this emerging category, because the split is not a product limitation — it is an architectural boundary. UpGuard's finding that one in 15 MCP servers is a lookalike impersonation is invisible to a network boundary if the lookalike is npm-side; the Deadbugz payload arrives inside legitimate MCP responses a monitor can see but not semantically judge; and the model's context window is behind every boundary a network product can enforce.

The matrix as one view: three coverage bands, the market numbers behind them, and the RFP rule the picture carries:

Buying the partials is still rational — if you score them honestly

The 5 partial rows are where procurement conversations drift. "Authentication attack detection" does not mean OAuth 2.1 is deployed, and agent-identity monitoring does not mean agent identities are revocable. The partials are real value — detection without enforcement is a tripwire, and a network inventory that finds servers you did not register is the fastest shadow-MCP census you can buy. Score them as detection coverage, not control closure:

• C1/C3/C4 partials convert to full controls only when the operator's own work happens — the transport migration, the OAuth rollout, the identity lifecycle. Monitoring can drive the remediation queue; it cannot be the remediation.
• C5 partial deserves a specific RFP question, because it is the highest-consequence gap: can the product diff a server's tools/list responses over time and alert on semantic drift? The announcement names visibility into exposed tools and resources — it does not claim drift detection, and Deadbugz is designed to defeat every review that stops before an un-diffed fourth call.
• C11 partial cuts both directions: network-point telemetry feeds anomaly detection the module cannot see, but the authoritative audit record — timestamp, agent ID, tool, input hash, output status — must be structured, immutable, and under your control. AgentCorruption is the counterexample that settles why: after a platform default role exposed every agent in the account, "which agent, which tool, whose input" had to be answered from logs the operator owned.

The buy-vs-build boundary

Four rules fall out of the matrix:

1. Buy the network layer when your exposure is network-shaped. Flooding, enumeration, protocol abuse, and an unknown server population are wire-visible problems, and a vendor with DDoS/WAF lineage prices and operates them as a service. If you run multi-tenant, multi-team agent estates on shared infrastructure, that layer is likely someone else's core competency.
2. Own the four application-layer controls regardless of purchase. Provenance (C6), STDIO hardening (C7), context scoping (C9), and the kill switch (C10) are not on any network vendor's claimed list this week, and they are not buyable as a product line at all — they are properties of how your modules are built and operated. The MCP Module Code Standard is the build-side reference for making them enforceable in the module itself.
3. Turn the 12 controls into the RFP. Ask any prospective MCP-security vendor for evidence against the matrix, not claims: a drift-detection demonstration against the Deadbugz pattern, a sample audit record matching your schema, and the exact scope of "governance" — enforcement over what, enforced where. What the vendor evidences closes; what it cannot stays on your build list.
4. The build half has a free reference. The Microsoft Agent Governance Toolkit ships 10/10 OWASP MCP Top 10 coverage (7 fully, 3 partial with roadmap) as an open-source runtime — the non-commercial complement to a commercial perimeter. The checklist's scoring model (12/12 production-ready; below 8, do not expose to production) is the acceptance gate for both halves.

The pattern generalizes beyond Radware: the Black Hat 2026 wave already brought shadow-server discovery (Cyera Agent Guardian), identity governance (SailPoint), and network-layer monitoring (Check Point AI Network Firewall) — covered in the parent checklist's update log — and gateway vendors like TrueFoundry carry the governance half. Radware's entry puts a listed vendor behind the purpose-built product. The category's convergence is the market's job from here; the four controls a network product cannot see remain the operator's.

Related reading

• MCP Security Hardening Checklist: 1,467 Exposed Servers and the Controls That Close Them — the parent article: the 12 controls across five layers that this article's matrix tests against, plus the update log of CVEs, KEV listings, and attack classes.
• The Default Role, Not the Model: How One Prompt Took Over Every Agent in an AWS Account — the managed-platform incident that defines the operator-side audit requirement: a platform default execution role, scoped account-wide, decided the blast radius.
• Deadbugz: The Fourth MCP Attack Class Hides Until You Trust It — the runtime-gated metadata-poisoning class behind this article's C5 RFP question: approval-time scanning cannot see it, fingerprint-and-diff can.

---

A representative build: a mid-market distributor exposing one MCP module into production — a NetSuite catalog reader and quote generator with write-back to the ERP. The network layer (in whatever product form the estate already trusts) discovers the module, monitors the agent traffic, and floods-proof the boundary. The four application-layer controls are built into the module before the first tool call: signed provenance for the artifact, no user-controlled paths in STDIO, context scoped per tool, kill switch exercised once in staging. The one-week Discovery phase produces the server inventory and the 12-control scorecard that turns any vendor's capability list — this one or the next — into a verifiable RFP response instead of a slide.

One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.