MCP sicher nutzen: Ein Leitfaden zur Governance von KI-Coding-Agenten mit Evo ADS

Als wir bekannt gaben, dass MCP Governance in Evo Agentic Development Security (ADS) allgemein verfügbar ist, kam am häufigsten die praktische Nachfrage: „Klingt gut. Wo fange ich am Montag an?“

Eine berechtigte Frage: In 10.000 Entwicklerumgebungen fand Snyk 4.524 einzigartige, aktiv genutzte MCP-Server. Bei einem von zwölf Entwicklern mit installiertem MCP-Server wurde ein bestätigter Befund mit hohem oder kritischem Schweregrad festgestellt. Die meisten dieser Server wurden innerhalb von Sekunden hinzugefügt – von Entwicklern, die ihren Agenten zu etwas Nützlichem bringen wollten, ohne dass eine Prüfung vorausging.

Unsere Antwort: Mit vier Schritten gelangen Sie von einer ersten Inventarisierung zu Richtlinien, die nur Server mit Risiken blockieren. Evo ADS bewertet MCP-Server jetzt mit einem Risiko-Score. So können Sie risikobasiert steuern – mit oder ohne Allowlist –, anstatt jeden Server manuell zu prüfen oder pauschal zu blockieren und dadurch Entwickler auszubremsen. Alles läuft direkt auf dem Endgerät, auf dem die Agenten ohnehin arbeiten, über schlanke Hooks und ohne Proxy. Ermitteln Sie, was vorhanden ist, legen Sie fest, was akzeptabel ist, beobachten Sie, was Ihre Richtlinie erfasst, und setzen Sie sie sicher durch.

Schritt 1: Ermitteln, was bereits läuft

MCP-Server durchlaufen weder CI noch Abhängigkeitsprüfungen. Ein Entwickler bearbeitet eine Konfigurationsdatei, und schon verfügt sein Agent über neue Tools. Der erste Schritt ist also, herauszufinden, was bereits vorhanden ist. Was Sie nicht sehen, können Sie nicht steuern. Deshalb bietet Evo ADS zwei Ansichten:

• MCP-Server auf Entwicklergeräten: Stellen Sie das Evo ADS-Installationsprogramm in Ihrer gesamten Flotte bereit. Es zeigt, mit welchen MCP-Servern sich Agenten tatsächlich verbinden – einschließlich einmaliger lokaler Installationen, die nie ein Repository berührt haben.

• MCP-Server in Code-Repositories: Evo AI-SPM findet über die SCM-Integration von Snyk MCP-Server, auf die in Ihrem Code verwiesen wird.

Zusammen beantworten diese Ansichten zwei unterschiedliche Fragen: Was ist im Code konfiguriert und was läuft auf den Laptops? Beides ist in der Evo-Benutzeroberfläche unter Inventar → MCP-Server verfügbar.

Sie können auch den Evo MCP Server nutzen, um mit Ihrem eigenen agentischen Workflow auf diese Daten zuzugreifen. So erhalten Sie eine zentrale Ansicht Ihrer MCP-Umgebung, ohne etwas zu blockieren oder Entwickler zu beeinträchtigen. Mit diesem einen Schritt können Sie jetzt eine Frage beantworten, auf die die meisten Sicherheitsteams keine Antwort haben: Mit welchen Systemen verbinden sich unsere Agenten?

Schritt 2: Definieren, was „akzeptabel“ bedeutet

Die Entscheidung, ob Server Nummer 47 in Ordnung ist, sollte keinen Slack-Thread und keine Websuche erfordern. Evo ADS stellt Ihnen die nötigen Informationen zu jedem Server bereit, damit Sie schneller und sicherer zustimmen oder ablehnen können.

Das Inventar prüfen

Ein Server mit hohem Risiko, der weit verbreitet und inoffiziell ist, stellt ein ganz anderes Problem dar als ein Server mit hohem Risiko, der nur auf einem Gerät installiert ist. Jede Zeile beantwortet Fragen, denen Sie sonst mühsam selbst nachgehen müssten: Wer hat diesen Server entwickelt? Wo ist er installiert? Wurde er genehmigt? Und wie hoch ist sein Risiko?

• Server: Name, Herkunft (z. B. NPM), Transport (SSE oder STDIO) und Angabe, ob der Server lokal ist.

• Herkunft des Anbieters: Gibt an, ob der Server offiziell ist. Auch „Unbekannt“ ist ein Hinweis.

• Quelle: Wie oft der Server im Code, auf Geräten und zur Laufzeit vorkommt.

• Allowlist-Status: Zugelassen oder nicht zugelassen.

