Das Risiko von KI-Modellen hängt davon ab, worauf sie zugreifen können

Neue Snyk-Studien zu Tausenden gescannten Unternehmensumgebungen zeigen, warum ein hoher Modellrisikoscore der Beginn der Triage ist – und wie Sicherheitsteams darauf reagieren sollten.

Stellen Sie sich zwei Anwendungen vor, die dasselbe KI-Modell verwenden. Eine fasst Besprechungsnotizen zusammen, die andere nutzt einen Agenten, um Kundeninformationen abzufragen und Geschäftsabläufe auszulösen. Das Modell könnte in beiden Anwendungen dieselben Ergebnisse bei adversarialen Tests erzielen. Doch die Folgen eines Fehlers könnten sehr unterschiedlich sein – ebenso wie die Art des Fehlers, die relevant ist. Bei einer Anwendung zum Zusammenfassen von Besprechungen muss geklärt werden, ob sich das Modell zu irreführenden Ausgaben verleiten lässt. Bei einem Agenten für Kundendaten muss geprüft werden, ob er dazu gebracht werden kann, Daten preiszugeben oder nicht autorisierte Aktionen auszuführen. Deshalb ist ein Modellscore für jede Angriffsart hilfreicher als ein Durchschnittswert über alle Angriffsarten hinweg.

Dieser Unterschied steht im Mittelpunkt von Snyks State of Agentic AI Adoption 2026, Volume III. Die ersten beiden Ausgaben haben gezeigt, dass Unternehmens-KI ein vernetzter Softwarebestand ist und nicht nur eine Sammlung von Modellen. Diese neue Analyse ergänzt Risikoscores für identifizierbare Modelle und stellt die Frage, auf die Sicherheitsverantwortliche eine Antwort brauchen: Welche Ergebnisse erfordern Maßnahmen, und welche Maßnahmen senken das Risiko?

Fast die Hälfte aller KI-Modellbestände enthält einen Verweis mit kritischem Score

So funktionieren die Scores: Snyk testet jedes Modell anhand von 29 Angreiferzielen, etwa dem Abgreifen personenbezogener Daten oder dem Ausführen von Befehlen, und bewertet jedes Ziel mit 0 bis 1.000 Punkten. Der Score kombiniert die Häufigkeit erfolgreicher Angriffe mit dem möglichen Schaden des jeweiligen Ziels. Ab 500 gilt ein Score als hoch, ab 750 als kritisch. Die Modelle werden mit einer grundlegenden Schutzvorkehrung getestet. Die Scores beschreiben daher ein geschütztes Modell, kein ungeschütztes.

Von 1.693 Umgebungen mit mindestens einem erkannten Modellbezeichner verweisen 74,5 % auf ein Modell, das bei mindestens einem Angreiferziel einen hohen Score (500+) erzielt hat. 49,2 % verweisen auf ein Modell mit kritischem Score (750+). In dieser Stichprobe entfielen die Ergebnisse im kritischen Bereich auf das Abgreifen personenbezogener Daten und die Befehlsausführung.

Diese Zahlen sollten Anlass zu einer Untersuchung geben, nicht zu Panik. In der Studie werden in Code gefundene Modellbezeichner mit Ergebnissen adversarialer Tests abgeglichen. Sie belegt nicht, dass jedes Modell in der Produktion aktiv ist, ein bestimmtes Tool oder Dataset zugänglich ist oder ein Angriff in der Anwendung eines Unternehmens erfolgreich war.

Auch die Abdeckung spricht für eine präzise Einordnung: Für nur 37,5 % der gefundenen Modellvorkommen liegt ein zugeordneter Risikoscore vor. Bei etwa 17 % der Umgebungen mit Modellen wurde kein Modell bewertet. Behandeln Sie nicht bewertete Verweise und Verweise ohne Versionsangabe als offene Fragen, die weiterhin geprüft werden müssen.

