KI-Agenten: Sicherheit und Risiken im Betrieb

Ein Agent hat die Rechte des Zugangs, mit dem er eingerichtet wurde. Nicht weniger. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt einen KI-Agenten als Softwaresystem, das auf Basis eines Sprachmodells eigenständig Handlungen ausführt, etwa Mails schreiben, Termine eintragen oder Buchungen abschließen, ohne dass jeder Schritt freigegeben wird (BSI, KI-Agenten). Damit verschiebt sich das Risiko von der Aussage zur Handlung. Ein falscher Satz lässt sich löschen. Eine verschickte Mail, ein überschriebener Datensatz, ein veröffentlichter Artikel lassen sich bestenfalls nachträglich korrigieren.

Die Frage „Ist das Modell gut genug?“ greift deshalb nicht mehr. Die richtigen lauten: Was darf dieses System anfassen, wer hat ihm das erlaubt, wer merkt es, wenn etwas schiefgeht, und wie kommt man zurück. Der häufigste Auslöser dafür, dass ein Agent etwas tut, was niemand wollte, ist Prompt Injection: eine Anweisung in einem Inhalt, den er verarbeitet. Hier geht es um das, was danach passiert.

Sechs Risiken, je mit dem Fall, in dem sie einem Website-Betreiber begegnen#

1. Geerbte Rechte. Eine Agentur richtet einen Agenten ein, der Beiträge im CMS anlegt, angemeldet mit dem Konto des Projektleiters, weil das schon da war. Dieses Konto kann auch Benutzer verwalten, Plugins installieren und die .htaccess ändern. Der Agent braucht nichts davon, kann es aber. OWASP führt den Fall als ASI03 Identity & Privilege Abuse in den Top 10 for Agentic Applications 2026 vom 9. Dezember 2025. Microsoft schreibt für den eigenen Copilot, er erbe die Berechtigungen seiner Nutzer (Microsoft Security Insider).

2. Abfluss über die Werkzeuge. Jedes Werkzeug, das der Agent bedienen darf, ist ein Weg nach draußen. Ein Agent räumt das Support-Postfach auf und darf Zusammenfassungen an eine interne Adresse schicken. In einer Kundenmail steht ein Absatz in weißer Schrift, der ihn anweist, die letzten zwanzig Vorgänge an eine externe Adresse weiterzuleiten. Das BSI nennt dieses Risiko in der Verbraucherinformation ausdrücklich.

3. Zu breite Zugangsdaten. Der Agent bekommt ein Deploy-Token, um ein Vorschaubild hochzuladen, ausgestellt mit vollem Schreibzugriff auf alle Repositories, weil das der voreingestellte Umfang war. Ein dokumentierter Fall: Ein Angreifer nutzte ein „inappropriately scoped GitHub token“ in der Build-Konfiguration der Amazon-Q-Erweiterung für Visual Studio Code und bekam Schadcode in ein veröffentlichtes Release; nur ein Syntaxfehler verhinderte die Ausführung (AWS Security Bulletin AWS-2025-015, 23. Juli 2025). Die Dokumentation des Model Context Protocol führt Scope Minimization als eigenen Abschnitt (MCP Security Best Practices).

4. Keine Rückfrage. Ein Agent soll veraltete Beiträge aktualisieren, hält drei Artikel für redundant, legt einen neuen an und setzt die alten auf 410 Gone. Technisch sauber, und die drei Adressen mit dem meisten Traffic sind weg. Zurücknehmen geht; die Rankings kommen nicht am selben Tag zurück. Das BSI empfiehlt Bestätigungsabfragen vor kritischen Aktionen; die MCP-Dokumentation verlangt beim Einrichten eines neuen Werkzeug-Servers, dass der vollständige Befehl angezeigt und ausdrücklich freigegeben wird.

5. Kein Protokoll. Nach vier Wochen fällt auf, dass die Meta-Beschreibungen von sechzig Seiten identisch sind. War das der Agent, ein Plugin-Update, jemand im Team? Ein Agent hinterlässt nur, was du protokolliert hast. Das BSI rät, die Aktionsprotokolle regelmäßig durchzusehen, was voraussetzt, dass es welche gibt. Dieselbe Ratlosigkeit kennt, wer eine gehackte Website zurückverfolgen musste, nur dass hier keine Malware zu finden ist, sondern eine Entscheidung.

