Klassische Software trennt sauber zwischen Programm und Daten. Ein Sprachmodell tut das nicht. Für ein LLM ist alles Text: die Anweisung des Unternehmens, die Frage des Nutzers und der Inhalt des Dokuments, das gerade gelesen wird. Wenn in diesem Dokument eine Anweisung steht, kann das Modell sie ausführen. Das ist keine Sicherheitslücke im Sinne eines Fehlers — es ist eine Eigenschaft der Technologie.
Wie Prompt Injection funktioniert
Ein Angreifer schreibt Anweisungen in Inhalte, von denen er weiß, dass ein KI-System sie verarbeiten wird. Beispiele aus dem Unternehmensalltag:
- Eine eingehende E-Mail enthält versteckten Text mit einer Anweisung an den KI-Assistenten, der sie zusammenfassen soll
- Ein Bewerbungs-PDF enthält weiße Schrift auf weißem Grund mit Instruktionen an das Screening-System
- Eine Webseite, die ein Recherche-Agent besucht, enthält im Quelltext Anweisungen zur Weitergabe von Daten
- Ein Kundenkommentar im Support-Ticket weist den Agenten an, interne Informationen preiszugeben
Die gefährliche Kombination ist nicht der KI-Agent allein. Sie besteht aus drei Zutaten: Zugriff auf sensible Daten, Verarbeitung fremder Inhalte und die Fähigkeit, nach außen zu kommunizieren. Wer eine dieser drei Zutaten entfernt, entschärft den Angriff.
Die drei realistischen Schadensbilder
Datenabfluss: Der Agent hat Zugriff auf interne Daten und wird dazu gebracht, sie in eine Antwort, eine ausgehende E-Mail oder einen HTTP-Aufruf zu schreiben. Fehlhandlung: Der Agent führt eine Aktion aus, die er nicht ausführen sollte — eine Rechnung freigeben, einen Datensatz löschen, eine Zahlung anstoßen. Manipulierte Ausgabe: Der Agent liefert eine inhaltlich verfälschte Zusammenfassung, auf deren Basis ein Mensch eine Fehlentscheidung trifft. Das dritte Schadensbild ist das unauffälligste und deshalb oft das teuerste.
Was tatsächlich schützt
Es gibt keinen vollständigen technischen Schutz gegen Prompt Injection — jedenfalls keinen, der als gelöst gelten könnte. Was funktioniert, ist Architektur, die den möglichen Schaden begrenzt:
- Least Privilege für Agenten: Ein Agent bekommt exakt die Berechtigungen, die seine Aufgabe erfordert — lesend, wo lesend genügt.
- Trennung von Lesen und Handeln: Der Agent, der fremde Inhalte verarbeitet, ist nicht derselbe, der Systemaktionen ausführen darf.
- Human in the Loop bei irreversiblen Aktionen: Zahlungen, Löschungen, externe Kommunikation gehen über eine menschliche Freigabe.
- Ausgehende Kanäle begrenzen: Ein Agent, der keine E-Mails senden und keine beliebigen URLs aufrufen kann, kann Daten schlechter exfiltrieren.
- Vollständiges Logging: Jeder Werkzeugaufruf, jede Eingabe, jede Ausgabe wird protokolliert — sonst ist ein Vorfall nicht rekonstruierbar.
Der zweite Vektor: unbeabsichtigter Datenabfluss
Nicht jeder Datenabfluss ist ein Angriff. Der häufigere Fall im Mittelstand ist banal: Mitarbeitende fügen Kundendaten, Verträge oder Quellcode in ein öffentliches KI-Tool ein, weil es die Arbeit erleichtert. Ob diese Daten zu Trainingszwecken verwendet werden, hängt vom Anbieter und vom Vertrag ab — die relevante Frage für ein Unternehmen ist jedoch eine andere: Ist die Weitergabe an diesen Dienstleister überhaupt zulässig, und ist sie im Verarbeitungsverzeichnis abgebildet?
Die organisatorische Leitplanke
Ein Verbot funktioniert nicht — Mitarbeitende nutzen die Tools trotzdem, dann eben unsichtbar. Was funktioniert, ist eine klare, kurze Regel: Welche Tools sind freigegeben, welche Datenkategorien dürfen hinein, und welche niemals. Drei Sätze, die jeder versteht, wirken besser als eine zehnseitige Richtlinie, die niemand liest.
Vor jedem Agenten-Rollout
Drei Fragen entscheiden über das Risikoprofil: Welche Daten kann dieser Agent sehen? Welche Inhalte von außen verarbeitet er? Und welche Aktionen kann er ohne menschliche Bestätigung auslösen? Wenn die Antworten auf alle drei Fragen umfangreich ausfallen, ist der Agent kein Produktivitätsgewinn, sondern ein offenes Risiko — unabhängig davon, wie gut das Modell dahinter ist.