Prompt-Injection bei KI-Anwendungen — Eine Anweisung ist keine Sicherheitsgrenze

Eine kleine Anwendung liest eine eingehende E-Mail, bittet ein Sprachmodell um eine Zusammenfassung und lässt das Modell, falls diese Zusammenfassung eine Aufgabe erwähnt, eine Folgeaktion anstoßen. Die E-Mail stammt von jemandem, den du nicht kontrollierst. Der Text darin kann alles Mögliche behaupten, auch „ignoriere deine bisherigen Anweisungen". Wird dieser Text an die Anweisungen des Modells angehängt, kann das Modell ihn ebenfalls als Anweisung behandeln. Das ist die Gestalt einer Angriffsklasse, die das OWASP GenAI Security Project als erstes Risiko in seiner Top-10-Liste für LLM-Anwendungen führt: Prompt Injection.

Eine Prompt-Injection-Schwachstelle entsteht, wenn Eingaben das Verhalten oder die Ausgabe eines Modells auf unbeabsichtigte Weise verändern. Das Gefährliche ist nicht, dass das Modell etwas Seltsames schreibt; das Problem ist, dass eine Anwendung ihre eigenen Anweisungen zuverlässig nicht von angreiferkontrollierten Daten unterscheiden kann. Dieser Artikel erklärt, warum diese Unterscheidung so schwer fällt, wie sich der Angriff verändert, wenn Daten von außen kommen, und betrachtet Maßnahmen, die im Anwendungscode leben statt im Prompt.

Ein Textstrom, zwei Arten von Inhalt

