Eine generative KI-Anwendung testen
Eine generative KI-Anwendung prüft man nicht wie eine herkömmliche: Ihre Angriffsfläche liegt nicht im Code, sondern in dem, was das Modell zu tun bereit ist, wenn man richtig fragt.
Die Lücke liegt nicht im Code, sondern in der Anweisung
Ein Sprachmodell unterscheidet von sich aus nicht zwischen der Anweisung der Entwicklung und einer, die in den zu lesenden Daten steckt. Genau das ist Prompt Injection: Text in einem Dokument, auf einer Webseite, in einem Ticket oder einer E-Mail wird zur Anweisung, sobald der Agent ihn verarbeitet. Der Angreifer braucht keinen Zugang zu Ihrem System — es genügt, dort zu schreiben, wo Ihr Agent lesen wird.
Das Risiko wächst mit den zugestandenen Fähigkeiten. Ein Agent, der nur antwortet, gibt vor allem seinen Kontext preis: interne Anweisungen, Dokumentauszüge, im Speicher verbliebene Daten anderer Nutzenden. Ein Agent, der Werkzeuge aufrufen kann — eine E-Mail senden, in eine Datenbank schreiben, eine Aktion auslösen — gibt diese Werkzeuge selbst preis, mit den ihm erteilten Rechten.
Hinzu kommt die Frage der Schutzmechanismen. Sie sind fast immer vorhanden und fast immer umgehbar: Umformulierung, Sprachwechsel, Rollenspiel, Zerlegen der Anfrage. Sie zu prüfen misst nicht, ob es sie gibt, sondern was es kostet, sie zu überwinden.
- Versteckte Anweisung in einem Dokument, das der Agent verarbeitet
- Daten anderer Nutzenden über den Kontext zurückgegeben
- Werkzeuge des Agenten über ihren Zweck hinaus zweckentfremdet
- Schutzmechanismen durch blosse Umformulierung überwunden
- Agent mit weiteren Rechten als die Person, die ihn nutzt
Alles, was der Agent liest, kann ihm befehlen
Wie wir vorgehen
Wir prüfen die Anwendung so, wie sie exponiert ist, mit den Rechten einer gewöhnlichen Person — und arbeiten uns von dort zu dem vor, was diese Rechte erreichbar machen.
Scoping und Fähigkeiten
Erhebung dessen, was der Agent kann: welche Quellen er liest, welche Werkzeuge er aufruft, auf welche Daten er zugreift und unter wessen Identität. Diese Karte der Fähigkeiten bestimmt, was tatsächlich auf dem Spiel steht.
Direkte und indirekte Injection
Versuche der Übernahme über die Benutzereingabe, dann über die Inhalte, die der Agent aufnimmt — ein Dokument, eine Seite, ein Datensatz. Die zweite wiegt schwerer, denn sie verlangt keinerlei Zugang zu Ihrer Anwendung.
Kontext und Trennung
Suche danach, was das Modell aus seinem Kontext preisgibt: interne Anweisungen, Dokumentfragmente, Spuren anderer Sitzungen. Wir prüfen, dass niemand über den Agenten erreicht, was die eigenen Rechte verbieten.
Werkzeuge und Nebenwirkungen
Prüfung der Aktionen, die der Agent auslösen kann: zweckentfremdete Nutzung, nicht vorgesehene Verkettung, Ausführung ohne Bestätigung. Ein Agent, der schreibt oder sendet, ist ein Agent, den man etwas anderes schreiben oder senden lassen kann.
Rückgabe und Härtung
Priorisierter Bericht mit reproduzierbarem Nachweis, dann konkrete Empfehlungen: engere Rechte, Trennung vertrauenswürdiger Quellen, Prüfung der Ausgaben, verwertbare Protokollierung. Nachtest nach der Behebung.
Mehrere Disziplinen, eine Ansprechperson
Der Test prüft die Anwendung, die Integration fasst die Rechte, die Schulung bereitet die Bauenden vor.
- Karte der Fähigkeiten und Rechte des Agenten
- Reproduzierbare Injection-Szenarien
- Nach realer Wirkung priorisierte Befunde
- Umsetzbare Härtungsempfehlungen
- Nachtest nach der Behebung
Häufige Fragen
Was kann Ihr Agent, wenn man richtig fragt?
Sagen Sie uns, was er liest und was er auslösen kann — daraus stecken wir den Test ab.