Also habe ich stattdessen meinen Agenten gefragt …

Evo weiß bereits, welche KI-Assets eure Teams in eure Repositories eingebunden haben, welche MCP-Server und Skills sich auf den Rechnern eurer Entwickler befinden, welche davon ein Risiko darstellen und gegen welche Richtlinien sie verstoßen. Der Zugriff darauf war mit Aufwand verbunden: Ihr musstet das Tool verlassen, in dem ihr gerade arbeitet, eine Benutzeroberfläche filtern, eine CSV-Datei exportieren und jedes Mal, wenn ihr sie benötigt habt, das Diagramm neu erstellen, das ihr im letzten Quartal erstellt habt.

Heute kündigen wir den Evo MCP server an, der jede dieser Antworten nur eine Frage entfernt verfügbar macht – innerhalb des Agent-Harness, in dem ihr ohnehin arbeitet. Also habe ich stattdessen meinen Agenten gefragt.

Play Video: So I asked my agent instead… - video 1

Womit verbindet sich der Evo MCP server?

Mit dem Evo MCP server könnt ihr KI-Assets in euren Repositories und auf den Rechnern eurer Entwickler sowie die zugehörigen Risikodaten, eure Richtlinien und offenen Verstöße entdecken. Die Einrichtung ist in unserer Dokumentation

beschrieben. Verbindung über Cursor:

1{
2  "mcpServers": {
3    "Evo MCP": {
4      "url": "https://evo.snyk.io/mcp"
5    }
6  }
7}

Verbindung über Claude Code:

1claude mcp add --scope user --transport http evo https://evo.snyk.io/mcp/

Das ist die gesamte Installation. Es handelt sich um einen Remote-Server, daher wird nichts auf eurem Rechner abgelegt, und er hat keinen Zugriff auf euer Dateisystem.

Der MCP Server unterstützt Folgendes:

• Inventar. Die in eurer Umgebung entdeckten KI-Assets mit ihrer bewerteten Risikostufe.

• Richtlinien und Probleme. Die Regeln für die KI-Nutzung und die Probleme, die entstehen, wenn Assets gegen sie verstoßen.

• Informationen. Wie sich eure KI-Sicherheitslage im Laufe der Zeit verändert.

Einen KI-Asset-Bericht mit dem Evo-MCP-Server erstellen

Um Evo MCP zu verwenden, habe ich zuerst den Umfang festgelegt. Ich fragte: „Wie viele KI-Assets haben wir, aufgeschlüsselt nach Typ und Quelle? Als Antwort erhielt ich eine Übersicht über unsere Umgebung: Modelle, Agenten, MCP-Server, Skills, Repositories und Rechner von Entwicklern.

Die Quelle ist besonders interessant. Evo unterscheidet, was in einem Repository referenziert wird und was auf einem Rechner eines Entwicklers konfiguriert ist, und teilt euch mit, um welchen Rechner es sich handelt. Die Frage lautet also nicht nur, welche MCP-Server und Skills in eurer Organisation existieren, sondern auch, auf wessen Laptop sich die einzelnen befinden. Diese Ansicht pro Rechner ist aus einem Dashboard-Export nur schwer zu erhalten. Sie verwandelt einen riskanten Server von einem Listeneintrag in einen benannten Rechner, für den jemand verantwortlich ist.

Dann schränkte ich die Abfrage ein: „Ich möchte Modelle nach Anbieter und Herkunftsland gruppiert sehen, aufgeschlüsselt nach Lizenztyp und danach, ob sie selbst gehostet werden können, sowie offene Verstöße, gruppiert nach Richtlinie und Schweregrad.“

Schließlich kam der Teil, für den ich normalerweise einen ganzen Nachmittag verlieren würde: „Erstelle mir daraus ein Dashboard mit einem Diagramm für jeden Abschnitt. Es wurde aus den vier bereits in der Sitzung vorhandenen Ergebnissen zusammengestellt, ohne erneut Abfragen auszuführen. Das bedeutet, dass ich es jederzeit neu erstellen lassen kann.

