Die Antwort vorweg: Ein KI-Agent ist kein Chatbot – er ist ein Programm, das für Sie Aktionen ausführt: E-Mails liest, Rechnungen anlegt, Dateien speichert und Kunden antwortet. Bei einer Prompt Injection befindet sich in den Daten, die der Agent verarbeitet – etwa in einer eingehenden E-Mail, einer PDF-Datei oder auf einer Webseite – ein als Anweisung formulierter Text. Ohne entsprechende Schutzmaßnahmen kann der Agent diese Anweisung ausführen, weil Instruktionen und Daten über denselben Kanal zu ihm gelangen. OWASP führt Prompt Injection auf Platz eins seiner Risikoliste für Anwendungen auf Basis von Sprachmodellen. Cybersicherheitsbehörden weisen zudem darauf hin, dass sich diese Eigenschaft nicht vollständig beseitigen lässt. Die Abwehr beruht deshalb nicht darauf, den Agenten zu „überzeugen“, sondern auf vier Maßnahmen außerhalb des Modells: minimale Berechtigungen – der Agent sieht nicht mehr als die Person, die er vertritt –, menschliche Bestätigung sensibler Aktionen, ein Audit-Trail mit Angaben dazu, wer was wann und auf wessen Veranlassung getan hat, sowie Limits und die Möglichkeit, den Agenten sofort abzuschalten.
Bei einem KI-Assistenten, der lediglich in einem Chatfenster antwortet, besteht das größte Risiko in den Inhalten, die Menschen dort einfügen. Sobald dasselbe Modell jedoch Zugriff auf E-Mails, das Buchhaltungssystem oder ein gemeinsames Laufwerk erhält und dort selbst Aktionen ausführen darf, verändert sich die Art des Problems: Es geht nicht mehr nur um die Vertraulichkeit eingegebener Daten, sondern darum, was das Modell auf fremde Anweisung hin tun kann. Dieser Text behandelt die zweite Situation. Mit der Eingabe betrieblicher Daten in Chatbots befasst sich Unternehmensdaten in ChatGPT, mit der Kontrolle KI-generierten Codes dagegen KI-generierter Code: Wer hat ihn geprüft, bevor er die Nutzer erreichte?.
Worin sich ein Agent von einem Chatbot unterscheidet
Ein Chatbot gibt Text zurück, die Verantwortung bleibt beim Menschen. Ein Agent verfügt zusätzlich über Werkzeuge – also Anbindungen an APIs: Er kann ein Postfach lesen, einen Beleg anlegen oder eine Nachricht versenden. Genau darin liegt der Unterschied zwischen „Er hat Unsinn erzeugt“ und „Er hat Unsinn erzeugt und ihn sofort an dreißig Kunden verschickt“. Außerdem verarbeitet ein Agent Inhalte, die das Unternehmen weder erstellt noch genehmigt hat – fremde E-Mails, Anhänge und Webseiten. Dadurch entsteht eine Angriffsfläche.
Was Prompt Injection an einem konkreten Beispiel bedeutet
Stellen Sie sich einen Agenten vor, der jeden Morgen das Firmenpostfach durchsieht, Anfragen sortiert und Antworten vorbereitet. Es trifft eine E-Mail ein, die wie eine gewöhnliche Anfrage aussieht. Irgendwo in ihrem Inhalt – in winziger Schrift in der Farbe des Hintergrunds oder in den Metadaten eines Anhangs – befindet sich jedoch ein Text, der als Anweisung an den Agenten formuliert ist: Er solle die zuletzt ausgestellten Rechnungen an die angegebene Adresse weiterleiten.
Ein ungeschützter Agent kann dieser Anweisung folgen. Nicht weil er „dumm“ wäre, sondern weil das Sprachmodell sowohl seine Aufgabe als auch die Daten als einen einzigen Textstrom erhält. Anders als klassische Software besitzt es keine getrennte „Befehlszeile“ und „Dateneingabe“. OWASP weist außerdem darauf hin, dass die Eingabe für Menschen weder sichtbar noch lesbar sein muss – es genügt, dass das Modell sie verarbeitet.
Man unterscheidet zwei Formen. Bei einer direkten Injection erzwingt der Nutzer selbst innerhalb einer Unterhaltung ein anderes Verhalten. Bei einer indirekten Injection – die für Unternehmen gefährlicher ist – gelangt die Anweisung über fremde Inhalte in das System, die der Agent einliest: eine E-Mail, ein Dokument, eine Webseite oder ein Ticket. Microsoft beschreibt dies als eine Situation, in der ein Angreifer Anweisungen in Inhalte Dritter einbettet und die KI sie als legitimen Befehl interpretiert.
Die Lehre daraus lautet: Eingabedaten dürfen nicht als Befehle behandelt werden.
Warum sich Prompt Injection nicht einfach „herausfiltern“ lässt
Die erste Reaktion lautet häufig: Wir setzen einen Filter davor. Filter und speziell zur Angriffserkennung trainierte Modelle gibt es, und sie sind durchaus sinnvoll – eine undurchdringliche Schutzmauer bilden sie jedoch nicht. Das britische NCSC erklärt in seiner Stellungnahme zur Einführung von Agenten ausdrücklich, dass sich Schutzmaßnahmen auf Vorkehrungen außerhalb des Modells konzentrieren sollten. Diese begrenzen, was das System überhaupt tun kann. Ein Modell, das beispielsweise E-Mails fremder Absender verarbeitet, sollte keinen Zugriff auf privilegierte Werkzeuge haben. Microsoft empfiehlt, das System unter der Annahme zu entwickeln, dass ein Teil der Angriffe erfolgreich sein wird, und die Schutzmaßnahmen so zu staffeln, dass der mögliche Schaden gering bleibt. Gesucht wird also nicht der perfekte Filter. Stattdessen braucht es ein System, in dem selbst eine erfolgreiche Injection keinen Schaden anrichten kann, weil der Agent nicht über die erforderlichen Rechte verfügt und sensible Aktionen ohnehin von einem Menschen freigegeben werden müssen.
Minimale Berechtigungen: Ein Agent darf nicht mehr Rechte haben als die Person, die er vertritt
Dies ist die günstigste wirksame Maßnahme, die einem kleinen Unternehmen zur Verfügung steht. Ein Agent, der Rechnungen vorbereitet, muss Bestellungen, Preislisten und Kontaktdaten sehen können – nicht aber Gehälter, Personalakten oder Sicherungskopien. Wenn er darauf keinen Zugriff hat, spielt es keine Rolle, wie geschickt jemand ihn zu überreden versucht: Er kann diese Daten nirgendwoher beschaffen.
OWASP führt Excessive Agency, also übermäßige Handlungsfähigkeit, als eigenständiges Risiko auf und unterteilt es in unnötige Funktionen – der Agent besitzt Werkzeuge, die er für seine Arbeit nicht benötigt, häufig weil eine fertige Komplettintegration eingesetzt wurde –, unnötige Berechtigungen – das Werkzeug verfügt im Zielsystem über mehr Rechte, als die Aufgabe erfordert – und unnötige Autonomie – bei Aktionen mit großer Tragweite fehlt ein Kontrollschritt. Für den Betrieb in einem kleinen Unternehmen bedeutet das konkret:
- Trennen Sie Lese- und Schreibzugriff. Eine Rolle mit reinen Leserechten sammelt die benötigten Informationen; für Schreibvorgänge gibt es eine eigene, eng begrenzte Rolle.
- Legen Sie die erlaubten Werkzeuge ausdrücklich fest. Eine Positivliste wie „darf einen Beleg anlegen und bearbeiten“ ist sicherer als eine Verbotsliste – was nicht darauf steht, ist nicht möglich.
- Erzwingen Sie Berechtigungen im Zielsystem. Was erlaubt ist, entscheidet nicht der Text des Prompts, sondern das Buchhaltungssystem, der Datei- oder der Mailserver – also eine Ebene, die das Modell nicht beeinflussen kann.
- Verwenden Sie kein Administratorkonto. Ein Agent mit Rechten für das gesamte Netzwerk ist die häufigste Abkürzung in Pilotprojekten und zugleich der größte Fehler, den man dabei machen kann.
Welche Aktionen immer von einem Menschen bestätigt werden müssen
Human-in-the-Loop bedeutet, dass zwischen der Entscheidung des Agenten und ihrer Ausführung ein menschliches „Ja“ steht. Microsoft bezeichnet dies als letzte Verteidigungslinie; OWASP empfiehlt eine menschliche Freigabe für Aktionen mit großer Tragweite. Dazu gehören fünf Kategorien:
- Geldbewegungen – Zahlungsaufträge, Änderungen der Bankverbindung eines Lieferanten, Gutschriften;
- Löschungen und irreversible Änderungen – das Löschen eines Belegs, einer Datei oder eines Datensatzes;
- Massenkommunikation – der gleichzeitige Versand einer E-Mail an mehrere Empfänger;
- Datenübertragung nach außen – Exporte, die Weiterleitung eines Anhangs außerhalb des Unternehmens oder die Freigabe eines Ordners;
- Änderungen von Berechtigungen – das Hinzufügen eines Kontos, die Erweiterung eines Zugriffs oder das Abschalten einer Kontrolle.
Eine solche Bestätigung muss eine Voraussetzung erfüllen: Der Mensch muss sehen, was konkret passieren wird – an wen, in welcher Höhe und mit welcher Datei. Ein bloßer Dialog mit der Frage „Stimmen Sie zu?“ reicht nicht aus. Ein Fenster ohne konkrete Angaben wird nach einer Woche blind bestätigt und dient dann nur noch als Alibi.
Audit-Trail: wer, was, wann und auf wessen Veranlassung
Ein Audit-Trail ist ein Protokoll, anhand dessen sich im Nachhinein rekonstruieren lässt, was der Agent getan hat. Häufig erfahren Sie erst dadurch überhaupt, dass etwas passiert ist.
Microsoft benennt in seinem Leitfaden zu minimalen Berechtigungen für Agenten eine typische Schwachstelle: Protokolle erfassen oft nur die Antwort im Chat, nicht aber die tatsächlichen Werkzeugaufrufe, Berechtigungsumfänge und Entscheidungen nachgelagerter Systeme. Ein solches Protokoll ist für eine Untersuchung nutzlos. Ein brauchbarer Datensatz enthält Angaben darüber, wer gehandelt hat – die Identität des Agenten über ein eigenes Konto statt eines gemeinsam genutzten Passworts –, auf wessen Veranlassung die Aktion erfolgte – welcher Mensch oder welches Ereignis sie ausgelöst hat –, was geschehen ist – die aufgerufene Operation und ihre Parameter statt nur des Antworttextes –, wann es geschah, mit welcher Berechtigung, mit welchem Ergebnis sowie eine gemeinsame ID für den gesamten Durchlauf, damit sich die Abfolge der einzelnen Schritte rekonstruieren lässt.
Einen Teil dieser Arbeit übernehmen die Plattformbetreiber. Microsoft führt in seinem Auditprotokoll separate Ereignisse für den Start eines Agenten, den Aufruf eines Werkzeugs und das Eingreifen eines Schutzmechanismus. Es muss jedoch geprüft werden, ob diese Protokollierung aktiviert ist und die Daten ausreichend lange aufbewahrt werden.
Limits, getrennte Umgebungen und Notausschalter
Die letzte Schutzebene begrenzt den Schaden im zeitlichen Verlauf. OWASP empfiehlt, die Anzahl der Aktionen pro Zeiteinheit zu beschränken. Das NCSC rät dazu, Agenten nur für möglichst kurze Zeit den minimal erforderlichen Zugriff zu gewähren und ungewöhnliches Verhalten zu überwachen. Ein Aktionslimit legt fest, wie viele Belege, E-Mails oder Dateien der Agent pro Stunde verarbeiten darf. Wird es überschritten, muss der Agent anhalten und eine Warnung auslösen, statt unbemerkt weiterzuarbeiten. Eine getrennte Umgebung bedeutet, dass der Agent unter einem eigenen Konto und in einem eigenen Netzwerksegment läuft, von dem aus er den übrigen Teil des Netzwerks nicht erreichen kann. Zeitlich begrenzte Rechte gelten nur für die Dauer der jeweiligen Aufgabe. Ein Notausschalter ist ein erprobter Weg, den Agenten unverzüglich anzuhalten und seine Anmeldedaten ungültig zu machen. Das NCSC formuliert es unmissverständlich: Was Sie nicht verstehen, überwachen und stoppen können, ist nicht bereit für den Einsatz.
Die Grundlage all dessen ist gewöhnliche IT-Hygiene. Ein Agent, der Daten in ein System schreiben darf, ist ein weiterer Grund für ein getestetes Backup-Konzept – die Wiederherstellung ist die einzige zuverlässige Antwort auf fehlerhafte Massenänderungen. Wo sich die Daten während der Verarbeitung befinden, erläutert KI ohne Cloud: Welche Bereiche das eigene Netzwerk nicht verlassen dürfen.
Ein Agent gehört wie ein Mitarbeiter in die Zugriffsverwaltung
Ein hilfreiches Modell für Unternehmensinhaber: Ein Agent mit Datenzugriff ist ein weiterer Eintrag in der Zugriffsverwaltung. Er besitzt eine eigene Identität, einen benannten Verantwortlichen für sein Verhalten, einen klar abgegrenzten Berechtigungsumfang und einen Termin für die nächste Überprüfung. Daraus ergeben sich Pflichten, die Sie bei Menschen bereits selbstverständlich erfüllen: Ändert sich ein Prozess, werden die Zugriffsrechte neu bewertet; wird ein Agent außer Betrieb genommen, werden seine Zugänge einschließlich Token und Schlüssel widerrufen; bei der jährlichen Kontrolle werden auch Agenten überprüft. Und Berechtigungen sammeln sich genauso an wie bei Menschen: Was für ein Pilotprojekt „nur vorübergehend“ erweitert wurde, bleibt bestehen, bis es jemand wieder entzieht.
Fragen, die Sie dem Anbieter eines KI-Agenten stellen sollten
Nehmen Sie diese Tabelle mit zum Gespräch. „Das übernimmt unser Modell“ ist keine Antwort.
| Frage | Warum Sie danach fragen sollten | Eine überzeugende Antwort |
|---|---|---|
| Welche Berechtigungen erhält der Agent und auf welche Systeme darf er zugreifen? | Der Berechtigungsumfang bestimmt die Obergrenze des möglichen Schadens. | Eine konkrete Liste der Systeme, Rollen und Berechtigungsumfänge; getrennte Lese- und Schreibrechte; kein Administratorkonto. |
| Was genau wird protokolliert und wo befindet sich dieses Protokoll? | Ohne Aufzeichnung der ausgeführten Aktionen lässt sich ein Vorfall nicht untersuchen. | Identität, Anweisung, Operation, Zeitpunkt, Berechtigung und Ergebnis; außerhalb des Agenten gespeichert und mit festgelegter Aufbewahrungsdauer. |
| Was passiert, wenn der Agent einen Fehler macht oder eine manipulierte Anweisung erhält? | Die Antwort zeigt, ob der Anbieter mit einem möglichen Versagen rechnet. | Begrenzung des Schadens, Stopp bei Anomalien, Benachrichtigung eines Menschen und ein Verfahren zur Behebung. |
| Welche Aktionen werden von einem Menschen bestätigt und wie sieht diese Bestätigung aus? | Ohne Bestätigung gelangt ein Fehler unmittelbar in den laufenden Betrieb. | Benannte Kategorien – Geld, Löschungen, Massenkommunikation, Exporte und Rechteänderungen – sowie eine Bestätigung mit konkreten Angaben zur Aktion. |
| Wo werden die Daten verarbeitet und wer hat darauf Zugriff? | Dies bestimmt, wohin Inhalte aus Rechnungen, Verträgen und E-Mails gelangen. | Verarbeitungsort, namentlich benannte Auftragsverarbeiter, Umgang mit Daten für Trainingszwecke und vertragliche Regelungen. |
| Wie kann ich den Agenten sofort abschalten? | Der Notausschalter darf nicht erst während eines Vorfalls gesucht werden. | Ein getestetes Verfahren zum Stoppen des Agenten und Ungültigmachen seiner Anmeldedaten, einschließlich einer Festlegung, wer es auslösen darf. |
Häufig gestellte Fragen
Wie lässt sich ein Agent einführen, ohne den Betrieb des Unternehmens lahmzulegen?
Beginnen Sie mit einem Pilotprojekt für einen einzelnen Prozess mit geringen Auswirkungen. Der Agent darf zunächst nur lesen und Vorschläge zur Genehmigung vorbereiten. Erst wenn die Aufzeichnungen zeigen, dass seine Vorschläge sinnvoll sind, erhält er Schreibrechte – zunächst für reversible Aktionen und erst ganz zum Schluss für irreversible Vorgänge.
Gilt das auch für ein kleines Unternehmen mit fünf Beschäftigten?
Ja – in mancher Hinsicht sogar noch mehr als für ein großes. Kleine Unternehmen verfügen meist nicht über getrennte Systeme und Rollen, sodass ein einziges Konto auf alles zugreifen kann. Ein Agent, der an ein solches Konto angebunden wird, übernimmt dessen vollständigen Zugriff. Deshalb lohnt es sich, mit der Trennung der Berechtigungen zu beginnen und nicht mit der Technologie.
Ist das Problem nicht bereits gelöst, wenn wir eine bekannte Plattform einsetzen?
Zum Teil schon: Große Anbieter stellen Filter, Auditprotokolle und eigene Identitäten für Agenten bereit. Den Berechtigungsumfang, die erlaubten Werkzeuge, die Regeln für Bestätigungen und die Bereiche Ihres Netzwerks, auf die der Agent zugreifen darf, wird jedoch niemand für Sie festlegen.
Erkennen wir überhaupt, dass jemand eine Injection versucht hat?
Nur wenn die Werkzeugaufrufe protokolliert und ungewöhnliche Verhaltensweisen überwacht werden – etwa der Versuch, auf Bereiche außerhalb des üblichen Umfangs zuzugreifen, oder ein plötzlicher Anstieg der Zahl ausgeführter Aktionen. An der Antwort im Chat allein lässt sich das nicht erkennen.
ITHOPE entwickelt in Brünn und Umgebung KI-Automatisierungen, die sich ohne blindes Vertrauen in das Modell betreiben lassen: mit klar abgegrenzten Berechtigungen, der Bestätigung sensibler Aktionen und einem Audit-Trail, anhand dessen sich im Nachhinein rekonstruieren lässt, was geschehen ist. Welche Prozesse sich für den Einstieg eignen, erläutert KI-Automatisierung für Unternehmen. Informationen zur IT-Verwaltung und Datensicherung sowie zu weiteren Leistungen finden Sie im Bereich IT für Unternehmen. Wenn die Analyse ergibt, dass sich ein bestimmter Prozess derzeit noch nicht für einen Agenten eignet, sagen wir Ihnen das offen.
Quellen
- OWASP Top 10 for LLM Applications – Prompt Injection auf Platz eins (LLM01), übermäßige Handlungsfähigkeit von Agenten als eigenständiger Eintrag.
- OWASP: LLM01 Prompt Injection – direkte und indirekte Injection, für Menschen unsichtbare Eingaben und menschliche Freigabe privilegierter Operationen.
- OWASP: Excessive Agency – unnötige Funktionen, Berechtigungen und Autonomie; Beschränkung der Rechte auf das Minimum, Genehmigung von Aktionen mit großer Tragweite, Protokollierung und Frequenzlimits.
- NCSC: Thinking carefully before adopting agentic AI – Stellungnahme der britischen Behörde vom 15. 5. 2026: minimaler Zugriff für den kürzestmöglichen Zeitraum, temporäre Anmeldedaten und Überwachung des Verhaltens.
- Microsoft: Defend against indirect prompt injection attacks – mehrschichtige Abwehr unter der Annahme, dass ein Teil der Angriffe erfolgreich sein wird; menschliche Bestätigung riskanter Aktionen.
- Microsoft: Least privilege for AI agents – eigene Agentenidentität mit einem Verantwortlichen, auf die Aufgabe beschränkte Rollen, erlaubte Werkzeuge und Inhalt des Auditprotokolls.
- Microsoft Purview: Audit log activities – Auditereignisse für den Start eines Agenten, den Aufruf eines Werkzeugs und das Eingreifen eines Schutzmechanismus.
Wo Sie uns finden
ITHOPE ist eine Firma aus Brno, Tschechien: wir machen Datenrettung von Festplatten, RAID und NAS, PC- und Notebook-Service und IT für Unternehmen, alles im eigenen Labor in der Viniční 3587/216, 615 00 Brno.
Telefon +420 775 556 063 (rund um die Uhr). Das Gerät können Sie persönlich bringen oder per Kurier schicken (Zásilkovna, PPL).