Zurück zum Blog

Prompt Injection bei KI-Agenten: Sicherheitsgrenzen für produktive Workflows

AICybersecuritySoftware ArchitectureGovernance

Prompt Injection bei KI-Agenten wird relevant, sobald ein Agent nicht mehr nur Text erzeugt, sondern Tools nutzt, Daten liest oder Aktionen ausführt. Für wachsende Softwareunternehmen ist das kein Prompt-Problem, sondern eine Architektur- und Governance-Frage: Welche Inhalte darf ein Modell als Anweisung verstehen, und welche nur als untrusted data?

Was Prompt Injection bei KI-Agenten bedeutet

Prompt Injection beschreibt Eingaben, die ein Modell dazu bringen sollen, seine ursprünglichen Anweisungen zu ignorieren, Daten preiszugeben oder unerwünschte Aktionen auszuführen. Bei Agenten kann diese Eingabe direkt vom Nutzer kommen oder indirekt aus E-Mails, Tickets, Webseiten, PDFs oder Datenbankfeldern.

Das Risiko wächst mit jeder Systemintegration:

  • Tool Calls: Ein Support-Agent könnte eine scheinbar harmlose Kundenmail als Anweisung lesen und ein internes Tool falsch verwenden.
  • Retrieval: Bösartige Inhalte in Wissensdatenbanken können Antworten, Empfehlungen oder Freigabeentscheidungen manipulieren.
  • Datenabfluss: Ein Agent mit Zugriff auf CRM, Logs oder Dateien kann sensible Informationen in eine Antwort oder einen externen Tool Call tragen.
  • Rechteausweitung: Wenn Agenten mit technischen Service-Konten arbeiten, wird ein Prompt-Angriff schnell zum IAM-Problem.

Die wichtigste Erkenntnis: Prompt Injection lässt sich nicht zuverlässig durch bessere Formulierungen im System Prompt lösen. Teams brauchen Sicherheitsgrenzen außerhalb des Modells.

Welche Leitplanken Teams klären sollten

Der erste Schritt ist ein klares Vertrauensmodell. Systemanweisungen, Nutzerinhalte, geladene Dokumente, Tool-Antworten und externe Webseiten gehören in unterschiedliche Risikoklassen. Ein Agent darf diese Quellen nicht gleich behandeln.

Praktische Leitplanken sind:

  • Least Privilege: Agenten bekommen nur die Tools und Daten, die für den konkreten Workflow notwendig sind.
  • Explizite Freigaben: Zahlungen, Löschungen, Vertragsänderungen und Kundennachrichten brauchen Human Approval.
  • Kontext-Trennung: Untrusted Content wird als Datenquelle markiert, nicht als neue Anweisung für den Agenten.
  • Output-Kontrollen: Antworten und Tool-Parameter werden validiert, bevor sie an Nutzer oder Systeme gehen.
  • Security-Evals: Prompt-Injection-Fälle gehören in Regressionstests, nicht nur in einmalige Red-Team-Workshops.
agent_security:
  workflow: support-refund
  untrusted_sources: ["customer_email", "uploaded_pdf", "webpage"]
  allowed_tools: ["read_order", "draft_ticket"]
  approval_required: ["refund_payment", "send_customer_email"]
  secrets_in_context: forbidden
  injection_tests: required

Gerade bei MCP-Servern, Browser-Agenten und internen Automatisierungen sollte diese Policy vor der ersten Demo existieren. Danach ist es deutlich schwerer, bereits gewachsene Rechte wieder einzufangen.

Warum das wichtig ist

Prompt Injection ist wirtschaftlich relevant, weil AI Agents an der Grenze zwischen Sprache und Handlung arbeiten. Ein falsch gelenkter Agent verursacht nicht nur eine schlechte Antwort, sondern kann Kundendaten offenlegen, operative Prozesse stören oder Compliance-Nachweise unbrauchbar machen.

Für Produktleitung und Engineering Management geht es deshalb um kontrollierte Skalierung. Agenten können Support, Operations und Entwicklung entlasten, wenn Architektur, IAM, Logging und Review-Prozesse mitwachsen. Ohne diese Grundlagen entstehen Schattenintegrationen, deren Risiken erst sichtbar werden, wenn sie bereits produktiv genutzt werden.

Wer AI Agents einsetzen will, sollte Prompt Injection wie ein Architekturthema behandeln: kleine Berechtigungen, klare Trust Boundaries, überprüfbare Tool Calls und regelmäßige Angriffstests. Eine Architecture & AI Review kann prüfen, ob ein Agenten-Workflow dafür belastbar genug ist.