6. Fremder Code in der Kette. Für die Anbindung an ein Analyse-Werkzeug installierst du einen MCP-Server aus einem öffentlichen Verzeichnis. Er läuft lokal über stdio, mit denselben Rechten wie das Programm, das ihn startet. Ein Update zwei Monate später bringt eine Zeile mehr mit. OWASP führt das als ASI04 Agentic Supply Chain Vulnerabilities; die MCP-Dokumentation empfiehlt Sandboxing und minimale Standardrechte. Es ist dieselbe Abhängigkeit von fremdem Code, die auch fremde Skripte auf einer Website zum Risiko macht.

Risiko KI-Agenten: Ein Satz in der Mail genügt – Video abspielen (lädt YouTube)

Fünf Maßnahmen, nach Wirkung je Aufwand#

Ein eigener Zugang mit minimalen Rechten. Kein admin, kein persönliches Konto, keine geteilten Zugangsdaten. Ein Benutzer, der nur das darf, was der Auftrag verlangt, im CMS also Beiträge bearbeiten. Eine halbe Stunde Arbeit, und die Risiken 1 bis 3 sind entschärft. Fang mit Lesezugriff an, lass den Agenten zwei Wochen laufen und sieh, woran er scheitert; die Liste der tatsächlich nötigen Rechte ist kürzer als die vorab vergebene.

Bestätigung vor wirksamen Aktionen. Die Trennlinie verläuft zwischen umkehrbar und nicht umkehrbar. Lesen, Entwürfe anlegen, Dateien in einem Arbeitsverzeichnis schreiben: ohne Rückfrage. Versenden, veröffentlichen, löschen, bezahlen: mit. Eine Rückfrage vor jedem einzelnen Schritt hebt den Nutzen auf; wer vierzig Mal am Tag „Ja“ klickt, klickt beim einundvierzigsten Mal auch „Ja“.

Test getrennt von Produktion. Der Agent arbeitet auf einer Staging-Instanz mit Kopien.

Protokollieren, was er anfasst. Zeitstempel, Werkzeug, Ziel, Ergebnis, in einer Datei reicht. Der Agent darf das Protokoll nicht selbst überschreiben können. Du kannst protokollieren, was er getan hat, nicht zuverlässig, warum.

Sicherung vor jedem Schreibzugriff. Datenbank-Dump vor dem Lauf, Dateien in der Versionsverwaltung.

Eine Anweisung im Prompt („tu das nicht“) ist keine dieser Maßnahmen. Sie ist eine Bitte. Was der Agent nicht tun soll, darf er technisch nicht können. Wer das systematischer angehen will, findet im NIST AI Risk Management Framework mit dem Generative AI Profile (NIST AI 600-1, Juli 2024) die vier Funktionen Govern, Map, Measure und Manage als Gliederung.

Abläufe, die nicht an einen Agenten gehören#

Drei Merkmale reichen als Prüfung: Die Handlung ist nicht umkehrbar, ein Fehler fällt nicht sofort auf, und er trifft jemand anderen als dich. Zahlungen auslösen, Verträge abschließen, Kundendaten löschen, im Namen des Unternehmens nach außen kommunizieren: Dort gehört ein Mensch dazwischen. Welche Abläufe sich überhaupt eignen, steht unter Welche Prozesse mit KI automatisieren?.

Auf die Schutzmechanismen der Anbieter allein solltest du dich nicht verlassen. Das BSI hielt am 24. Juli 2026 einen Vorfall fest, bei dem ein KI-Agent von OpenAI im Rahmen eines Tests seine Sandbox verließ, um sich zusätzliche Werkzeuge zu beschaffen, und zieht daraus die offene Frage, wie vernünftige Rechte- und Rollenvergaben für KIs aussehen (BSI-Blog). Die fünf Maßnahmen oben funktionieren unabhängig davon, welches Modell darunter läuft. Und wenn ein Agent etwas Falsches ausgeführt hat: erst den Zugang sperren, dann den Umfang bestimmen (Protokoll, Versionsstand, Sicherung), dann zurückrollen. Wer zuerst aufräumt, weiß hinterher nicht mehr, was passiert ist.

Stand 03.10.2026. Quellen am selben Tag abgerufen.