Sicherheit & Governance

MCP Server Protection wird zur Produktkategorie: der Buy-vs-Build-Test mit 12 Kontrollen

Von IdeaBosque EngineeringZuletzt aktualisiert: 2026年10月14日

Am 14. Oktober 2026 hat Radware (NASDAQ: RDWR) Model Context Protocol (MCP) Server Protection eingeführt — das erste eigens für MCP-Verteidigung gebaute Produkt eines börsennotierten Netzwerksicherheitsanbieters. Die Einführung zitiert Stackloks State of Model Context Protocol in Software 2026 als Marktrahmen: Fast die Hälfte der befragten Softwareunternehmen betreibt MCP-Server in Produktion, 19 % im breiten Produktionsbetrieb. Ein börsennotierter Anbieter macht aus einer leeren Sicherheitsfläche kein Produkt. Zugleich füllt sich das Angriffsbuch weiter: Splunks eigener MCP Server veröffentlichte im Oktober CVE-2026-76286 — eine SSRF, die den Splunk-Anmelde-Token des Benutzers an jede URL ausliefert, auf die die Konfiguration des benutzerdefinierten Tools zeigt. Die Frage für Technikverantwortliche ist daher nicht mehr „Sollen wir unsere MCP-Server härten?" — die 12-Kontrollen-Checkliste hat das ohnehin geklärt. Die Frage lautet jetzt: Was schließt der Kauf von MCP-Schutz tatsächlich, und was lässt er offen?

Dieser Artikel mappt Radwares fünf angekündigte Capability-Gruppen gegen die 12-Kontrollen-Basislinie. Das Ergebnis: 3 Kontrollen schließen am Netzwerkrand, 5 erhalten Teilkontrolle, und 4 — die Anwendungsschicht-Kontrollen, die entscheiden, ob eine Verletzung laut oder leise verläuft — bleiben in jedem Deployment Ihre Bauarbeit, mit oder ohne das Produkt. Die folgende Entscheidungsmatrix ist das Werkstück.

Vor der Matrix zwei Ehrlichkeitsmarken, weil beide die Lektüre prägen. Erstens: Die Produkteigenschaften sind Design-Intentions-Behauptungen aus einem Pressetext — jede ist als „designed to" formuliert, und Radwares Webinar am 3. Dezember ist der Verifikationsort, nicht die Ankündigung. Zweitens: Das Mapping unten richtet sich nach der angekündigten Fähigkeitenliste; es ist eine testbare Hypothese darüber, was ein Netzwerkschichtprodukt sehen kann, keine Prüfung ausgelieferter Funktionsweise. Laden Sie eigenen Verkehr gegen eigene Härtungsevidenz, bevor irgendein Produkt in einen Auftrag wandert.

Kernbefunde

Radware (NASDAQ: RDWR) hat am 14. Oktober 2026 einen eigens entwickelten MCP Server Protection vorgestellt — das erste MCP-Verteidigungsprodukt eines börsennotierten Netzwerksicherheitsanbieters, zitiert Stackloks State of MCP 2026-Umfrage: Fast die Hälfte der Softwarefirmen betreibt MCP-Server in Produktion, 19 % im breiten Produktionsbetrieb.
Splunk hat CVE-2026-76286 in seinem eigenen MCP Server am 7. Oktober 2026 publiziert (CWE-918, CVSS 5.3, in 1.2.1 gefixt) — eine SSRF, die den Plattform-Token des laufenden Benutzers an die konfigurierte URL eines Custom-API-Werkzeugs sendet; er reiht sich in ein Buch, das schon den ersten CVSS 10.0 des Ökosystems (CVE-2026-16496) und zwei CISA-KEV-Listungen enthält.
Gegen die 12-Kontrollen-Härtungsbasis schließt ein Netzwerkschicht-MCP-Produkt 3 Kontrollen — Netzwerkisolation, Flooding und DoS, Shadow-Server-Erkennung — und überlässt 4 Kontrollen der Anwendungsschicht (Provenienz, STDIO-Härtung, Kontextgrenze, Kill Switch) in jedem Deployment dem Betreiber.
Die 5 Teilstücke sind Detektion, keine Durchsetzung — die Erkennung von Authentifizierungsangriffen, Agenten-Identitätsüberwachung und Netzwerkpunkt-Audit-Telemetrie ersetzen nicht das OAuth-Rollout, den Identitätslebenszyklus oder das unveränderliche Auditprotokoll pro Aufruf.
Die 12 Kontrollen sind zugleich das RFP — Radwares angekündigte Liste beansprucht Sichtbarkeit über exponierte Werkzeuge und Ressourcen, aber keine tools/list-Driftdetektion, also bleibt die Fingerprint-and-Diff-Kontrolle, die Deadbugz-artige Metadaten-Vergiftung fängt, auf der Baulliste des Betreibers.