Eine Evo-Richtlinie auf Grundlage eures tatsächlichen Inventars verfassen

Ihr könnt den MCP server verwenden, um eine Richtlinie auf Grundlage eures Inventars zu erstellen – ausgehend von einer Frage, die ich überprüfen konnte: Wie viele Skills in unserer Umgebung erreichen beim Umgang mit unsicheren Zugangsdaten einen Wert von 500 oder höher?

Anschließend bat ich darum, diese Skills nach ihrem Wert sortiert anzuzeigen. Danach bat ich Evo, eine Richtlinie zu erstellen, um Skills in meiner Umgebung zu identifizieren, die beim Umgang mit unsicheren Zugangsdaten einen Wert von 500 oder höher erreichen – mit passenden Hinweisen zur Behebung. Es wurden dieselben Verstöße zurückgegeben, die ich zuvor abgefragt hatte. Vorhersage und Ergebnis stimmten überein – genau darum geht es, erst die Umgebung abzufragen, bevor man die Regel verfasst.

Evo-Verstöße in Tickets umwandeln – eines pro Team

Ich rief die offenen Verstöße für eine Richtlinie ab. Jeder enthielt das betroffene Asset, den Standort dieses Assets und die Hinweise der Richtlinie zur Behebung. Dann bat ich darum, sie nach Repository zu gruppieren, denn ein Ticket pro Verstoß ist der Grund, warum Sicherheitsarbeit ignoriert wird, während ein Ticket pro verantwortlichem Team dafür sorgt, dass sie erledigt wird. Nachdem sie gruppiert waren, bat ich darum, die Tickets zu erstellen – mit der Asset-Liste und den Hinweisen zur Behebung bereits in jeder Beschreibung.

Dieser letzte Schritt lief über einen Ticketing-MCP-Server, der in meinem Client bereits neben dem Evo MCP Server konfiguriert war. Snyk stellt diese Server weder bereit noch unterstützt es sie. Was der Ablauf leisten kann, hängt von den Berechtigungen ab, die ihr eurem Ticketing-MCP-Server wie Jira oder ServiceNow erteilt habt. Die von Evo erkannten Probleme wurden nun zu Aktionen in euren Systemen, ohne dass dafür eine Integration erstellt werden musste.

So wird der Evo MCP server abgesichert

Alles oben Beschriebene setzt voraus, dass ein Agent eure Sicherheitsdaten abfragen und ändern darf – genau die Art von Zugriff, die Evo prüfen soll. Der Fehler, den ich von einem Sprachmodell vor einem Inventar erwartet hatte, war eine selbstbewusst vorgetragene falsche Zahl. Drei Einschränkungen verhindern das.

1. Er läuft mit euren Berechtigungen

Über OAuth – mit eurer Identität und euren Berechtigungen. Was ihr über den Server tun könnt, entspricht genau dem, was ihr in der Evo-Benutzeroberfläche tun könnt. Von den acht Tools lesen sechs Daten und zwei schreiben Daten. Wenn eure Rolle keine Bearbeitung von Richtlinien erlaubt, werden euch die beiden Schreib-Tools nicht angezeigt.

2. Ein Schreibvorgang erfordert eine echte Genehmigung.

Wenn ein Agent versucht, eine Richtlinie zu erstellen oder zu aktualisieren, zeigt Evo die Änderung in einer Vorschau an und sendet eine Genehmigungsanfrage an euren Client.

3. Der Agent kann euer Schema nicht erraten

Jedes Abfrage-Tool arbeitet mit einem Abfrageschema, das die für euch verfügbaren Felder und ihre Bedeutung exakt zurückgibt. Felder, die ihr nicht abfragen dürft, werden weder zurückgegeben noch im Eingabeschema des Tools aufgeführt.

Fragt einfach danach

Möchtet ihr wissen, wie eure eigene Umgebung innerhalb des Clients aussieht, mit dem ihr bereits arbeitet? Richtet euren Client auf https://evo.snyk.io/mcp aus und fragt nach.