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 gefaehrlicher, 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 verknuepfe es mit den naechsten Architekturentscheidungen.
Warum Prompt Injection bei Agenten anders ist Bei einem normalen Chatbot kann Prompt Injection zu falschen Antworten fuehren. Das ist schlecht, aber oft begrenzt. Bei einem Agenten kann derselbe Angriff eine Tool-Aktion beeinflussen: E-Mail senden, Datei auslesen, Ticket aendern, CRM-Eintrag ueberschreiben 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 veraendern. OpenAI rahmt Prompt Injection bei Agenten als Social-Engineering-Problem fuer Modelle: Untrusted Text versucht, die Autoritaet von echten Entwickler- oder Nutzeranweisungen zu uebernehmen.
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 fuer 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 gefaehrlich, 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 laengeren Systemprompts zu loesen. 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 koennen Prompt Injection nicht vollstaendig beseitigen. Sie koennen die Qualitaet 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 zusaetzliche Pruefungen 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 hoeher die Klasse, desto staerker muessen Freigabe, Logging, Rate Limit und Input-Validierung sein.
Bei MCP -Tools gehoert Approval direkt in die Architektur. OpenAI dokumentiert fuer 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 ausfuehren. Schreiben: Systemzustand veraendern. Extern senden: Daten oder Nachrichten nach aussen geben. Loeschen 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 fuer `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 prueft, ob daraus ein Tool Call entstehen darf. 3. Riskante Tool Calls gehen in Review oder Dry-Run.
So bleibt der Agent nuetzlich, aber die fremde Quelle bekommt keine direkte Kontrolle ueber Tools.
Testfaelle fuer Prompt Injection Ein Sicherheitsmodell ist erst glaubwuerdig, wenn es getestet wird. Gute Testfaelle enthalten:
Diese Faelle gehoeren 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 ueber 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 fuer Inputs und Outputs. Policy-Check vor Tool Calls. Approval fuer sensitive Aktionen. Allowlist fuer erlaubte Tools und Ziele. DLP oder Sensitive-Data-Checks vor externem Versand. Monitoring fuer ungewoehnliche 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, ausfuehren. Je naeher ein Agent an Geld, Kundendaten oder rechtlich relevanten Entscheidungen arbeitet, desto enger muessen Rechte, Evals und Freigaben werden.