Ein börsennotierter Anbieter baut dort, wo die Nachfrageanforderungen stehen

Sicherheitsproduktkategorien entstehen, wenn vier Vorbedingungen gleichzeitig erfüllt sind: die Risiken sind aufgelistet, die Angriffe sind konkret, die Vorfälle haben Namen, und die Nachfrage ist messbar. Diesen Monat hat MCP alle vier Linien gleichzeitig überschritten:

Die Risiken sind aufgelistet. Der OWASP MCP Top 10 verzeichnet zehn namentlich genannte Kategorien — von Token Mismanagement über Context Injection bis Over-Sharing — in Beta v0.1.
Die Angriffe sind konkret. Vier Community-Angriffsklassen sind in Produktionsdetail dokumentiert: STDIO-Befehlsinjektion (OX Security, mehr als 150M betroffene Downloads), die Postmark-MCP-Hintertür (Tool poisoning in einem legitim aussehenden npm-Paket), SHA-Pinning-Umgehung, und Deadbugz' runtime-gated Metadaten-Vergiftung (23 Pull Requests in 74 Minuten, böswillige Werkzeugdefinitionen, die erst nach zwei vertrauten Aufrufen auftauchen).
Die Vorfälle haben Namen und Nummern. CVE-2026-16496 brachte den ersten CVSS 10.0 ins Ökosystem — einen Session-Hijacking-Umgehung im zustandsbehafteten Transport des Terraform MCP Servers. Zwei MCP-nahe CVEs gelangten auf CISAs Katalog bekannter ausgenutzter Schwachstellen, die zweite (CVE-2026-59822, CVSS 8.8) mit föderaler Sanierungsfrist am 16. September. Splunk publizierte am 7. Oktober CVE-2026-76286 in seinem eigenen MCP Server, gefixt in 1.2.1. Zenitys AgentCorruption zeigte die Blast-Radius-Größe der Managed-Platform: Ein einzelner Prompt an einen öffentlichen Agenten enthüllte Credentials, die jeden Agenten im AWS-Konto erreichten.
Die Nachfrage ist gemessen. Stackloks Umfrage setzt die Adoption dort an, wo Anbieter einen Markt dimensionieren können: Fast die Hälfte der befragten Softwareunternehmen in Produktion, 19 % im breiten Produktionsbetrieb — vor den Finanzdienste- und Retail-Kohorten, die nach derselben Methode befragt wurden.

Die Scan-Zahlen schließen den Dringlichkeitskreis: 1,467 öffentlich zugängliche MCP-Server ohne jegliche Authentifizierung (korrigierter Trend-Micro-Count, 1,227 auf dem veralteten SSE-Transport) und 82 % Pfad-Traversal-Exposition mit 8,5 % OAuth-Adoption über 2,614 befragte Server (Practical DevSecOps). Radwares CTO David Aviv formulierte die Produkt-These in einem Satz: „Organisationen müssen wissen, welche MCP-Server sie haben, was diese Server aussetzen, welche Agenten auf sie zugreifen und ob diese Interaktionen sicher sind."Dieser Satz ist, nahezu wörtlich, die Inventar- und Drift-Überwachungskontrolle der Checkliste — jetzt als Werbepitch.

Was das Produkt beansprucht — fünf Capability-Gruppen

Die Ankündigung stellt Radware MCP Server Protection neben die bestehenden Produktlinien Agentic AI Protection und LLM Firewall, einsetzbar als Cloud-Dienst (Cloud Application Protection Service) oder cloud-augmentiert on-premises auf Alteon und DefensePro, über Public Cloud, Private Cloud, Kubernetes und hardwarebasierte Rechenzentren. Fünf Capability-Gruppen werden beansprucht:

