In this article
Wie KI-Agenten die Sicherheit weiterhin gefährden, obwohl nichts kaputt ist
KI-Agenten schaffen schnell den Sprung von Experimenten in den produktiven Einsatz. Sie priorisieren Warnmeldungen, prüfen Pull Requests, fassen Logs zusammen, leiten Tickets weiter und führen mit echten Zugangsdaten Aktionen in verschiedenen Systemen aus.
Aus Sicherheitssicht wirken viele dieser Systeme sauber. Es gibt keinen unsicheren Umgang mit Speicher. Keine offensichtliche Injection-Schwachstelle. Keine fehlerhafte Authentifizierung. Und doch können sie weiterhin versagen – manchmal katastrophal –, nur weil sie einem einzigen Satz folgen.
Diese Lücke hat nichts mit fehlenden Patches oder ungeprüften Abhängigkeiten zu tun, sondern damit, wie nichtdeterministische Systeme wie LLMs die Bedeutung von Vertrauensgrenzen verändern.
Aktuelle Forschung von Snyk Labs untersucht, warum traditionelle AppSec-Modelle Schwierigkeiten haben, das Verhalten von Agenten zu bewerten, und warum sich Threat Modeling zu einer der wirksamsten Abwehrmaßnahmen für KI-native Anwendungen entwickelt.
Deterministische Sicherheit lässt sich nicht ohne Weiteres auf agentische Systeme übertragen
Traditionelle Anwendungssicherheit basiert auf vorhersehbarem Verhalten. Eingaben gelten als Daten, Anweisungen werden durch Code begrenzt und Kontrollen setzen klare Grenzen durch. KI-Agenten funktionieren jedoch anders. Sie interpretieren Bedeutungen, bewerten Kontext und entscheiden, wann sie handeln. Dadurch entsteht eine neue Risikoklasse: Das System verhält sich genau wie vorgesehen, doch das Ergebnis bleibt schädlich.
Zum Beispiel:
Ein KI-Agent liest nicht vertrauenswürdigen Text aus einem Issue, einer E-Mail oder einem Dokument.
Dieser Text verändert subtil, wie der Agent seine Aufgabe interpretiert.
Der Agent nutzt legitime Tools und Berechtigungen, um eine Aktion auszuführen.
Sensible Daten landen an einem Ort, an den sie niemals gelangen sollten.
Aus Sicht eines Sicherheitsscanners ist nichts „kaputt“, aus Sicht eines Angreifers hat hingegen alles funktioniert. Deshalb steht Prompt Injection ganz oben in den OWASP Top 10 für LLMs und deshalb kann statische Analyse allein solche Fehler nicht erkennen.
Das tatsächliche Risiko agentischer Systeme ist verhaltensbedingt, nicht technischer Natur
Eine der wichtigsten Erkenntnisse der Studie betrifft den Ort, an dem Fehler auftreten. Agentische Systeme versagen tendenziell auf der Verhaltensebene, nicht auf der Codeebene. Sicherheitsteams müssen sich zunehmend Fragen stellen wie:
Dient diese Eingabe als Kontext oder als Anweisung?
Darf dieser Agent auf Grundlage des gerade Gelesenen handeln?
Was geschieht, wenn diese Ausgabe zur Eingabe eines anderen Agenten wird?
Dabei handelt es sich um semantische Entscheidungen, die naturgemäß probabilistisch sind. Selbst gut konzipierte Leitplanken können im großen Maßstab keine perfekten Ergebnisse garantieren. An diesem Punkt stoßen viele bestehende Tools an ihre Grenzen – nicht, weil sie schlecht entwickelt wurden, sondern weil sie nie dafür konzipiert waren, Absicht, Handlungsspielraum und Informationsfluss zu bewerten.
Aktuelle Vorfälle in der Branche machen diesen Wandel unübersehbar.
Anfang 2025 legten Forschende Fehler in Agentenbereitstellungen von Unternehmen bei ServiceNow und Salesforce offen, obwohl keine herkömmliche Schwachstelle vorlag.
Im Fall von ServiceNow verarbeitete ein interner Agent eine Anfrage korrekt, die scheinbar von einem vertrauenswürdigen Anbieter stammte. Da die Identität jedoch als vom Nutzer bereitgestellte Metadaten und nicht als verifizierter Anspruch behandelt wurde, richtete der Agent im Namen eines Angreifers eine Sitzung mit weitreichenden Berechtigungen ein – ein klassischer Fall eines Confused Deputy, der ausschließlich durch die Logik des Agenten ausgelöst wurde.
Bei Salesforce gelangte ein öffentliches Formularfeld unverändert in das Kontextfenster eines internen „Zusammenfassungs“-Agenten. Dadurch konnte eine nicht vertrauenswürdige Eingabe die Absicht des Agenten verändern und einen routinemäßigen Workflow in einen Pfad zur Datenexfiltration verwandeln. In beiden Fällen bestanden die Code-Scans, die Berechtigungen waren technisch gültig und die Systeme verhielten sich wie vorgesehen. Der Fehler trat auf der Verhaltensebene auf: Die Agenten leiteten Bedeutung, Autorität und Absicht aus einem Kontext ab, den Sicherheitstools als inerte Daten behandelten.
Warum das Zusammenspiel wichtiger ist als einzelne Agenten
Viele der schwerwiegendsten Fehler in agentischen Systemen entstehen nicht innerhalb eines einzelnen Agenten. Sie treten auf, wenn Agenten zu Workflows, Pipelines oder orchestrierten Systemen zusammengeführt werden. Für sich genommen mag jeder Agent gut konzipiert wirken: Berechtigungen sind eingegrenzt, Richtlinien werden durchgesetzt und das Verhalten entspricht den Erwartungen. Sicherheitsprüfungen werden bestanden, weil isoliert betrachtet nichts offensichtlich unsicher erscheint.
Das Risiko entsteht an den Übergängen. Wird die Ausgabe eines Agenten zur Eingabe eines anderen, entstehen neue Datenpfade – oft ohne explizite Prüfungen zu Sensibilität, Absicht oder Ziel. Informationen können Vertrauensgrenzen überschreiten, weil das System davon ausgeht, nachgelagerte Agenten würden „das Richtige tun“. Das ähnelt bekannten Sicherheitsmustern wie Confused Deputies und Time-of-Check-to-Time-of-Use-Lücken, mit einem wichtigen Unterschied: In agentischen Systemen kann das Modell diese Fehler durch seine Schlussfolgerungen dynamisch auslösen, statt dass sie auf festgelegter Logik beruhen.
Mit zunehmender Komplexität agentischer Workflows wird das Risiko zu einer emergenten Eigenschaft des Systems statt zu einem Fehler in einer einzelnen Komponente. Daher muss die Sicherheitsanalyse beim Zusammenspiel ansetzen, nicht bei einzelnen Agenten.
Threat Modeling verschafft Sicherheitsteams Handlungsspielraum
Herkömmliche Sicherheitstools können agentisches Verhalten nur schwer bewerten, weil technisch nichts kaputt ist. Threat Modeling bringt wieder Struktur ins Spiel, indem es den Fokus von der Korrektheit des Codes auf das Verhalten des Systems verlagert. Statt zu fragen, ob eine Funktion verwundbar ist, untersuchen Teams, wie Daten, Berechtigungen und Entscheidungen durch ein agentisches System fließen.
Dieser Ansatz wirft Fragen auf, die Scanner nicht beantworten können. Wo gelangen nicht vertrauenswürdige Eingaben in den Workflow? Welche Agenten können sensible Daten lesen? Welche Aktionen verändern den externen Zustand? Wie schränken frühere Entscheidungen in einem Workflow spätere Aktionen ein oder ermöglichen sie?
Indem Threat Modeling diese Zusammenhänge abbildet, deckt es Fehlerpfade auf, die erst beim Zusammenspiel von Komponenten entstehen und bei der isolierten Prüfung von Agenten unsichtbar bleiben. Für Sicherheitsteams, die mit nichtdeterministischen Systemen arbeiten, ist das ein entscheidender Vorteil. Threat Modeling versucht nicht, jedes mögliche Ergebnis vorherzusagen. Stattdessen hilft es Teams zu verstehen, wo Fehler auftreten könnten, und Kontrollen zu entwickeln, die ihre Auswirkungen begrenzen.
Von der Prävention zur Eindämmung
Agentische Systeme zwingen uns dazu, neu zu überdenken, was „sicher“ bedeutet. Wenn Verhalten probabilistisch ist, lässt sich die Wahrscheinlichkeit eines Fehlers kaum auf null senken. Selbst starke Schutzmaßnahmen lassen Raum für Fehler, und im großen Maßstab werden geringe Wahrscheinlichkeiten zur betrieblichen Realität. In diesem Umfeld greifen Sicherheitsstrategien zu kurz, die sich ausschließlich auf Prävention stützen.
Eindämmung wird ebenso wichtig wie Erkennung. Ziel ist es, einzuschränken, worauf ein Agent zugreifen kann, welche Kombinationen von Fähigkeiten möglich sind und wie weit sensible Daten gelangen können. Anstatt davon auszugehen, dass Grenzen immer Bestand haben, werden Systeme so konzipiert, dass sie auch dann sicher bleiben, wenn diese Grenzen versagen. Im Mittelpunkt stehen dabei die Begrenzung des Schadensradius, die Trennung von Fähigkeiten und explizite Kontrollen des Datenflusses.
Threat Modeling unterstützt diesen Wandel und hilft Teams dabei, die wichtigsten Ansatzpunkte für Eindämmungsmaßnahmen zu identifizieren. Es bietet einen Rahmen für die Entwicklung resilienter Systeme, die Nutzer und Daten auch dann schützen, wenn sich Modelle unerwartet verhalten.
Warum KI-Sicherheit für Agenten mit Threat Modeling beginnt
KI-Agenten verändern das Verhalten von Software – und damit auch die Art, wie Sicherheitsvorfälle entstehen. Die größten Risiken liegen nicht länger in isolierten Schwachstellen oder Fehlkonfigurationen, sondern darin, wie autonome Systeme Kontext interpretieren, Fähigkeiten kombinieren und über Vertrauensgrenzen hinweg handeln. Um diese Systeme abzusichern, müssen wir deterministische Annahmen hinter uns lassen und Ansätze verfolgen, die Verhalten, Interaktionen und Auswirkungen berücksichtigen.
Threat Modeling bietet einen praxisnahen Weg nach vorn. Indem Teams das Verhalten von Agenten und den Systemverbund als zentrale Sicherheitsaspekte behandeln, gewinnen sie die nötige Klarheit, um Kontrollen zu entwickeln, die mit KI-gestützter Entwicklung mitwachsen. Wenn agentische Systeme zur Grundlage moderner Anwendungen werden, wird dieser Wandel darüber entscheiden, wie Unternehmen Sicherheitsmaßnahmen entwickeln, die mit den nächsten Entwicklungen Schritt halten.
Möchten Sie tiefer eintauchen und die umfassende Studie lesen? Besuchen Sie noch heute das Lab.
Oder sind Sie bereits Snyk-Kunde und an dieser Studie interessiert? Bewerben Sie sich für das Evo Design Partner Program, um eine Vorschau auf unsere Lösung Secure Agent Design (KI-Threat-Modeling) zu erhalten.
SNYK LABS
Testen Sie die neuesten Innovationen von Snyk im Bereich KI-Sicherheit
Snyk-Kunden haben jetzt Zugriff auf Snyk AI-BOM und Snyk MCP-Scan in der experimentellen Vorschau – und weitere Innovationen folgen!