Die Größe des Bestands verändert die Anzahl der Ergebnisse, nicht aber deren Verteilung. Die Wahrscheinlichkeit, mindestens ein Modell mit hohem Score zu finden, steigt von 34,6 % bei den kleinsten Modellbeständen auf 100 % bei den größten. Der Anteil der Modellvorkommen, die mit Modellen mit hohem Score verknüpft sind, bleibt jedoch bei jeder Bestandsgröße zwischen 21 % und 25 % und über acht Branchen hinweg zwischen 18,9 % und 25,5 %. Nutzen Sie die Anzahl, um den Umfang des Prüfungsrückstands zu bestimmen, und den Anteil, um die Modellauswahl mit der von vergleichbaren Unternehmen abzugleichen. Keine der beiden Zahlen zeigt, was eine aktive Anwendung einem Modell tatsächlich ermöglicht.

Bei jedem Modell mit hohem Score lauten die ersten Fragen: Ist es aktiv, worauf kann es zugreifen und was passiert, wenn es versagt?

Agenten und MCP-Server machen den Bereitstellungskontext unverzichtbar

Ein Modell kann für sich allein eine unsichere Antwort erzeugen. Ist es mit Tools, Daten und Arbeitsabläufen verbunden, kann es möglicherweise auch auf Grundlage dieser Antwort handeln. Darin liegt der Unterschied zwischen der getesteten Angriffsanfälligkeit eines Modells und der Reichweite des Systems, in das es eingebettet ist.

Von den 1.051 US-Konten mit einem MCP-Verweis zeigen 744 (70,8 %) Anzeichen dafür, dass mit einem SDK ein MCP-Server entwickelt wird. Bei den übrigen gibt es lediglich Hinweise auf Client-Verbindungen oder Konfigurationsverweise. Einen Server zu entwickeln, zu konfigurieren und zu betreiben sind drei unterschiedliche Signale. Nur eine Laufzeitprüfung bestätigt Letzteres.

Bei den Umgebungen ohne erkannte Agenten- oder MCP-Signale verweisen 49,1 % auf ein Modell mit hohem Score. Bei den Umgebungen mit einem Agentenindikator und Code zum Erstellen eines MCP-Servers sind es 96,6 %.

Die zweite Gruppe nutzt außerdem deutlich mehr Modelle im Bestand: Der Median liegt bei 104 statt 4. Betrachtet man Umgebungen mit 5 bis 19 Modellen, verringert sich der Abstand von 47 auf 26 Prozentpunkte (62,1 % gegenüber 87,8 %). Das Muster zeigt einen Zusammenhang. Agenten und MCP-Server verändern, wie weit die Auswirkungen eines Modell-Scores reichen können – deshalb sollte man sich diese zuerst ansehen.

Für Sicherheitsteams ist der nächste Schritt die Überprüfung: Stellen Sie fest, welche Agenten und MCP-Server aktiv sind, welche Tools sie bereitstellen, welche Daten sie abrufen können und welche Genehmigungen zwischen der Ausgabe eines Modells und einer folgenreichen Aktion erforderlich sind. Ein Modellscore kann diese Fragen nicht beantworten.

Nicht jede KI-Schwachstelle lässt sich mit derselben Maßnahme beheben

Sobald Sie wissen, worauf ein Modell zugreifen kann, stellt sich die nächste Frage: Welche Maßnahme passt zum jeweiligen Fehler? Ein sinnvolles Programm für Modellrisiken beschränkt sich nicht auf Schweregradstufen. Es fragt, welches Angreiferziel für die Anwendung relevant ist und ob ein anderes Modell bei diesem Ziel deutlich besser abschneidet. Die Antwort führt zu zwei Ansätzen:

• Wann ein Modellwechsel helfen kann. Bei der Befehlsausführung erzielten 77 % der getesteten Modelle einen Score von null, während das schlechteste Modell 834 erreichte. Bei Code-Backdoors lag der Score bei 57 % der Modelle bei null, während der höchste Wert 695 betrug.

