Evo ADS Govern Agent Behavior ist allgemein verfügbar: MCP-Nutzung unter Kontrolle bringen

Heute geben wir die allgemeine Verfügbarkeit von Govern Agent Behavior bekannt. Diese Funktion von Evo Agentic Development Security (ADS) steuert, was KI-Coding-Agenten zur Laufzeit tun dürfen. Den Anfang macht MCP Governance.

Seit der Einführung von Evo ADS im Juni arbeiten wir auf eine einfache Idee hin: Agentic Development birgt Risiken auf drei Ebenen, und jede erfordert eine eigene Form der Kontrolle:

1. Was Agenten nutzen: die MCP-Server, Skills und Tools, die sie einbinden und die erkannt und bewertet werden müssen.

2. Was Agenten generieren: Das muss direkt bei der Erstellung validiert werden.

3. Und was Agenten tun: die Aktionen, die sie ausführen, sobald sie sich zum Handeln entschlossen haben und die in Echtzeit durchgesetzt werden müssen.

Mit Govern Agent Behavior beantwortet Evo ADS diese dritte Frage. MCP Governance ist der erste Anwendungsfall, der dafür verfügbar ist.

MCP Governance gibt Sicherheits- und Plattformteams ganz praktisch die Möglichkeit, alle MCP-Server in ihrer Umgebung zu erkennen, festzulegen, welche davon genutzt werden dürfen, zu sehen, wenn ein Agent gegen diese Richtlinie verstößt, und die MCP-Nutzung bei der Ausführung live zu protokollieren oder zu blockieren – in Claude Code, Cursor, Codex und GitHub Copilot.

Zu steuern, welche Tools ein autonomer Agent aufrufen kann, ist grundlegend. Viele Sicherheitsteams gingen davon aus, dass diese Kontrollmöglichkeit bereits existiert – bis sie danach suchten und nichts fanden. MCP Governance schließt diese Lücke direkt im selben Workflow, in dem die Agent-Supply-Chain erkannt und KI-generierter Code validiert wird, statt als separates, nachträglich angebundenes Tool.

Warum MCP-Governance jetzt wichtig ist

Das Model Context Protocol (MCP) ist ein Standard, über den sich KI-Coding-Agenten über eine gemeinsame Schnittstelle mit externen Tools, Datenquellen und Systemen verbinden können, darunter Repositories, Datenbanken, Cloud-Infrastruktur und interne APIs. Das ist ein wesentlicher Grund dafür, dass Agenten immer weniger wie Autovervollständigung und immer mehr wie Kollegen wirken: Ein Agent mit MCP-Zugriff schlägt nicht nur eine Codezeile vor. Er kann in derselben Sitzung ein Ticketsystem abfragen, Datensätze aus einer Produktionsdatenbank abrufen oder einen internen Dienst aufrufen.

Genau darin liegt auch das Problem. MCP standardisiert, wie Agenten sich mit Tools verbinden, sagt aber nichts darüber aus, welchen Tools vertraut werden sollte oder was ein Agent mit den erreichbaren Tools tun darf. Jeder MCP-Server, mit dem sich ein Agent verbindet, ist funktional ein neues Element Ihrer Software-Supply-Chain. Anders als eine in einem Manifest fixierte Abhängigkeit wird er jedoch oft dynamisch hinzugefügt: Ein Entwickler installiert ihn in wenigen Sekunden, ohne dass ein Prüfprozess dahintersteht.

Diese Angriffsfläche ist nicht hypothetisch und auch nicht neu. Es ist dasselbe Problem mit manipulierten Paketen, nur über einen anderen Zugang. Ein kompromittierter MCP-Server kann lokale Dateien lesen, Zugangsdaten abgreifen oder auf interne Systeme zugreifen, sobald er gestartet wird – noch bevor ein Sicherheitsteam überhaupt von seiner Existenz weiß, geschweige denn ihn prüfen kann. Das Risiko entsteht auf dem Rechner des Entwicklers, genau in dem Moment, in dem der Server aufgerufen wird. Dort muss es also erkannt werden.

Das Ausmaß ist größer, als die meisten Sicherheitsteams annehmen. Eine eigene Analyse von Snyk mit Daten aus fast 10.000 Entwicklerumgebungen ergab 4.524 unterschiedliche MCP-Server im aktiven Einsatz. Auf den am stärksten instrumentierten Rechnern liefen 13 oder mehr gleichzeitig. Mehr als die Hälfte der Entwickler hat bereits aktive MCP-Verbindungen zu Produktions-Tools und -Systemen. Und unsere Analyse der Sicherheitslage dieser Verbindungen ergab: Bei einem von zwölf Entwicklern mit installiertem MCP-Server gab es heute einen bestätigten Befund mit hohem oder kritischem Schweregrad.

In einer herkömmlichen AppSec-Pipeline wird nichts davon erfasst, denn MCP-Server sind weder Artefakte, die in CI gescannt werden, noch Abhängigkeiten, die vor dem Merge geprüft werden. Stattdessen werden sie live zur Laufzeit eingebunden – häufig außerhalb jedes Prozesses, den die Sicherheitsabteilung je zu Gesicht bekommt. Ohne eine Möglichkeit, akzeptable MCP-Server festzulegen und diese Richtlinie durchzusetzen, sobald ein Agent einen Server nutzen will, werden „KI-Agenten einführen“ und „die nicht verwaltete Angriffsfläche vergrößern“ zum selben Vorhaben.