Viele kleine Integrationen sind im Kern eine Verkettung: Systemanweisungen, abgerufene Inhalte und Benutzereingaben werden zu einem einzigen Prompt zusammengefügt, bevor sie an das Modell gesendet werden. In diesem Strom gibt es kein strukturelles Merkmal, das das Modell als absolut behandelt. Simon Willison, der den Begriff 2022 mitgeprägt hat, zeigte die Grundversion in einem Essay vom April 2023: Eine Anwendung, die Text ins Französische übersetzen und JSON ausgeben sollte, hörte auf zu übersetzen und begann wie ein Pirat des 18. Jahrhunderts zu reden, weil die unübersetzte Eingabe ihre eigene Anweisung enthielt, genau das zu tun (Simon Willison, „Prompt injection: What's the worst that can happen?", 14. April 2023).

Die OWASP-Definition betont einen subtilen Punkt: Eine Prompt Injection muss für einen menschlichen Leser nicht sichtbar sein. Sie muss nur vom Modell geparst werden. Eine Anweisung, die im Leerraum einer Seite, in einem Bild oder in einem langen Dokument versteckt ist, kann dieselbe Wirkung haben wie eine explizite Anfrage. In Sicherheitsbegriffen ist das ein Eingabevalidierungsproblem, bei dem die „Abfragesprache" natürliche Sprache ist.

Prompt Injection wird manchmal mit Jailbreaking gleichgesetzt, doch das OWASP-Projekt trennt beides. Jailbreaking ist eine Form der Injection, bei der die Eingabe eines Angreifers das Modell dazu bringt, seine Sicherheitsprotokolle vollständig außer Kraft zu setzen. Prompt Injection ist weiter gefasst: Sie manipuliert das Verhalten, ohne zwangsläufig Sicherheitsmechanismen zu beseitigen. Für eine kleine Anwendung bedeutet beides, dass das Modell nun der Logik des Angreifers folgt statt der des Entwicklers.

Indirekte Injection: Der Angreifer ist nicht mehr der Benutzer

Der klarste Wandel kam mit dem, was Kai Greshake und seine Kollegen indirect prompt injection nannten. Ihr Paper von 2023, Not what you've signed up for, argumentiert, dass LLM-integrierte Anwendungen die Grenze zwischen Daten und Anweisungen verschwimmen lassen. Der Angreifer muss das Modell nicht mehr direkt ansteuern. Stattdessen injiziert er Anweisungen in Daten, die die Anwendung voraussichtlich abruft: eine Webseite, ein gemeinsam genutztes Dokument, einen Lebenslauf, eine E-Mail oder sogar die README eines Repositories (Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz und Mario Fritz, arXiv:2302.12173, 2023).

Willisons Essay von 2023 beschreibt dieselbe Angriffsfamilie mit konkreten Beispielen. Ein besonders deutlicher Fall ist die Vergiftung des Suchindexes: Ein Forscher platzierte eine Anweisung in weißer Schrift auf weißem Grund auf seiner akademischen Profilseite, und Bing, das den sichtbaren Inhalt der Seite in seinen Prompt einlas, beschrieb ihn daraufhin mit genau dieser behaupteten Expertise. Der verborgene Text war nicht für Menschen gedacht; er war für die Abruf-Pipeline gedacht, die Seiten in ein Modell einspeist (Willison, 2023).

Greshakes Paper kartiert ein Spektrum von Auswirkungen, das über eine einzelne peinliche Antwort hinausgeht: Datendiebstahl, Worming (das Verbreiten einer Anweisung an andere Systeme, die die Anwendung berührt) und die Kontamination des breiteren Informationsökosystems. Die Gruppe demonstrierte praktische Angriffe auf echte Bereitstellungen, darunter einen GPT-4-gestützten Chat-Assistenten im Browser und Code-Completion-Engines. Was für eine kleine Automatisierung zählt: Die verwundbare Eigenschaft ist nicht exotisch. Daten abrufen, in einen Prompt einfügen, und das Modell folgt gelegentlich dem, was die Daten sagen.

Warum ein stärkerer Prompt nicht die Antwort ist

Wer Prompt Injection zum ersten Mal begegnet, schlägt meist Abwehr auf Prompt-Ebene vor: Das Modell soll Angriffe ignorieren, abgerufener Text wird in Begrenzer gepackt, eine Warnung in den System-Prompt aufgenommen oder das Modell gebeten, vertrauenswürdige von unvertrauenswürdigen Inhalten zu unterscheiden. Das ist alles einen Versuch wert, aber es ist keine Grenze.

Willison ist zur Filterung auf Prompt-Ebene ebenso deutlich: In seinem Essay 2023 beschreibt er viele Lösungen, die „zu 95 % wirksam" sind, weil sie Eingaben und Ausgaben filtern, und warnt, dass die restlichen fünf Prozent genau das Fenster sind, nach dem ein entschlossener Angreifer sucht. Selbst ein getrennter System-Prompt ist umgehbar. Im selben Essay zeigte er, dass GPT-4, das das Konzept des getrennten System-Prompts einführte, dennoch Anweisungen befolgte, die in der Benutzereingabe versteckt waren und es aufforderten, sein Verhalten zu ändern.

Der OWASP-Eintrag von 2025 macht einen verwandten Punkt zu Abruf und Feintuning: Techniken wie Retrieval-Augmented Generation und Fine-Tuning sollen Antworten relevanter machen, aber die Forschung hat nicht gezeigt, dass sie Prompt Injection vollständig entschärfen. Willisons Kommentar von 2025, verfasst im Zuge eines Berichts von The Economist, fasst den andauernden Zustand unverblümt zusammen: eine tödliche Dreifaltigkeit von Bedingungen macht KI-Systeme angreifbar — der Zugriff auf private Daten, die Konfrontation mit unvertrauenswürdigen Eingaben und die Fähigkeit zu handeln (Simon Willison, „Why AI systems might never be secure", 23. September 2025). Der verlinkte Bericht nennt eine Episode vom Januar 2024, in der ein Paketdienst seinen KI-Kundenservice-Chatbot abschaltete, weil Kunden ihn zu unflätigen Antworten befehligen konnten. Das war harmlos und billig; die unbequeme Wahrheit: Die Branche liefert weiterhin dieselbe Kombination aus.

Die Schlussfolgerung aus all diesen Quellen ist konsistent: Text auf Prompt-Ebene ist keine Sicherheitsgrenze. Wenn man einen Absatz Systemanweisungen als Firewall behandelt, stellt man die Anwendung vor die Aufgabe, sich mit genau der Sprache zu verteidigen, die der Angreifer kontrolliert.

Maßnahmen außerhalb des Prompts

Wenn die Textebene nicht vertrauenswürdig ist, müssen die Kontrollen auf die Ebenen wandern, die der Angreifer nicht kontrolliert: der Code, der entscheidet, was das Modell tun darf, und die Person bzw. Richtlinie, die das Ergebnis genehmigt.

Der OWASP-Eintrag listet praktische Kategorien, die bewusst auf Anwendungsebene liegen. Darunter:

• Least Privilege. Die Anwendung bekommt eigene Zugangsdaten, Funktionen werden im Code gehandhabt statt pauschal dem Modell übergeben, und der Zugriff des Modells wird auf das Minimum für seine Aufgabe begrenzt.
• Freigabe durch Menschen bei riskanten Aktionen. Für privilegierte Operationen wie das Senden von Nachrichten, das Ändern von Dateien oder administrative Endpunkte bleibt ein Mensch im Prozess.
• Deterministische Ausgabevalidierung. Ausgabeformate festlegen und per Code validieren, nicht per weiterem Prompt.
• Unvertrauenswürdigen Inhalt trennen. Externen Inhalt klar abgrenzen, damit sein Einfluss auf die Kernanweisungen begrenzt bleibt.
• Das Modell als unvertrauenswürdigen Benutzer behandeln. Vertrauensgrenzen regelmäßig testen und dabei annehmen, dass das Modell überredet werden kann.

Eine kompakte Art, das in Code auszudrücken, ist eine kleine Richtlinientabelle für Aktionen, die ein Modell vorschlagen darf. Der Code unten ist eine Veranschaulichung und wurde mit php -l auf Syntax geprüft; passe Werkzeuge und Bedeutung an deine Anwendung an.

<?php

declare(strict_types=1);

final class ToolPolicy
{
    private const TOOLS = [
        'search_knowledge_base' => ['risk' => 'read',     'confirm' => false],
        'create_draft'          => ['risk' => 'write',    'confirm' => false],
        'send_email'            => ['risk' => 'external', 'confirm' => true],
        'run_shell_command'     => ['risk' => 'execute',  'confirm' => true],
    ];

    public static function proposal(string $tool, array $arguments): array
    {
        if (!isset(self::TOOLS[$tool])) {
            return ['ok' => false, 'reason' => 'tool_not_allowed'];
        }

        $allowedArguments = [
            'search_knowledge_base' => ['query'],
            'create_draft'          => ['title', 'content'],
            'send_email'            => ['to', 'subject', 'body'],
            'run_shell_command'     => ['command'],
        ];

        $unexpected = array_diff(array_keys($arguments), $allowedArguments[$tool] ?? []);
        if ($unexpected !== []) {
            return ['ok' => false, 'reason' => 'unexpected_argument'];
        }

        return [
            'ok'        => true,
            'tool'      => $tool,
            'confirm'   => self::TOOLS[$tool]['confirm'],
            'reason'    => 'proposal recorded for review',
        ];
    }
}

Selbst wenn eine indirekte Injection gelingt und das Modell send_email an einen vom Angreifer gewählten Empfänger vorschlägt, hält die Grenze: Ohne einen Freigabeschritt steht die Aktion nicht in der Allowlist der Anwendung, der Code weigert sich also, sie als endgültig zu behandeln. Die Injection manipuliert den Vorschlagenden, nicht den Torwächter. Der Torwächter ist gewöhnlicher, langweiliger, überprüfbarer Code im Besitz des Entwicklers.

Das bedeutet nicht, alles freizugeben. Reine Leseaktionen mit enger Argument-Allowlist dürfen laufen; Schreibaktionen, die über die Anwendung hinausreichen, sind der Ort, an dem sich die Freigabe bezahlt macht. Die genaue Aufteilung hängt davon ab, was die Anwendung tut — und das entscheidet ihr Betreiber, nicht das Modell.

Unsicherheit und offene Fragen

Seien wir ehrlich über die Grenzen dessen, was dieser Artikel behauptet. Für Prompt Injection gibt es keine allgemein anerkannte, garantierte Verteidigung; jede Maßnahme reduziert die Gefährdung und erhöht die Kosten für den Angreifer, statt das Problem zu schließen. Willison schrieb 2023, er habe noch keine robuste Verteidigung gesehen, die garantiert zu hundert Prozent funktionierte, und sein Kommentar von 2025 deutet an, dass sich daran grundlegend nichts geändert hat. Behandle jedes Framework, auch dieses, als Ausgangspunkt für dein eigenes Bedrohungsmodell.

Zwei offene Fragen verdienen es, festgehalten zu werden. Erstens: Wie viel Handlungsmacht (Agency) soll eine Automatisierung zugestanden bekommen? Jedes zusätzliche Tool ist ein neuer Weg, auf dem eine injizierte Anweisung eine Wirkung entfalten kann; die billigste Maßnahme ist oft, das Tool ganz zu entfernen. Zweitens: Ist Sandboxing die eigentliche Antwort? Wenn man das Modell als unvertrauenswürdige Software behandelt und es in einer Umgebung ohne Privilegien jenseits eines Wegwerf-Workers einschließt, verändert das den schlimmsten Fall von „voller Zugriff" zu „einem beherrschbaren Schritt". Auf beide Fragen gibt es keine universelle Antwort — genau deshalb gehören sie in ein Designgespräch und nicht in einen Prompt.

Fazit

Prompt Injection ist kein Bug, den eine bessere Anweisungsfolge behebt. Sie ist die Folge einer Anwendung, die Text zugleich als Daten und als Anweisungen wirken lässt. Die ehrliche Antwort ist architektonisch: Trenne beides, halte das Modell außerhalb seiner erklärten Rolle machtlos, validiere Ausgaben mit deterministischem Code, und lasse Entscheidungen, die wichtig sind, von jemand anderem als dem Modell freigeben. Der Satz „eine Anweisung ist keine Sicherheitsgrenze" fasst diese Position zusammen. Der Prompt schlägt vor; die Anwendung entscheidet.

References

1. OWASP GenAI Security Project — LLM01:2025 Prompt Injection. OWASP Foundation. Abgerufen am 23. September 2026. Primärquelle (Community-Sicherheitsstandard).
2. Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz and Mario Fritz — Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. arXiv:2302.12173 (2023). Abgerufen am 23. September 2026. Primärquelle (akademisches Paper).
3. Simon Willison — Prompt injection: What's the worst that can happen?. 14. April 2023. Abgerufen am 23. September 2026. Sekundärquelle/technischer Experte.
4. Simon Willison — Why AI systems might never be secure. 23. September 2025 (Linkbeitrag, der The Economist zitiert). Abgerufen am 23. September 2026. Sekundärquelle/technischer Experte.