• Wann Anwendungskontrollen den Unterschied machen. Bei Desinformation erreichte der Median der Modelle den höchstmöglichen Score. Bei rassistischer Voreingenommenheit erzielte keines der getesteten Modelle einen Score von null.

Ein Wert von null bedeutet, dass bei diesem Test kein Angriff erfolgreich war. Ein Modell, das bei einem Ziel gut abschneidet, kann bei einem anderen schlecht abschneiden. Prüfen Sie daher jeden Ersatz anhand aller Ziele, von denen die Arbeitslast abhängt. Wenn sich die Ergebnisse häufen, muss die Anwendung geschützt werden: Beschränken Sie Zugriffe, validieren Sie Ausgaben, verlangen Sie Genehmigungen, überwachen Sie die Nutzung und scannen Sie generierten Code und Abhängigkeiten, bevor diese in einen Build gelangen.

Auch Schwellenwerte für Warnmeldungen zeigen nur einen Teil des Bildes: Bei 18 der 29 Angreiferziele kann der Standard-Schwellenwert von 500 nie erreicht werden, weil der mögliche Schaden den Höchstscore unter diesem Wert begrenzt. Diese Fehler sind auch dann relevant, wenn die Warteschlange für Warnmeldungen leer ist.

Unterscheiden sich die Modelle, testen Sie einen Ersatz. Tun sie das nicht, beschränken Sie die Zugriffsrechte und Befugnisse der Anwendung.

Bei welchen Zielen hilft ein Modellwechsel tatsächlich, und welche lösen niemals eine Warnmeldung aus? Sehen Sie sich alle 29 in der Grafik an. Den vollständigen Bericht herunterladen.

Ihre Liste zugelassener Modelle sollte möglicherweise überprüft werden

Bekanntheit, Lizenz und Preis sind kein Ersatz dafür, das konkrete Modell zu prüfen.

Modelle mit geringeren Fähigkeiten sollten zuerst überprüft werden

In der bewerteten Gruppe schnitten Modelle mit geringeren Fähigkeiten bei der Preisgabe personenbezogener Daten, der Umgehung von Entscheidungen und der Generierung unsicheren Codes schlechter ab. Bei der Umgehung von Entscheidungen sank der Durchschnitt von 501 bei Modellen mit weniger als 130 Punkten im Epoch Capabilities Index (ECI) auf 45 bei Modellen mit mindestens 150 ECI-Punkten. Diese Modelle mit den geringsten Fähigkeiten machen etwa ein Drittel der Modellvorkommen im bewerteten Vergleich aus. Die Erkenntnis geht also weit über einen Sonderfall hinaus.

Fähigkeiten sind ein anderes Maß als Sicherheit. Auch ein leistungsfähigeres Modell muss für die jeweilige Aufgabe getestet werden. Überprüfen Sie zugelassene Versionen mit geringeren Fähigkeiten erneut und testen Sie Alternativen desselben Anbieters, den Sie bereits nutzen. Denn das Muster zeigt sich auch innerhalb der Modellreihen einzelner Anbieter.

Der Anbieter ist ein nützliches erstes Signal, sagt im Spitzenbereich jedoch weniger aus. Bei Modellen im mittleren Leistungsbereich liegen die Anbieterdurchschnitte zwischen 113 und 356 Punkten. Bei den leistungsfähigsten Modellen beträgt der Abstand zwischen drei führenden Anbietern nur 22 Punkte. Wenn Ihre Liste zugelassener Modelle stark auf einen Anbieter ausgerichtet ist, zeigt der vollständige Bericht, wo dessen Modelle gut und wo sie weniger gut abschneiden. Sechs Anbieter werden für sieben Angriffsarten direkt miteinander verglichen – vom Datenabfluss bis zur Manipulation von Ausgaben. In dieser Stichprobe boten höhere Preisklassen keinen durchgängigen Sicherheitsvorteil. Das liegt vor allem daran, dass die hochpreisige Klasse überwiegend aus älteren Modellen mit geringeren Fähigkeiten besteht.

Open-Weight-Modelle und die Herkunft ihrer Trainingsdaten