So funktioniert MCP Governance in Evo ADS

MCP Governance schließt diese Lücke und erweitert die Transparenz, die Evo ADS bereits für die Agent-Supply-Chain bietet. Die Funktion umfasst drei Schritte:

1. Ihre Liste in Snyk einpflegen

Sicherheits- und Plattformteams legen fest, welche MCP-Server genehmigt sind. Dafür nutzen sie ein vorhandenes Inventar, eine manuell zusammengestellte Liste oder die Server, die Evo ADS bereits bei der Erkennung erfasst hat. Daraus entsteht die Basisrichtlinie, an der alle Agenten in der gesamten Flotte gemessen werden. Das geht manuell oder einfach per Prompt an Evo im Chat!

2. Nicht richtlinienkonforme Nutzung erkennen

Sobald die Richtlinie eingerichtet ist, überwacht Evo ADS kontinuierlich die MCP-Aktivitäten auf den Rechnern Ihrer Entwickler und zeigt jeden Fall an, in dem ein Agent auf einen Server zugreifen will, der nicht auf der genehmigten Liste steht – ganz gleich, ob es sich um eine einmalige lokale Installation oder ein Muster in der gesamten Flotte handelt. Um von dieser Transparenz zu profitieren, muss nichts blockiert werden. Für viele Teams ist es bereits ein großer Schritt, überhaupt zu erfahren, womit sich ihre Agenten tatsächlich verbinden.

3. Nutzung zur Laufzeit steuern

Hier wird aus Transparenz Kontrolle. Evo ADS kann nicht autorisierte MCP-Nutzung zu Prüfzwecken protokollieren oder direkt am Endgerät vollständig blockieren, genau in dem Moment, in dem ein Agent die Verbindung herstellen will – nicht erst im Nachhinein und nicht abhängig davon, ob der Agent sich an die Vorgaben hält.

MCP Governance läuft überall dort, wo auch Ihre Agenten eingesetzt werden. Die Funktion ist heute für Claude Code, Cursor, Codex und GitHub Copilot verfügbar. Durchgesetzt wird sie über schlanke Hooks, die neben dem Agenten laufen, statt dessen Datenverkehr über einen separaten Proxy oder ein Gateway umzuleiten. Dasselbe Prinzip nutzt Evo ADS auch für das sichere Scannen von Code von Anfang an. Teams müssen also weder die Verbindung ihrer Agenten mit Tools ändern noch neue Infrastruktur bereitstellen oder einen zusätzlichen Fehlerpunkt im Ausführungspfad des Agenten in Kauf nehmen. Die Richtlinie wird zentral verwaltet, die Durchsetzung erfolgt lokal – genau dort, wo die Entscheidung fällt, einen MCP-Server zu nutzen.

Was als Nächstes bei der Steuerung des Agentenverhaltens kommt

Wir bezeichnen dies bewusst als ersten Anwendungsfall und nicht als abgeschlossene Lösung. MCP Governance beantwortet die Frage: „Darf dieser Agent auf dieses Tool zugreifen?“ Das ist eine notwendige, aber nicht die einzige Frage. Ein Agent kann auch dann einen destruktiven Shell-Befehl ausführen oder sensible Daten an einen unzulässigen Ort verschieben, wenn er ausschließlich mit einem genehmigten MCP-Server arbeitet. MCP Governance allein erkennt das nicht.

Genau hier setzt Evo ADS als Nächstes an. In den kommenden Wochen erweitern wir die Durchsetzung über MCP-Allowlisting hinaus, um Aktionen von Agenten abzudecken und zu blockieren. Außerdem stellen wir die MCP-Richtlinie von einer statischen Liste auf eine dynamische Lösung um: Teams können sie dann über das Evo MCP direkt aus einem Git-Repository oder einer Confluence-Seite beziehen. Danach folgt eine risikobasierte Durchsetzung, bei der die Richtlinie das tatsächliche Risiko eines Servers abbildet statt nur zwischen pauschaler Zulassung und Ablehnung zu unterscheiden.

Im weiteren Jahresverlauf erweitern wir die Abdeckung von ADS, um nicht autorisierten Zugriff auf sensible Daten, Schutz vor Prompt Injection und Offenlegung von Geheimnissen durch Agenten zu steuern. Außerdem übertragen wir das mit MCP Governance eingeführte Modell aus Erkennung, Klassifizierung und Durchsetzung auf Agent Skills.

Zu steuern, was Agenten nutzen, ist notwendig. Zu steuern, was sie tun – genau in dem Moment, in dem sie es tun – macht diese Governance wirksam. MCP Governance ist der erste Beleg dafür und ab heute verfügbar.

Möchten Sie MCP Governance in Aktion sehen? Demo vereinbaren oder Evo Agentic Development Security entdecken, um zu erfahren, wie Evo ADS die Nutzung, Aktionen und Ergebnisse von Agenten über den gesamten KI-gestützten Entwicklungszyklus hinweg absichert.