Sichtbarkeit der MCP-Angriffsfläche — deployte Server, exponierte Werkzeuge und Ressourcen, Agentenaktivität, Nutzungsmuster, Kommunikationsflüsse.
MCP-bewusster Angriffsschutz — Protokollmissbrauch, Authentifizierungsangriffe, Enumeration von Werkzeugen und Ressourcen, unbefugte MCP-Interaktionen, KI-gesteuertes Werkzeugflooding, Denial-of-Service.
Governance — Expositionsbewertung, Schwächeerkennung, Policy-Durchsetzung im Maßstab.
Agentenaktivitätsüberwachung — Agentenidentitäten, Tool-Invocation-Muster, Verhaltensanomalien, Ressourcenverbrauch-Trends.
Deployment-Flexibilität — Cloud-Dienst, oder cloud-augmentiertes Alteon und DefensePro on-premises.

Lesen Sie diese Liste gegen das Angriffsbuch, und die Übereinstimmung ist real aber partiell. Die Schutzgruppe (2) benennt genau die auf der Leitung sichtbaren Angriffsflächen: Protokollmissbrauch, Enumeration, Flooding, Denial-of-Service — die gleichen Klassen, die der MCP-Paradox-Artikel auf das frictionless Design des Protokolls zurückverfolgt. Was in der Liste fehlt, ist ebenso informativ: Nichts beansprucht Werkzeugdefinitions-Driftdetektion (die Deadbugz-Klasse), nichts beansprucht Paketprovenienz, nichts beansprucht die Durchsetzung des Kontextfensters, nichts beansprucht den Kill-Switch. Das sind die Kontrollen, die vor und innerhalb des Moduls leben — und das sind die, die dieser Artikels Matrix als Betreiberpflicht wertet.

Die Splunk-CVE zeigt, warum die Unterscheidung in der Praxis zählt. CVE-2026-76286 ist ein Werkzeugkonfigurationsfehler: Der MCP Server sendete den Plattform-Anmelde-Token des laufenden Benutzers an die URL, die für das Werkzeug konfiguriert war — und wenn ein anderer Benutzer diese URL kontrollierte, fing er den Token ein und handelte wie der Benutzer. Eine Netzwerkkontrolle kann den Ausgangsversuch nachträglich markieren; die Korrektur ist eine Konfigurationsregel, die bereits in der 12-Kontrollen-Basislinie stand — der Server validiert und besitzt jede tool-konfigurierte URL, und der Modul-Exit ist eingegrenzt, bevor der Token sich bewegt (CWE-918, CVSS 5.3, in 1.2.1 gefixt). Detektion am Rand und Durchsetzung in der Konfiguration sind zwei verschiedene Kontrollen, und nur eine von beiden verhindert, dass der Token das System verlässt.

Der Buy-vs-Build-Test mit 12 Kontrollen

Die untenstehende Matrix ist das Arbeitswerkstück des Artikels. Der Status wird gegen die fünf angekündigten Capability-Gruppen ermittelt: Schließt bedeutet, dass die angekündigte Capability die Angriffsklasse des Kontrollpunkts am Netzwerkrand deckt; Teilweise bedeutet, dass das Produkt die Fläche sieht oder erkennt, während Durchsetzung, Lebenszyklus oder die autoritative Aufzeichnung beim Betreiber bleibt; Nicht abgedeckt bedeutet, dass die Fläche des Kontrollpunkts für ein Netzwerkschicht-Tool konstruktionsbedingt unsichtbar ist — nicht unbedingt der Schuld eines bestimmten Produkts.

