AI Security · 10 Min.
Prompt Injection bei KI-Agenten: Die Bedrohung, die erst mit Tool-Zugriff richtig teuer wird
Prompt Injection ist bei Chatbots aergerlich. Bei Agenten mit Tools, Daten und Schreibrechten wird sie ein Architekturproblem.
SYSTEMS Grafik zu Prompt Injection Schutz KI Agenten: Risk -> Guardrail -> Audit. Fokus: Wie Unternehmen KI-Agenten gegen Prompt Injection und Tool-Missbrauch absichern.
Kurzfassung
Prompt Injection wird gefährlicher, sobald ein Modell Tools nutzen kann. Schutz entsteht nicht durch einen perfekten Systemprompt, sondern durch Rechte, Trennung, Freigaben und Logging. Unternehmen brauchen ein Sicherheitsmodell pro Tool, Datenquelle und Aktion.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum Prompt Injection bei Agenten anders ist Bei einem normalen Chatbot kann Prompt Injection zu falschen Antworten führen. Das ist schlecht, aber oft begrenzt. Bei einem Agenten kann derselbe Angriff eine Tool-Aktion beeinflussen: E-Mail senden, Datei auslesen, Ticket ändern, CRM-Eintrag überschreiben oder interne Daten zusammenfassen.
Der Unterschied ist nicht das Modell. Der Unterschied ist die Wirkungskette nach dem Modell.
Stand Mai 2026: Prompt Injection ist ein Systemproblem OWASP beschreibt Prompt Injection als Risiko, bei dem Eingaben das Verhalten eines LLM in unbeabsichtigte Richtungen verändern. OpenAI rahmt Prompt Injection bei Agenten als Social-Engineering-Problem für Modelle: Untrusted Text versucht, die Autorität von echten Entwickler- oder Nutzeranweisungen zu übernehmen.
Das bedeutet: Der Schutz kann nicht nur aus "besseren Prompts" bestehen. Er muss die Wirkungskette begrenzen, selbst wenn das Modell eine manipulative Anweisung teilweise falsch einordnet.
NIST nutzt für verwandte Agentenangriffe den Begriff Agent Hijacking: externe Inhalte bringen einen Agenten dazu, ein Ziel zu verfolgen, das nicht vom Nutzer kommt. Genau das ist bei Tool-Agenten der operative Kern des Problems.
Direkte und indirekte Angriffe Direkte Prompt Injection kommt vom Nutzer: "Ignoriere alle Regeln." Indirekte Prompt Injection versteckt sich in Daten, die der Agent liest: einer Webseite, einem Dokument, einem Support-Ticket oder einem CRM-Feld.
Gerade indirekte Angriffe sind gefährlich, weil der Agent die manipulierte Information als Kontext behandelt. Er glaubt, er liest Arbeitsmaterial. In Wirklichkeit liest er einen Befehl.
Das falsche Schutzversprechen Viele Teams versuchen, Prompt Injection mit längeren Systemprompts zu lösen. Das hilft etwas, reicht aber nicht. Ein Modell bleibt ein Modell. Es kann Regeln falsch priorisieren, Kontext falsch einordnen oder Anweisungen aus Daten mit Arbeitsanweisungen verwechseln.
Sicherheit muss deshalb ausserhalb des Prompts entstehen: durch Tool-Berechtigungen, Datenklassifizierung, Freigabegrenzen und nachvollziehbare Entscheidungen.
OpenAI warnt konkret davor, untrusted Input in Developer Messages zu schreiben, weil diese in der Instruktionshierarchie besonders stark sind. Anthropic warnt gleichzeitig, Prompt-Leak-Schutz nicht durch immer komplexere Prompts zu erzwingen, weil das andere Aufgaben verschlechtern kann.
Die Schlussfolgerung ist hart: Prompt Engineering ist kein Security Boundary.
OWASP sagt denselben Punkt praktisch: RAG und Fine-Tuning können Prompt Injection nicht vollständig beseitigen. Sie können die Qualität verbessern, aber sie ersetzen keine Trennung von Daten, Instruktionen, Rechten und Actions.
Ein praktisches Schutzmodell Ein belastbares Modell trennt vier Ebenen:
Der Agent darf untrusted Input lesen, aber nicht daraus neue Systemregeln ableiten. Schreibende Tools sollten immer zusätzliche Prüfungen haben.
Untrusted Input: Webseiten, Kundenmails, Uploads, fremde Dokumente. Trusted Policy: Regeln, die nicht aus Nutzerdaten kommen. Tool Permission: Welche Aktion ist ohne Freigabe erlaubt? Runtime Audit: Was hat der Agent warum getan? Tool-Grenzen sind der wichtigste Schutz Prompt Injection wird teuer, wenn ein Agent nach der manipulierten Anweisung handeln kann. Deshalb muss jedes Tool eine Risiko-Klasse haben:
Je höher die Klasse, desto stärker müssen Freigabe, Logging, Rate Limit und Input-Validierung sein.
Bei MCP -Tools gehört Approval direkt in die Architektur. OpenAI dokumentiert für MCP Controls wie `require_approval` und `allowed_tools`; MCP Security Best Practices warnen vor Token-Passthrough, zu breiten Scopes und Session-/SSRF-Risiken. Das ist keine Zusatzoption, sondern Betriebsstandard.
Lesen: Informationen abrufen. Entwerfen: Vorschlag erzeugen. Vorbereiten: Aktion technisch vorbereiten, aber nicht ausführen. Schreiben: Systemzustand verändern. Extern senden: Daten oder Nachrichten nach aussen geben. Löschen oder bezahlen: irreversible oder finanzielle Aktion. Untrusted Content darf keine Tool-Parameter besitzen Ein praktischer Fehler: Der Agent liest eine E-Mail und nutzt daraus direkt Tool-Parameter für `send_email`, `update_crm` oder `search_private_docs`. Genau dort kann indirekte Prompt Injection aus Kontext eine Aktion machen.
Besser ist ein zweistufiges Muster:
1. Der Agent extrahiert Fakten aus untrusted Content in ein enges Schema. 2. Eine Policy-Schicht prüft, ob daraus ein Tool Call entstehen darf. 3. Riskante Tool Calls gehen in Review oder Dry-Run.
So bleibt der Agent nützlich, aber die fremde Quelle bekommt keine direkte Kontrolle über Tools.
Testfälle für Prompt Injection Ein Sicherheitsmodell ist erst glaubwürdig, wenn es getestet wird. Gute Testfälle enthalten:
Diese Fälle gehören in Evals, nicht nur in eine einmalige Security-Diskussion.
direkte Jailbreak-Versuche versteckte Anweisungen in Webseiten, PDFs oder Tickets Aufforderungen zur Datenexfiltration falsche Systemrollen in untrusted Text manipulierte Tool-Ausgaben Prompt-Leak-Versuche Cross-Tool-Angriffe über MCP oder externe Server Runtime-Schutz statt Einmalcheck Prompt-Injection-Schutz braucht Laufzeitkontrollen:
Google Model Armor und OpenAI Agent Safety zeigen beide in diese Richtung: Schutz sitzt im Laufzeitpfad, nicht nur im Prompt.
Guardrails für Inputs und Outputs. Policy-Check vor Tool Calls. Approval für sensitive Aktionen. Allowlist für erlaubte Tools und Ziele. DLP oder Sensitive-Data-Checks vor externem Versand. Monitoring für ungewöhnliche Tool-Ketten. Incident-Log mit Run-ID und betroffener Datenquelle. Der SYSTEMS-Blick Prompt Injection ist kein Grund, keine Agenten zu bauen. Es ist ein Grund, Agenten professionell zu bauen.
Wer Autonomie will, braucht Zonen: lesen, vorschlagen, vorbereiten, ausführen. Je näher ein Agent an Geld, Kundendaten oder rechtlich relevanten Entscheidungen arbeitet, desto enger müssen Rechte, Evals und Freigaben werden.
