Skip to content

For authorized AI red-teaming and defensive research only. Test systems you own or are permitted to test. Read the boundaries.

Autorisierte KI-Tests: Wo die Grenze verläuft

Was autorisiertes Testen für LLM-Anwendungen bedeutet: schriftlicher Geltungsbereich, warum Prompt-Injection-Forschung für Verteidiger legitim ist, verantwortungsvolle Offenlegung und was man niemals tun darf.

Veröffentlicht am 5 Min. Lesezeit

Prompt-Injection-Forschung ist von doppeltem Verwendungszweck (Dual-Use). Derselbe Payload, der dem Sicherheitsteam eines Anbieters einen Weg zur Datenexfiltration aufzeigt, wird – abgefeuert auf ein System, das einem nicht gehört – zum Angriff. Die Technik ändert sich nicht – die Autorisierung schon. In diesem Beitrag geht es um genau diese Grenze, denn alles andere auf dieser Website setzt voraus, dass Sie sich auf der richtigen Seite befinden.

Was „autorisiertes Testen" tatsächlich bedeutet

Autorisiertes Testen bedeutet, dass Sie eine ausdrückliche, dokumentierte Erlaubnis von derjenigen Partei haben, die das System besitzt oder betreibt, und dass diese Erlaubnis genau das abdeckt, was Sie zu tun beabsichtigen. Für eine LLM-Anwendung ist das umfassender als ein klassischer Web-Pentest, denn die Angriffsfläche umfasst:

  • Das Modell und seinen System-Prompt.
  • Angebundene Tools, Funktionen und Agenten, die das Modell aufrufen kann.
  • Abrufquellen (RAG-Korpora, hochgeladene Dateien, Web-Abruf).
  • Nachgelagerte Systeme, die das Modell erreichen kann (E-Mail, Ticketing, Datenbanken, Codeausführung).
  • Drittanbieter von Modellen, deren Nutzungsbedingungen ebenfalls für Sie bindend sind.

Eine Erlaubnis für „die App" ist nicht automatisch die Erlaubnis, den Agenten E-Mails versenden, interne APIs ansprechen oder Daten aus einem angebundenen Laufwerk ziehen zu lassen. Halten Sie es ausdrücklich fest.

Holen Sie es sich schriftlich, mit Geltungsbereich

Ein mündliches „klar, leg los" ist keine Autorisierung, auf die Sie sich berufen können. Bevor Sie auch nur einen einzigen Payload absenden, brauchen Sie eine schriftliche Vereinbarung, die Folgendes festlegt:

  • Wer autorisiert (eine Entität, die das System tatsächlich besitzt) und wer testet.
  • Ziele – genaue Hostnamen, Konten, Tenants, Modell-Endpunkte und welche angebundenen Tools im Geltungsbereich liegen.
  • Außerhalb des Geltungsbereichs – ausdrücklich. Produktive Kundendaten, Drittanbieter-SaaS, die Infrastruktur des Modellanbieters und andere Tenants sind übliche Ausschlüsse.
  • Erlaubte Handlungen – Dürfen Sie Tool-Aufrufe auslösen? Zu einem von Ihnen kontrollierten Proof-of-Concept-Endpunkt exfiltrieren? Echte oder nur synthetische Daten verwenden?
  • Einsatzregeln (Rules of Engagement) – Testfenster, Ratenbegrenzungen, ein Kontakt zum Stoppen und Benachrichtigen, und was zu tun ist, wenn Sie auf echte sensible Daten stoßen.

Bug-Bounty-Programme kodieren vieles davon in ihrer Richtlinie und ihren Safe-Harbor-Bestimmungen. Wenn ein Programm existiert, lesen Sie es und bleiben Sie innerhalb seiner Grenzen; die Richtlinie ist Ihre Autorisierung, und sie hat Grenzen.

Warum Prompt-Injection-Forschung legitim ist