• Risiko-Score: Ein einheitlicher Score pro Server, nach dem Sie sortieren und filtern können.

• Befunde nach Schweregrad: Anzahl kritischer Befunde sowie solcher mit hohem, mittlerem und niedrigem Schweregrad.

Sortieren Sie nach Risiko-Score und prüfen Sie die Einträge der Reihe nach.

Das Risikoprofil öffnen

Klicken Sie auf einen Server, um die Detailansicht zu öffnen. Im Kopfbereich werden zusätzlich die Authentifizierungsmethoden angezeigt. Drei Karten zeigen, wo der Server zu finden ist: im Code deklariert, auf wie vielen Geräten und wann zuletzt gescannt, sowie wie oft Agenten ihn in den letzten sieben Tagen aufgerufen haben.

Öffnen Sie anschließend den Tab Risikoprofil. Damit erübrigen sich der Slack-Thread und die Websuche.

Bei einem untersuchten Server fand Evo in 8 von 12 Fällen Tool-Beschreibungen mit der Aufforderung „vorherige Anweisungen ignorieren“. Diese Prompt Injection würden Sie nur entdecken, wenn Sie jede Tool-Beschreibung selbst lesen.

Die Scores reichen von 0 bis 1000:

• Niedrig (0 bis 249)

• Mittel (250 bis 499)

• Hoch (500 bis 749)

• Kritisch (750 bis 1000)

Der Tab schlüsselt den Score nach Merkmalen auf, darunter Prompt Injection in Tool-Beschreibungen, destruktive Funktionen und nicht vertrauenswürdige Inhalte. Jedes Merkmal wird mit bis zu 1000 bewertet. Klappen Sie ein Merkmal auf, um eine Beschreibung und die Erklärung „Warum dieses Risiko?“ mit entsprechenden Belegen zu sehen.

Dieser Server stand bereits auf der Allowlist. Jemand hatte ihn genehmigt, trotzdem liegt sein Score bei 931 – eindeutig kritisch. Eine Allowlist dokumentiert eine zu einem bestimmten Zeitpunkt getroffene Entscheidung. Der Risiko-Score zeigt Ihnen, wann diese Entscheidung erneut geprüft werden sollte. Sie können den Server auf dieser Seite auf „Nicht zugelassen“ setzen oder ihn zur Laufzeit blockieren.

So werden Server bewertet

Der MCP-Risiko-Score kombiniert drei Signale: das Verhalten des Servers (die Anweisungen und Tool-Beschreibungen, die er an Agenten sendet), die Vertrauenswürdigkeit (der Ruf seiner URLs und die Identität seiner Betreuer) sowie – bei lokalen Servern mit verfügbarem Quellcode – Implementierung, Wartung und Abhängigkeiten. Eine Einschränkung: Evo kann Server ohne Signatur nicht mit Sicherheit identifizieren. Das betrifft weniger als 20 % der Server, die deshalb keinen Score erhalten. Berücksichtigen Sie sie in Ihrem Prüfprozess.

Ihre Basis festlegen

Die Allowlist dokumentiert, welche MCP-Server Sie genehmigt haben. Für jeden Server gibt es einen Schalter: genehmigt oder nicht. Ändern Sie den Status, erscheint die Entscheidung in der Inventarspalte „Allowlist-Status“ („Zugelassen“ oder „Nicht zugelassen“), sodass alle beim Aufrufen des Inventars denselben Status sehen. In der Detailansicht eines Servers können Sie unter Allowlist anzeigen die vollständige Liste aufrufen.

Beginnen Sie mit dem, dem Sie bereits vertrauen – Sie müssen nicht bei null anfangen. Nutzen Sie ein vorhandenes Inventar, eine kuratierte Liste oder die Server, die Evo ADS bereits ermittelt hat, als Grundlage. Schalten Sie Server im Inventar manuell um oder fragen Sie einfach Evo im Chat.

Prüfen Sie für jeden Kandidaten die Informationen aus dem vorherigen Schritt: die Risikostufe, ob der Anbieter offiziell ist, wie die Authentifizierung erfolgt und – bei hohem oder kritischem Risiko – die Belege unter „Warum dieses Risiko?“. Ein Server mit niedrigem Score, der offiziell ist und Authentifizierung nutzt, ist eine einfache Entscheidung. Bei einem kritischen Server sollten Sie vor der Genehmigung einen guten Grund haben. Ihn abzulehnen, ist völlig in Ordnung.

Denken Sie daran: Die Allowlist dokumentiert Entscheidungen. Sie blockiert selbst nichts. Richtlinien setzen diese Entscheidungen um – darum geht es in den nächsten Schritten.