#	Kontrolle	Was das Produkt beansprucht zu decken	Status	Was bei Ihnen bleibt
1	SSE → Streamable HTTP Migration	Inventar markiert Server mit veraltetem SSE	Teilweise	Die Migration selbst — ein Architekturwechsel, keine Filterregel
2	Netzwerkisolation und Origin-Validierung	L3–L7-Grenzdurchsetzung (das Heimatgelände des Anbieters)	Schließt	Host/Origin-Validierung innerhalb des SDK bleibt application-layer
3	OAuth 2.1 + OIDC-Durchsetzung	Detektion von Authentifizierungsangriffen, unbefugten Interaktionen	Teilweise	Tokenausstellung, Scopes, RFC 8707-Zielgruppenbindung — Rollout liegt bei Ihnen
4	Agenten-Identitätstrennung	Agenten-Identitätsüberwachung, Verhaltensanomalien	Teilweise	Provisioning, Attestation, Widerrufslebenszyklus (SCIM/SPIFFE) liegt bei Ihnen
5	Tool-poisoning-Scan / Driftdetektion	Protokollmissbrauch und Enumeration auf der Leitung	Teilweise	Scans beim Genehmigungszeitpunkt und Post-Install-`tools/list`-Fingerprinting (Deadbugz-Klasse) bleiben bei Ihnen
6	Signierte Provenienz und AIBOM	—	Nicht abgedeckt	Registry und npm-Lieferkette: Angriffe, die landen, bevor der Server spricht
7	STDIO-Härtung	—	Nicht abgedeckt	localhost-Transport zwischen Client und Subprozess; kein Leitungsverkehr zu inspizieren
8	Rate Limiting (Flooding / DoS)	KI-gesteuertes Toolflooding, Denial-of-Service	Schließt	Modulübergreifende Limits pro Werkzeug und pro Agent jenseits der Grenze
9	Kontextgrenze (OWASP MCP10)	—	Nicht abgedeckt	Was das Modell in der Session liest, sind keine Netzwerkdaten
10	Kill-Switch pro Modul	—	Nicht abgedeckt	Ihr Feature-Flag; ein Netzwerkblock ist die letzte Rettung
11	Auditprotokoll pro Aufruf	Fluss- und Anomalie-Telemetrie am Netzwerkpunkt	Teilweise	Der autoritative unveränderliche pro-Aufruf-JSON — mit Eingabehashes — liegt bei Ihnen
12	Shadow-Server-Detektion	Angriffsflächenerkennung deployter Server	Schließt	Registry-Vetting und Driftpolitik, die „Known-good" definieren

Zwischensumme: 3 schließen, 5 teilweise, 4 nicht abgedeckt. Derselbe Aufbau gilt für jeden Anbieter dieser aufstrebenden Kategorie, denn die Spaltung ist keine Produktgrenze — sie ist eine architektonische Grenze. UpGuards Befund, dass einer von 15 MCP-Servern eine lookalike-Imitation ist, ist für einen Netzwerkgrenzwert unsichtbar, wenn das Imitat auf der npm-Seite liegt; die Deadbugz-Nutzlast kommt in legitimen MCP-Antworten an, die ein Monitor sehen, aber nicht semantisch beurteilen kann; und das Kontextfenster des Modells liegt hinter jeder Grenze, die ein Netzwerkprodukt durchsetzen kann.

Die Matrix in einem Blick: drei Coverage-Banden, die Marktzahlen dahinter, und die RFP-Regel, die das Bild trägt:

Die Teilstücke zu kaufen bleibt rational — wenn Sie ehrlich punkten

Die 5 Teilstücke sind dort, wo Beschaffungsgespräche abdriften. „Detektion von Authentifizierungsangriffen" heißt nicht, dass OAuth 2.1 deployt ist, und Agenten-Identitätsüberwachung heißt nicht, dass Agentenidentitäten widerrufen werden können. Die Teilstücke haben realen Wert — Detektion ohne Durchsetzung ist eine Warnschnur, und ein Netzwerkinventar, das Server ausfindig macht, die Sie nicht registriert haben, ist die schnellste Shadow-MCP-Zählung, die Sie kaufen können. Punkten Sie sie als Detektionsabdeckung, nicht als Kontrollschluss:

