42Crunch schützt jeden MCP-Server innerhalb eines wiederholbaren, skalierbaren Rahmenwerks: entdeckt, auditiert, bewertet, gescannt und blockiert, bevor er sich seinen Platz in der Produktion verdient. So bildet dieser Workflow jede der zehn Risikokategorien des OWASP MCP Top 10 ab.
MCP hat für KI-Agenten das getan, was OpenAPI vor einem Jahrzehnt für Web-APIs getan hat: Es gab einem fragmentierten Ökosystem einen gemeinsamen Contract. Ein Agent braucht keinen individuellen Klebecode mehr für jedes Tool, das er aufruft — er zeigt einfach auf einen MCP-Server, liest die Tool-Beschreibungen und beginnt, sie aufzurufen. Genau diese Bequemlichkeit ist das Problem: Es gibt kein Schema-Validierungs-Gate, keine standardmäßige Authentifizierungspflicht und keine eingebaute Möglichkeit, eine legitime Tool-Beschreibung von einer zu unterscheiden, die ein Angreifer umgeschrieben hat, um eine neue Anweisung einzuschmuggeln. Der OWASP MCP Top 10 ist der erste Versuch der Community, genau zu katalogisieren, wie dieses Vertrauen missbraucht wird.
Jede Kategorie wird vom MCP-Sicherheits-Workflow von 42Crunch — Contract, Audit, Security Quality Gate, Scan und Findings — erkannt und durchgesetzt.
Hartcodierte Zugangsdaten oder langlebige Tokens verbleiben im Modellgedächtnis, in Protokoll-Logs oder Debug-Traces und werden über Prompt Injection herausgezogen.
Jeder entdeckte Server wird zu einem versionierten Contract, sodass Zugangsdaten oder langlebige Tokens, die in Tool-Beschreibungen oder Debug-Ausgaben auftauchen, als datierter, zuordenbarer Befund erscheinen — nicht als etwas, das in einem Chat-Transkript vergraben ist.
Locker abgegrenzte oder temporäre Berechtigungen weiten sich mit der Zeit aus und erlauben einem Agenten, weit mehr zu tun, als jemals vorgesehen war.
Die Audit-Engine bewertet die im MCP Contract deklarierten Scopes anhand struktureller Best Practices, und die Security Quality Gate blockiert jeden Server, dessen Berechtigungen sich nicht rechtfertigen lassen, bevor er in die Produktion gelangt.
Ein Angreifer kompromittiert ein Tool, dessen Beschreibung oder dessen Ausgabe — Rug Pulls, Schema Poisoning und Tool Shadowing fallen alle in diese Kategorie.
Ein dedizierter PromptDefense-Analyzer scannt jede Tool-Beschreibung auf fehlende Schutzmechanismen gegen Instruction Override, und das Fehlen von Nachrichtensignierung — eine strukturelle Voraussetzung für Rug Pulls und Tool Shadowing — wird auf Serverebene gemeldet.
Ein kompromittierter Open-Source-Connector oder ein Plug-in verändert das Verhalten des Agenten oder öffnet eine Backdoor auf Ausführungsebene.
Jede Abhängigkeit, die ein MCP-Server einbindet — jeder Connector, jedes Plug-in — ist Teil der auditierten Angriffsfläche. Eine Abhängigkeit, die das Verhalten eines Tools ändert oder neue Ausführungspfade einführt, erscheint als versionsübergreifende Änderung in den Audit- und Scan-Ergebnissen.
Ein Agent erstellt und führt Shell-Befehle, API-Aufrufe oder Code aus nicht vertrauenswürdigen Eingaben aus, ohne Validierung.
Scan meldet jedes Tool, dessen Beschreibung darauf hindeutet, dass es Befehle aus benutzerseitig bereitgestellten Eingaben konstruiert oder ausführt, als Befund für eine fehlende Schutzmaßnahme — mit der genauen Abhilfemaßnahme, um die Lücke zu schließen.
Bösartige Anweisungen, die in abgerufenem Kontext eingebettet sind, kapern das Ziel des Agenten — ein sekundärer Anweisungskanal, den der Nutzer nie zu sehen bekommt.
Ein Befund wie „keine Instruction-Override-Abwehr gefunden" ist ein direkter, testbarer Indikator für Intent Flow Subversion: Wenn eine Tool-Beschreibung das Modell nicht explizit anweist, Versuche zur Umgehung seiner Vorgaben zurückzuweisen, meldet Scan dies, bevor der Server ausgeliefert wird.
Server, Tools oder Agenten prüfen die Identität nicht ordnungsgemäß oder setzen die Zugriffskontrolle innerhalb eines Multi-Agenten-Austauschs nicht durch.
Die Audit-Engine bewertet den Contract anhand verbindlicher Authentifizierungsmuster, und die Security Quality Gate setzt diesen Schwellenwert als Release-Kriterium durch statt als optionale Empfehlung.
Fehlende Protokolle zu Tool-Aufrufen und Kontextänderungen machen Untersuchungen und Incident Response nahezu unmöglich.
Jeder Befund ist ein dauerhafter, filterbarer und mit Zeitstempel versehener Datensatz, sodass eine Regression zwischen dem letzten und dem aktuellen Release als konkreter, zuordenbarer Diff sichtbar wird — nicht als Überraschung, die erst während eines Incidents entdeckt wird.
Nicht genehmigte, unbeaufsichtigte MCP-Instanzen, die außerhalb der Governance aufgesetzt werden, oft mit Standard-Zugangsdaten.
Kontinuierliche Discovery findet MCP-Server automatisch im gesamten Unternehmen und erstellt für jeden gefundenen Server einen Contract — Shadow Server werden so vom blinden Fleck zu einem erfassten Inventar, sobald sie auftauchen.
Gemeinsam genutzte oder unzureichend abgegrenzte Kontextfenster lassen die Daten eines Nutzers oder Agenten in die Session eines anderen durchsickern.
Die deklarierten Ein- und Ausgaben jedes Tools werden im Contract erfasst und bei jedem Audit erneut geprüft, sodass ein Tool, das still und leise beginnt, einen breiteren Kontextzugriff anzufordern als seine vorherige Version, als Diff auffällt — nicht als Überraschung.
Indem 42Crunch Tool-Definitionen, Eingaben, Zugangsdaten, Berechtigungen, Isolation und delegierte Identität gegen den freigegebenen MCP Contract validiert, blockiert 42Crunch unsichere MCP-Server vor der Verbindung und erkennt Drift nach dem Deployment — einschließlich übermäßiger Berechtigungen (überprivilegierte Tools, die gegen das Least-Privilege-Prinzip verstoßen, wobei ein einziger Verstoß alles kompromittiert), unzureichender Isolation (Cross-Tenant-Datenlecks, gemeinsam genutzte Service-Konten, nicht sandboxed ausgeführter Code) und Confused-Deputy-Angriffen, bei denen Token-Passthrough einen Server dazu verleitet, die eigenen Rechte eines Nutzers zu missbrauchen.
Ein von der Community getragener Katalog, derzeit in Beta unter der Projektleitung von Vandana Verma Sehgal, mit den zehn kritischsten, für das Model Context Protocol spezifischen Risikokategorien — von Token Mismanagement und Tool Poisoning bis hin zu Shadow Servern und übermäßigem Context Sharing. Er ist das MCP-Pendant zum seit langem etablierten OWASP API Security Top 10.
Sie befindet sich in Beta und wird aktiv von der OWASP-Community gepflegt. 42Crunch verfolgt das Projekt direkt und aktualisiert seine Audit-, Scan- und Security-Quality-Gate-Prüfungen, sobald die Kategorien verfeinert werden, damit die Abdeckung dem Standard nie hinterherhinkt.
Beides. Mehrere Kategorien — Command Injection, unzureichende Authentifizierung, Shadow Server, Supply-Chain-Manipulation — sind Risiken für den Server selbst, ausnutzbar, ohne jemals das Modell zu manipulieren. Die Audit- und Scan-Engines von 42Crunch bewerten den Server als eigenständige Angriffsfläche, nicht nur als Vektor für die Manipulation des Agenten.
Jeder Server erhält von den Audit- und Scan-Engines einen deterministischen Score und eine Bewertung, aufgeschlüsselt nach Kategorie. Derselbe Server, zweimal bewertet, liefert denselben Score und dieselben Befunde — reproduzierbar, keine Schätzung — und jeder Befund enthält eine konkrete, testbare Abhilfemaßnahme.
Ja. Die Security Quality Gate erzwingt in CI/CD einen akzeptablen Mindest-Score und verhindert, dass ein Server unterhalb dieses Schwellenwerts in die Produktion gelangt — ohne manuelle Umgehungsmöglichkeit.
Gleiche Disziplin, neues Artefakt. 42Crunch wendet seit Jahren Contract-first-Sicherheit auf REST- und GraphQL-APIs an; der OWASP-MCP-Top-10-Workflow ist dasselbe Modell — discover, audit, gate, scan, evidence — nur gerichtet auf MCP-Server und deren natürlichsprachliche Tool-Beschreibungen statt auf OpenAPI-Pfade und -Parameter.
Richten Sie 42Crunch auf einen beliebigen MCP-Server und erhalten Sie in unter 60 Sekunden einen Bericht, der gegen alle zehn OWASP-MCP-Top-10-Kategorien bewertet ist. Kein Agent, keine Bereitstellung, keine Verpflichtung erforderlich.