Laut OWASP, die damit zum zweiten Mal in Folge den Spitzenplatz in ihrer Top-10-Liste behauptet, stellt die Eingabeaufforderung das größte Risiko für Unternehmensanwendungen dar, die Sprachmodelle verwenden. Es handelt sich dabei nicht um ein theoretisches Szenario oder ein Laborproblem, sondern um eine direkte Folge der Funktionsweise dieser Systeme.
Ein Sprachmodell unterscheidet nicht zwischen den Anweisungen seines Entwicklers und dem verarbeiteten Text. Alles wird als Wort empfangen. Enthält ein vom System gelesenes Dokument eine Anweisung, besteht die Möglichkeit, dass es diese auch als solche interpretiert.
Die bekannte Variante – ein Benutzer, der «Ignorieren Sie Ihre Anweisungen» schreibt – ist die am wenigsten besorgniserregende, da der Angreifer anwesend sein muss und über die gleichen Berechtigungen wie jeder andere Benutzer verfügt.
Die im Geschäftsumfeld relevante Version ist die indirekte InjektionDer schädliche Text wird nicht vom Benutzer verfasst; er ist Teil der Inhalte, die das System im Rahmen seiner normalen Arbeit verarbeitet.
Die üblichen Vektoren:
In jedem Fall ist der Vorgang derselbe: Jemand von außen schreibt Text, den Ihr System liest und der dessen Verhalten beeinflussen kann. Und in jedem Fall entspricht der potenzielle Schaden exakt dem Umfang der Berechtigungen, die Sie dieser Person erteilt haben.
Die intuitive Antwort wäre, verdächtige Anweisungen bereits bei der Eingabe herauszufiltern. Dies funktioniert aus drei Gründen nicht zuverlässig:
Sprache hat unendlich viele Formen. Jede Liste verbotener Muster kann umformuliert werden. Die Anweisung kann in einer anderen Sprache verfasst, paraphrasiert oder in mehrere Sätze unterteilt werden.
Es könnte versteckt sein. Leerer Text auf einer leeren Seite in einem PDF, Metadaten, Inhalte, die der Benutzer nicht sieht, die aber vom System gelesen werden.
Der Filter kann die Absicht nicht erkennen. Eine legitime E-Mail könnte die Formulierung «Bitte leiten Sie dies an die Buchhaltung weiter» enthalten. Das System hat keine zuverlässige Möglichkeit zu entscheiden, ob es sich um eine Anweisung für sich selbst oder um eine Information für eine Person handelt.
Das operative Ergebnis ist gleichermaßen unangenehm wie aufschlussreich: Wir müssen davon ausgehen, dass die Injektion stattfinden wird, und die Konstruktion so gestalten, dass es keine Rolle spielt..
Prinzip | Was beinhaltet das? | Was es verhindert |
|---|---|---|
Mindestgenehmigung | Das System greift nur auf das zu, was seine spezifische Aufgabe erfordert. | Dass eine eingeschleuste Anweisung externe Daten erreicht |
Kanaltrennung | Externe Inhalte werden niemals als Systemanweisung behandelt. | Lassen Sie ein PDF das Verhalten neu definieren |
Whitelist für Aktien | Nur explizit aufgeführte Operationen sind zulässig. | Dass etwas Unvorhergesehenes passiert |
Menschliche Validierung im irreversiblen | Zahlungen, externe Kommunikation, Produktionsänderungen | Dass der Schaden ohne Überprüfung eintritt |
Vollständige Registrierung | Es protokolliert, was eingegeben und was ausgeführt wurde. | Dass der Vorfall irreparabel ist |
Diese fünf Punkte betreffen die Architektur, nicht die Konfiguration von Werkzeugen. Und alle fünf sind, wenn sie vor der Entwicklung getroffen werden, mit geringen Kosten verbunden. Daher gehört dieser Artikel eher in den Bereich Design als in die Sicherheitsdiskussion.
OWASP fügt dieser Tabelle zwei damit zusammenhängende Risiken hinzu, die erwähnt werden sollten: LLM02, Offenlegung sensibler Informationen, Und LLM06, Überkapazität. Die drei Ansätze stellen dasselbe Problem aus unterschiedlichen Perspektiven dar: Was kann das System lesen, was kann es tun und wer kann es beeinflussen? Wir haben dies in Die Erteilung von Berechtigungen an einen Beauftragten ist eine riskante Entscheidung.
Stellen Sie sich einen Assistenten vor, der die im Verwaltungs-E-Mail-Postfach eingehenden Rechnungen bearbeitet: Er extrahiert Betrag, Lieferant und Kontonummer und bereitet die Zahlung vor.
Ein betrügerischer Lieferant versendet eine Rechnung, die am Ende eine kleine Anweisung an das System enthält, eine andere Kontonummer zu verwenden. Wenn der Sachbearbeiter die Berechtigung hat, Zahlungen vorzubereiten, und niemand die Kontonummer mit den Daten des Lieferanten abgleicht, wird der Betrug so effizient wie von einem automatisierten System ausgeführt.
Beachten Sie, dass das Modell in diesem Beispiel nicht versagt hat: Es hat genau das getan, was der Text von ihm verlangte. Der Fehler liegt im Design, das es einem externen Text ermöglichte, eine wichtige Information zu ermitteln, ohne sie mit der verlässlichen Quelle abzugleichen.
Daher die Regel, die wir in jedem Projekt wiederholen: Das Modell entwirft und interpretiert; das System entscheidet über die Fakten.. Beträge, Konten, Status und Berechtigungen werden mit dem Quellsystem abgeglichen; sie werden niemals aus verarbeiteten Inhalten übernommen.
Wenn jemand eine KI-gestützte Lösung vorstellt, die externe Inhalte liest, trennen drei Fragen die seriösen von den improvisierten Lösungen:
Ein Anbieter, der antwortet: «Unser Modell ist davon nicht betroffen», hat das Risiko nicht verstanden. Die Eindämmung hängt nicht von der Qualität des Modells ab, sondern von dessen Anwendungsbereich.
Es handelt sich um die Manipulation des Verhaltens eines Sprachmodells durch Text, den das Modell wie Anweisungen verarbeitet. OWASP stuft dies in seinen Top 10 der größten Risiken für LLM-Anwendungen bis 2025 ein, da das Modell strukturell nicht zwischen den Anweisungen des Entwicklers und den analysierten Inhalten unterscheidet.
Dies ist die relevante Variante im Geschäftsumfeld: Die Anweisungen werden nicht vom Benutzer geschrieben, sondern sind Bestandteil von Inhalten, die das System routinemäßig verarbeitet – beispielsweise eine E-Mail des Lieferanten, ein PDF, eine Webseite, ein Support-Ticket oder ein Formularfeld.
Nicht zuverlässig. Sprache lässt unendlich viele Umformulierungen zu, Anweisungen können in unsichtbarem Text oder Metadaten verborgen sein, und ein Filter kann die Absicht nicht ermitteln. Der richtige Ansatz besteht darin, davon auszugehen, dass es passieren wird, und den potenziellen Schaden durch Berechtigungen und Kontrollen zu begrenzen.
Mit fünf Designprinzipien: minimale Berechtigungen pro Aufgabe, Trennung zwischen externen Inhalten und Systemanweisungen, Whitelist zulässiger Aktionen, obligatorische menschliche Validierung bei irreversiblen Operationen und vollständige Protokollierung der Eingaben und durchgeführten Aktionen.
Ja, sofern das System diese verarbeitet und über weitreichende Berechtigungen verfügt. Ein typisches Beispiel ist eine Rechnung mit der Anweisung, die Zahlungskontonummer zu ändern. Das Problem liegt nicht im Modell selbst, sondern in der Konzeption, die es externem Text ermöglicht, kritische Daten zu ermitteln, ohne diese mit der Quelle abzugleichen.
Was geschieht, wenn die verarbeiteten Inhalte Anweisungen enthalten, die an das System gerichtet sind? Was kann das System im schlimmsten Fall tun? Und ließe sich ein Vorfall, der sich vor einem Monat ereignet hat, rekonstruieren? Eine Antwort, die die Möglichkeit eines Angriffs verneint, deutet auf mangelndes Risikobewusstsein hin.
Kann Ihr KI-System auch von Dritten verfasste Inhalte lesen? Wir überprüfen Umfang, Berechtigungen, Kanaltrennung und Rückverfolgbarkeit und zeigen Ihnen das schlimmstmögliche Szenario des aktuellen Designs auf. Bewertung anfordern →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
