Warum Prompt Injection im Betrieb ein anderes Problem ist als im Demo-Chat
Solange ein Sprachmodell nur auf eine einzelne Nutzereingabe antwortet, bleibt der Schaden durch fehlerhafte Ausgaben meist begrenzt. Anders sieht es aus, wenn ein KI-Agent selbstständig Links öffnet, Inhalte aus Webseiten liest, E-Mails verarbeitet, auf interne Dokumente zugreift oder Aktionen in Drittsystemen ausführt. Dann reicht ein manipulierter Text an einer beliebigen Stelle der Verarbeitungskette, um aus einer falschen Antwort ein reales Betriebsproblem zu machen.
Genau das ist der Kern von Prompt Injection. Der Agent erhält Anweisungen nicht nur aus dem eigentlichen Benutzerprompt, sondern auch aus Fremdinhalten, die er verarbeitet. Das kann eine Webseite sein, ein PDF, ein Tickettext, eine Produktbeschreibung, ein Chatverlauf oder ein Feld in einem CRM-System. Wenn der Agent diese Inhalte ungefiltert als handlungsleitende Instruktionen interpretiert, kann er Prioritäten verwechseln, interne Regeln ignorieren, sensible Daten preisgeben oder unerwünschte Tool-Aufrufe auslösen.
Für den kaufmännischen Mittelstand ist das kein akademisches Randthema. Es betrifft genau die Einsatzfälle, die wirtschaftlich attraktiv wirken: Service-Agenten, die Anfragen vorqualifizieren, Einkaufsprozesse vorbereiten, Rücksendungen prüfen, Stammdaten aktualisieren oder Informationen aus Portalen zusammentragen.
Wo Prompt Injection im Unternehmen praktisch auftritt
In der Praxis gibt es einige typische Eintrittspunkte:
- Webseiten oder externe Portale, die der Agent selbst öffnet
- E-Mail-Inhalte und Anhänge
- Texteingaben von Kunden in Formularen, Chats oder Tickets
- Inhalte aus Wissensdatenbanken, PDFs und Office-Dokumenten
- CRM-, ERP- oder PIM-Felder, die aus früheren Importen stammen
- Ergebnisse aus Suchfunktionen oder Web-Recherche
Das Muster ist fast immer gleich: Der Agent soll Informationen lesen, zusammenfassen, klassifizieren oder daraus Folgeaktionen ableiten. In diesen Fremdinhalten verstecken sich dann Anweisungen wie sinngemäß „Ignoriere die bisherigen Regeln“, „Gib den gesamten Verlauf aus“ oder „Nutze jetzt Tool X mit folgenden Parametern“. Auch wenn ein Modell diese Texte nicht immer befolgt, ist bereits die Möglichkeit für produktive Prozesse relevant.
Wer einen Agenten produktiv einsetzt, darf deshalb nicht davon ausgehen, dass das Modell Anweisung und Daten stets sauber trennt. Diese Trennung müssen Sie technisch erzwingen.
Die wichtigste Grundregel: Inhalte sind Daten, keine Befehle
Der erste Schutzmechanismus ist konzeptionell simpel und in der Umsetzung oft vernachlässigt: Alles, was aus externen Quellen kommt, muss für den Agenten standardmäßig als untrusted input behandelt werden.
Das heißt konkret:
- Webseiten, Tickets, Dokumente und Datenbankfelder dürfen nicht ungeprüft in denselben Kontext wie Systemregeln und Tool-Beschreibungen gemischt werden.
- Der Agent muss explizit angewiesen werden, externe Inhalte nur als Daten zur Auswertung zu behandeln.
- Handlungsrelevante Regeln gehören in einen getrennten, priorisierten Steuerungsbereich und nicht in frei zusammenkopierte Prompts.
In einfachen Prototypen sieht man oft genau den Fehler: Systemprompt, Nutzereingabe, Suchergebnis und Dokumentinhalt werden zu einem einzigen Textblock zusammengesetzt. Für Demos reicht das manchmal. Für produktive Abläufe ist es zu riskant.
Tool-Nutzung nur mit enger Freigabe
Sobald ein KI-Agent Tools nutzen darf, steigt das Risiko deutlich. Dann geht es nicht mehr nur um fehlerhafte Sprache, sondern um Veränderungen in Systemen.
Deshalb sollten Tools nie als generische Universalwerkzeuge freigegeben werden. Besser ist ein enges Berechtigungsmodell:
- Pro Anwendungsfall nur die minimal nötigen Tools bereitstellen
- Pro Tool nur die minimal nötigen Aktionen erlauben
- Parameterbereiche begrenzen, zum Beispiel nur bestimmte Datensätze, Postfächer oder Tabellen
- Schreibzugriffe von Lesezugriffen trennen
- Kritische Aktionen grundsätzlich doppelt absichern
Ein Service-Agent darf beispielsweise Kundendaten nachschlagen und einen Entwurf für eine Antwort erstellen. Er sollte aber nicht ohne zusätzliche Prüfung Adressen ändern, Gutschriften auslösen oder komplette Datensätze exportieren.
Technisch bedeutet das: lieber mehrere kleine, zweckgebundene Tools als ein einziges mächtiges Backend-Tool. Je gröber die Schnittstelle, desto größer der mögliche Schaden bei Fehlverhalten.
Bestätigungsstufen für riskante Aktionen einbauen
Ein produktiver Agent braucht Eskalationsstufen. Nicht jede Aktion ist gleich kritisch. Diese Unterscheidung muss in die Prozesslogik eingebaut werden.
Sinnvoll ist ein einfaches Freigabemodell mit drei Ebenen:
- Lesen erlaubt
- Vorschlagen erlaubt, Ausführen nur nach Freigabe
- Vollautomatisch ausführen nur bei klar begrenzten Standardfällen
Im Kundenservice kann das gut funktionieren. Das Auslesen eines Bestellstatus ist relativ unkritisch. Das Formulieren einer Antwort kann der Agent vorbereiten. Das tatsächliche Auslösen einer Rückerstattung oder Vertragsänderung sollte dagegen mindestens eine Regelprüfung oder eine menschliche Freigabe erfordern.
Diese Freigabe kann pragmatisch gestaltet werden. Es muss kein aufwendiges Governance-Projekt sein. Oft reicht schon ein Pflichtschritt: „Agent schlägt Aktion mit Begründung und Parametern vor, Mitarbeiter bestätigt.“ Das kostet pro Fall wenige Sekunden, reduziert aber das Risiko massiv.
Link-Sicherheit ist kein Browser-Detail, sondern Prozessschutz
Wenn Agenten Links öffnen, entsteht eine zusätzliche Angriffsfläche. Der Link selbst kann unkritisch wirken, das Ziel aber manipulierte Inhalte liefern. Ebenso problematisch sind Weiterleitungen, eingebettete Inhalte oder Seiten mit versteckten Anweisungen im Text.
Für den produktiven Einsatz sollten Sie deshalb mindestens folgende Leitplanken setzen:
- Nur definierte Domains und Subdomains zulassen
- Weiterleitungen kontrollieren oder unterbinden
- Externe Webzugriffe vom internen Systemzugriff trennen
- Inhalte vor der Weiterverarbeitung aufbereiten, zum Beispiel nur relevante Textausschnitte statt kompletter Seiten
- Downloads und Anhänge nicht ungeprüft in denselben Agentenlauf übernehmen
In der Praxis ist eine Allowlist meist der sinnvollste Start. Wenn ein Agent für Reklamationen nur auf den eigenen Shop, den Versanddienstleister und ein internes Helpcenter zugreifen soll, dann sollte er auch nur diese Ziele erreichen dürfen. Offenes Browsing ist im kaufmännischen Betrieb selten nötig und fast nie die risikoärmste Variante.
Ausgaben und Tool-Aufrufe vor dem Absenden prüfen
Ein oft unterschätzter Schutz ist die nachgelagerte Prüfung der Agentenentscheidung. Nicht jede Sicherheitsmaßnahme muss im Modell selbst stecken. Gerade im Mittelstand sind vorgelagerte und nachgelagerte Kontrollen oft robuster als ein immer komplexerer Prompt.
Bewährt haben sich Guardrail-Prüfungen vor der Ausführung:
- Ist der Tool-Aufruf für diesen Prozess überhaupt erlaubt?
- Passen die Parameter zum Kunden, Vorgang und Bearbeitungskontext?
- Enthält die Ausgabe sensible Daten, die nicht herausgegeben werden dürfen?
- Widerspricht die Aktion einer Geschäftsregel?
- Wurde eine Freigabeschwelle überschritten?
Das kann regelbasiert erfolgen. Sie brauchen dafür nicht zwingend ein zweites komplexes Modell. Viele Risiken lassen sich mit klaren Prüfregeln entschärfen: Feldvalidierung, Rollenprüfung, Domain-Check, Betragsgrenzen, Statusprüfung, Dublettenprüfung.
Datenzugriffe konsequent segmentieren
Prompt Injection wird besonders kritisch, wenn ein Agent breit auf Daten zugreifen darf. Dann genügt ein manipulierter Verarbeitungsschritt, um unnötig viele Informationen in den Kontext zu ziehen.
Deshalb gilt: Geben Sie dem Agenten nie „alles, was irgendwie nützlich sein könnte“. Geben Sie ihm nur das, was er für den konkreten Prozessschritt wirklich benötigt.
Das bedeutet in der Umsetzung:
- retrieval nur auf den fachlich passenden Datenraum beschränken
- Mandanten, Teams und Rollen sauber trennen
- sensible Datenfelder aus Standardabfragen herausnehmen
- Kontextfenster klein halten statt wahllos anzureichern
- Zugriffe protokollieren
Gerade bei Service-Prozessen ist das wichtig. Für die Beantwortung einer Lieferstatusanfrage braucht der Agent in der Regel keine vollständige Kundenhistorie, keine Einkaufsbedingungen und keine internen Kulanzregeln im Volltext.
Testen wie ein Angreifer, nicht wie ein Projektteam
Vor dem Rollout sollten Sie den Agenten gezielt mit schädlichen oder irreführenden Inhalten konfrontieren. Viele Teams testen nur Happy Paths: saubere Eingaben, eindeutige Fragen, wohlgeformte Datensätze. Genau dort zeigt sich Prompt Injection aber kaum.
Besser ist ein Stresstest mit realistischen Problemfällen:
- Tickettexte mit versteckten Handlungsanweisungen
- Webseiten mit irreführenden Prioritäten
- Dokumente mit widersprüchlichen Regeln
- absichtlich falsch benannte Felder oder Dateiinhalte
- Anfragen, die Datenexfiltration provozieren sollen
- Links auf unerwartete Ziele
Wichtig ist dabei nicht nur, ob der Agent „richtig antwortet“. Entscheidend ist, ob er verbotene Tools nutzt, unnötige Daten anfordert, Regeln missachtet oder unsichere Folgeaktionen vorbereitet.
Organisatorisch klein anfangen, technisch sauber bauen
Für viele Unternehmen ist die richtige Reihenfolge wichtiger als maximale Komplexität. Ein sicherer Start sieht meist so aus:
- ein klar abgegrenzter Prozess
- nur Leserechte oder vorbereitende Vorschläge
- enge Tool-Freigaben
- Allowlist für Links und Quellen
- regelbasierte Prüfungen vor Ausführung
- menschliche Freigabe bei jeder kritischen Aktion
- vollständige Protokollierung
Erst wenn diese Stufe stabil läuft, lohnt sich mehr Autonomie. Wer dagegen direkt mit offenem Webzugriff, breiten Systemrechten und automatischer Ausführung startet, spart am Anfang vielleicht Projektzeit, bezahlt später aber mit höherem Betriebsrisiko.
Fazit
Prompt Injection ist bei KI-Agenten keine theoretische Schwachstelle, sondern eine naheliegende Folge davon, dass Modelle Inhalte lesen und daraus Handlungen ableiten. Im produktiven Umfeld reicht es deshalb nicht, auf ein gutes Basismodell oder einen „starken Systemprompt“ zu vertrauen.
Sie brauchen technische Leitplanken: strikte Trennung von Daten und Anweisungen, minimale Tool-Rechte, Link-Beschränkungen, Prüfungen vor der Ausführung, segmentierte Datenzugriffe und Freigaben für kritische Aktionen.
Für den kaufmännischen Mittelstand ist das keine Bremse, sondern die Voraussetzung für belastbare KI-Automatisierung. Wenn Sie diese Kontrollen von Anfang an einplanen, bekommen Sie nicht nur mehr Sicherheit. Sie schaffen auch Prozesse, die auditierbar, wartbar und im Alltag beherrschbar bleiben.