Schritt 3: Beobachten, bevor Sie blockieren

Wenn Sie die Blockierung gleich am ersten Tag aktivieren, werden Entwickler-Workflows unterbrochen, die Sie noch gar nicht kennen. Im Überwachungsmodus sehen Sie genau, was Ihre Richtlinie blockieren würde, bevor tatsächlich etwas blockiert wird. Erstellen Sie Ihre erste Richtlinie anhand der Vorlage Nicht zugelassene MCP-Server überwachen auf der Richtlinienseite (Richtlinien → Probleme → Richtlinie erstellen). Sie meldet jeden riskanten Server als prüfenswertes Problem – ohne etwas zu blockieren. Entwickler und Agenten können so weiterarbeiten, während Sie eine laufend aktualisierte Liste aller von Ihrer Richtlinie erfassten Server erhalten.

Arbeiten Sie diese Liste anschließend unter Inventar → MCP-Server durch. Nutzen Sie dazu die Zeile und das Risikoprofil, die Sie in Schritt 2 kennengelernt haben. Prüfen Sie bei jedem markierten Server den Score, ob er offiziell ist und wie er sich authentifiziert, sowie die Merkmale, die den Score beeinflusst haben. Entscheiden Sie dann: Genehmigen und zur Allowlist hinzufügen oder ablehnen. Gehen Sie ein bis zwei Wochen lang so vor und achten Sie auf Muster. Ein Server, der einmal auftaucht, ist vielleicht nur eine Randnotiz. Taucht er hingegen auf fünfzig Geräten auf, müssen Sie bewusst eine Entscheidung treffen.

Am Ende der zweiten Woche haben Sie eine Richtlinie, die Ihrer Risikobereitschaft entspricht und anhand Ihrer tatsächlichen Umgebung getestet wurde. Ihr Sicherheits- und Entwicklerteam hat sie in Aktion erlebt, bevor sie jemanden aufhält.

Schritt 4: Durchsetzen – beginnend mit riskanten Servern

Sobald Sie den von der Richtlinie erfassten Ergebnissen vertrauen, aktivieren Sie die Durchsetzung. Die Richtlinienvorlage Nicht zugelassene MCP-Server blockieren (Richtlinien → Richtlinien → Richtlinie erstellen) verhindert, dass Coding-Agenten zur Laufzeit auf dem Endgerät Server aufrufen, die nicht auf Ihrer Allowlist stehen und ein hohes oder kritisches Risiko aufweisen. Entspricht die Vorlage nicht Ihrer Risikobereitschaft, wählen Sie Von Grund auf neu beginnen und erstellen Sie eine benutzerdefinierte Richtlinie nach Ihren eigenen Kriterien.

Die Richtlinie blockiert einen Server nur dann, wenn er nicht auf Ihrer Allowlist steht und zugleich als hohes oder kritisches Risiko eingestuft ist. Alle anderen Server laufen weiterhin im Protokollierungsmodus. Ein Server mit niedrigem Risiko, den noch niemand genehmigt hat, hält also keinen Entwickler auf – und Sie behalten trotzdem einen Audit-Trail. Die Durchsetzung erfolgt außerdem lokal zur Laufzeit auf dem Gerät des Entwicklers, über schlanke Hooks, die neben dem Agenten laufen, statt über einen Proxy oder ein Gateway, das sich in den Datenverkehr einschaltet. Sie legen die Richtlinie einmal zentral fest. Hooks setzen sie auf jedem Gerät genau dann durch, wenn der Agent den Server aufruft – egal ob mit Claude Code, Cursor, Codex oder GitHub Copilot.

MCP sicher nutzen – mit Kontrolle

Sie stellen also am Montag das Installationsprogramm bereit und verbinden Ihr SCM. Am Freitag haben Sie ein Inventar und eine vorbereitete Allowlist. Mit Evo ADS können Sie MCP nutzen und trotzdem wissen, womit sich Ihre Agenten verbinden, schnell Entscheidungen treffen und riskante Server blockieren. Das ist der erste Anwendungsfall unter Agentenverhalten steuern – und wir fangen gerade erst an: Im weiteren Jahresverlauf wird dasselbe Modell aus Ermitteln, Klassifizieren und Durchsetzen auch auf Agenten-Skills, den Zugriff auf sensible Daten, den Schutz vor Prompt Injection und die Offenlegung von Secrets ausgeweitet.

Möchten Sie sehen, womit sich Ihre Agenten verbinden? Demo vereinbaren oder Evo Agentic Development Security entdecken.