Der Bericht stellt bei den 16 bewerteten Open-Weight-Modellen im Durchschnitt höhere Scores für die Preisgabe personenbezogener Daten fest als bei proprietären Modellen: 562 gegenüber 274. Die Stichprobe ist klein. Betrachten Sie den Unterschied daher als Signal, das bei Arbeitslasten mit personenbezogenen Daten untersucht werden sollte.

Auch bei der Transparenz zur Herkunft zeigen sich Unterschiede. Bei 904 von 1.693 Umgebungen mit Modellen fanden Scans keine Informationen zur Herkunft der Trainingsdaten. Das liegt vor allem daran, dass Anbieter proprietärer Modelle ihre Trainingsdatensätze nicht veröffentlichen. Die verfügbaren Nachweise hängen daher vom Modelltyp ab: Bitten Sie Anbieter proprietärer Modelle um dokumentierte Zusicherungen und prüfen Sie die veröffentlichten Informationen zur Herkunft der Datasets von Open-Weight-Modellen.

Vier Maßnahmen für Sicherheitsverantwortliche

1. Erfassen Sie unbekannte Aspekte und bewerten Sie sie: Dokumentieren Sie Modellbezeichner, Versionen, Verantwortliche, aktive Verwendungszwecke, Agenten, Tools, MCP-Server und verfügbare Informationen zur Herkunft. Behalten Sie nicht zugeordnete Modelle im Blick und stufen Sie sie nicht stillschweigend als risikoarm ein.

2. Überprüfen Sie die Reichweite: Stellen Sie für jedes aktive Modell den Laufzeitpfad zu sensiblen Daten, Zugangsdaten, Tools und nachgelagerten Aktionen fest. Unterscheiden Sie zwischen Code zum Erstellen eines Servers, Konfiguration und tatsächlichen Verbindungen.

3. Richten Sie Abhilfemaßnahmen auf konkrete Ziele aus: Ordnen Sie Fehler nach ihren geschäftlichen Folgen. Testen Sie konkret benannte Ersatzmodelle, wenn die Ergebnisse adversarialer Tests variieren. Wo sie das nicht tun, setzen Sie auf geringstmögliche Berechtigungen, Ausgabekontrollen, Genehmigungen und Code-Scans.

4. Überführen Sie Entscheidungen in verbindliche Governance: Dokumentieren Sie Modell und Version, Testergebnisse, Verantwortliche, genehmigte Kontrollen, Begründung und Überprüfungsdatum. Bewerten Sie die Situation neu, wenn sich Modelle, Berechtigungen, Fine-Tuning-Daten oder Anwendungen ändern.

Das Fazit aus Volume III: Der Score eines Modells zeigt seine Angriffsanfälligkeit, und das System darum herum bestimmt seine Reichweite. Ergreifen Sie Maßnahmen für beides, wechseln Sie Modelle, wo sie sich unterscheiden, und verschärfen Sie Kontrollen, wo sie es nicht tun.

Methodik: Anonymisierte, aggregierte Scan-Daten aus AI-Bill-of-Materials (AI-BOM) von Unternehmen, die Snyk nutzen, ab September 2026: 3.023 Umgebungen, darunter 1.693 mit mindestens einem Modellbezeichner. Erkenntnisse auf Modellebene umfassen US-Konten.

Sicherheitsverantwortliche müssen wissen, welche Fehler für ihr Unternehmen relevant sein könnten und welche Änderung der Kontrollen das Ergebnis beeinflusst. Welches Agenten- und MCP-Muster beschreibt Ihre Umgebung, und wie schneidet Ihr Anbieter bei sieben Angriffsarten ab? Der vollständige Bericht schlüsselt beides auf – außerdem die Ergebnisse nach Branche und Preisklasse sowie die sechs Fragen, die jede für Governance verantwortliche Person beantworten können sollte. Den State of Agentic AI Adoption 2026, Volume III herunterladen.

Möchten Sie Ihren eigenen KI-Bestand bewerten? Evo AI-SPM entdecken.