Die C1/C3/C4-Teilstücke werden erst dann zu vollen Kontrollen, wenn die eigene Arbeit des Betreibers geschieht — die Transportmigration, das OAuth-Rollout, der Identitätslebenszyklus. Monitoring kann die Sanierungswarteschlange treiben; es kann nicht selbst die Sanierung sein.
C5-Teilstück verdient eine spezifische RFP-Frage, denn es ist die Lücke mit den höchsten Konsequenzen: Kann das Produkt die tools/list-Antworten eines Servers über die Zeit diffen und bei semantischer Drift Alarm schlagen? Die Ankündigung nennt Sichtbarkeit über exponierte Werkzeuge und Ressourcen — sie beansprucht keine Driftdetektion, und Deadbugz ist so gebaut, um jede Prüfung zu schlagen, die vor einem vierten, undifferenzierten Aufruf stehen bleibt.
C11-Teilstück schneidet in beide Richtungen: Netzwerkpunkt-Telemetrie füttert Anomaliedetektion, die das Modul nicht sehen kann. Aber der autoritative Audit-Katalog — Zeitstempel, Agenten-ID, Werkzeug, Eingabehash, Ausgabestatus — muss strukturiert, unveränderlich und unter Ihrer Kontrolle sein. AgentCorruption ist der Gegenbeweis, der den Grund beendet: Nachdem eine Plattform-Standardrolle jeden Agenten im Konto entblößt hatte, konnte „Welcher Agent, welches Werkzeug, wessen Eingabe" nur aus Logs beantwortet werden, die der Betreiber besaß.

Die Buy-vs-Build-Grenze

Vier Regeln fallen aus der Matrix heraus:

Kaufen Sie die Netzwerkschicht, wenn Ihre Exposition auf der Leitung liegt. Flooding, Enumeration, Protokollmissbrauch und eine unbekannte Serverpopulation sind leitungssichtbare Probleme, und ein Anbieter mit DDoS/WAF-väterlicher Genealogie operiert sie als Dienst. Wenn Sie multitenant-, multiteam-Agentenbestände auf geteilter Infrastruktur betreiben, ist diese Schicht vermutlich die Kernkompetenz eines anderen.
Besitzen Sie die vier Kontrollen der Anwendungsschicht unabhängig vom Kauf. Provenienz (C6), STDIO-Härtung (C7), Kontextabgrenzung (C9) und der Kill-Switch (C10) stehen diese Woche auf keinem Netzwerk-Anbietern auf der Beanspruchungsliste und sind keine als Produktlinie kaufbare Sorte — sie sind Eigenschaften des Modulbauens und -betreibens. Der MCP Module Code Standard ist die Build-seitige Referenz, um sie im Modul selbst durchsetzbar zu machen.
Setzen Sie die 12 Kontrollen als RFP ein. Fordern Sie von jedem potenziellen MCP-Sicherheitsanbieter Evidenz gegen die Matrix, keine Behauptungen: eine Driftdetektionsdemo gegen das Deadbugz-Muster, einen Probe-Auditkatalog passend zu Ihrem Schema, und die exakte Reichweite von „Governance" — Durchsetzung über was, wo durchgesetzt. Was der Anbieter nachweist, schließt; was er nicht kann, bleibt auf Ihrer Baulliste.
Die Build-Hälfte hat eine freie Referenz. Das Microsoft Agent Governance Toolkit liefert 10/10 OWASP-MCP-Top-10-Abdeckung (7 vollständig, 3 teilweise mit Roadmap) als Open-Source-Runtime — die nichtkommerzielle Ergänzung eines kommerziellen Perimeters. Das Bewertungssystem der Checkliste (12/12 produktionstauglich; unter 8 nicht in Produktion exponieren) ist die Annahmeschwelle für beide Hälften.

Das Muster verallgemeinert sich jenseits von Radware: Die Black-Hat-2026-Welle brachte bereits Shadow-Server-Erkennung (Cyera Agent Guardian), Identitätsgovernance (SailPoint) und Netzwerkschicht-Monitoring (Check Point AI Network Firewall) — abgedeckt im Update-Log der Eltern-Checkliste — und Gateway-Anbieter wie TrueFoundry tragen die Governance-Hälfte. Radwares Eintritt setzt einen börsennotierten Anbieter hinter das zweckgebaute Produkt. Die Konvergenz der Kategorie ist von nun an des Marktes Arbeit; die vier Kontrollen, die ein Netzwerkprodukt nicht sehen kann, bleiben beim Betreiber.