Verteidiger können eine Angriffsklasse nicht abwehren, die sie nicht untersuchen dürfen. Indirekte Prompt-Injection, Markdown-Image-Beacons und RAG-Poisoning sind reale, in freier Wildbahn beobachtete Techniken. Erkennungen aufzubauen, Spotlighting- und Egress-Kontrollen zu schreiben und die eigenen Agenten einem Red-Teaming zu unterziehen – all das erfordert, die Angriffe unter kontrollierten Bedingungen zu reproduzieren. Das ist gängige Sicherheitspraxis – dieselbe Logik, die die Exploit-Entwicklung für diejenigen legitim macht, die den Patch ausliefern.

Gerade der Dual-Use-Charakter ist der Grund, warum Absicht und Autorisierung das Gewicht tragen. Eine allgemein bekannte Technik samt ihrer Abwehrmaßnahmen zu veröffentlichen, hilft dem Fachgebiet. Diese Technik gegen ein System einzusetzen, das nie darum gebeten hat, hilft ihm nicht.

Hinweis zur autorisierten Nutzung: Jede Technik auf dieser Website ist für Systeme bestimmt, die Sie besitzen oder zu deren Test Sie ausdrücklich beauftragt sind. Reproduzieren Sie Angriffe in einem Labor oder in einer Umgebung innerhalb des Geltungsbereichs, niemals gegen Dritte.

Verantwortungsvolle Offenlegung

Wenn Sie etwas finden – ob im Geltungsbereich oder zufällig –, gehen Sie sorgfältig damit um:

  1. Hören Sie auf zu eskalieren. Demonstrieren Sie die Auswirkung mit dem notwendigen Minimum; pivotieren Sie nicht weiter, sobald ein Fund belegt ist.
  2. Minimieren Sie Daten. Verwenden Sie synthetische Geheimnisse als Köder (Canaries). Wenn Sie echte Daten berühren, erfassen Sie nur das, was das Problem belegt, und halten Sie fest, was Sie gesehen haben.
  3. Melden Sie zunächst privat. Nutzen Sie den Sicherheitskontakt des Anbieters, die security.txt oder den Bug-Bounty-Kanal. Liefern Sie klare Reproduktionsschritte und die Auswirkung.
  4. Geben Sie Zeit zur Behebung. Vereinbaren Sie einen Zeitplan zur Behebung (koordinierte Offenlegung, oft 90 Tage). Veröffentlichen Sie erst nach einem Fix oder nach einer angemessenen, kommunizierten Frist.
  5. Führen Sie Aufzeichnungen. Ihr Geltungsbereichsdokument, Zeitstempel und Korrespondenz sind das, was Forschung von Eindringen unterscheidet, falls jemand nachfragt.

Was man NICHT tun sollte

Manche Grenzen sind eindeutig, und sie zu überschreiten macht aus Forschung in den meisten Rechtsordnungen eine Straftat:

  • Testen Sie keine Systeme, die Ihnen nicht gehören oder für die Sie keine schriftliche Erlaubnis haben – auch nicht „nur einen Payload" gegen einen aktiven Chatbot eines Dritten.
  • Exfiltrieren Sie nicht die Daten anderer Menschen. Beaconen Sie einen Köder, den Sie selbst platziert haben, nicht die Datensätze eines echten Kunden oder die Dokumente eines anderen Tenants.
  • Überschreiten Sie nicht Ihren Geltungsbereich, um zu „sehen, wie weit es geht". Agentische Systeme können destruktive Handlungen in der realen Welt ausführen; gehen Sie davon aus, dass Tool-Aufrufe Konsequenzen haben.
  • Behalten oder teilen Sie keine erfassten Daten über das hinaus, was die Offenlegung erfordert, und löschen Sie sie danach.
  • Sitzen Sie nicht auf einem kritischen Fund, während Sie überlegen, ob Sie ihn zur Waffe machen. Legen Sie ihn offen.

Fazit

Der technische Inhalt hier lässt sich direkt auf OWASPs LLM01: Prompt Injection abbilden. Die Fähigkeit ist übertragbar; die Autorisierung nicht. Behalten Sie den schriftlichen Geltungsbereich, halten Sie die Köder synthetisch, legen Sie verantwortungsvoll offen und bleiben Sie innerhalb der Grenze – das ist es, was diese Arbeit vertretbar und lohnenswert macht.