KI-Agenten: Sicherheit und Risiken im Betrieb

Der Agent sollte nur die Produkttexte im Shop überarbeiten. Eingerichtet hat ihn der Entwickler mit seinem eigenen Zugang, weil das am schnellsten ging — einem Administratorkonto. Drei Wochen später stehen in den Logs Änderungen an Kategorien, Preisen und einer Weiterleitung, und niemand kann sagen, ob der Agent das selbst beschlossen hat oder ob ihn etwas dazu gebracht hat.

Hier hört KI-Sicherheit auf, eine Debatte über Halluzinationen zu sein. Ein Chatbot, der Unsinn erzählt, kostet dich Zeit. Ein Agent, der Unsinn ausführt, kostet dich den Shop. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt einen KI-Agenten genau so: als Softwaresystem, das auf Basis eines Sprachmodells eigenständig Handlungen ausführt — Mails schreiben, Termine eintragen, Buchungen abschließen, ohne dass jeder Schritt freigegeben wird (BSI, Verbraucherinformation KI-Agenten).

Dieser Beitrag ordnet die Risikolage: sechs Risikoarten, jeweils mit dem Szenario, in dem sie einem Website-Betreiber oder einer Agentur begegnen, und danach die Gegenmaßnahmen, die ohne Sicherheitsabteilung umsetzbar sind.

Der Unterschied, um den es geht#

Die kurze Antwort vorweg: Beim Agenten 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 nicht zurückholen — bestenfalls nachträglich korrigieren, und das sieht jeder.

Deshalb greift „Ist das Modell gut genug?“ als Frage 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. Die gleiche Verschiebung ist es, die KI-Automatisierung überhaupt erst wirtschaftlich macht — man bekommt beides im Paket.

Eine Vorbemerkung zum häufigsten Auslöser: Prompt Injection ist der Angriff, bei dem Anweisungen in Inhalten stecken, die der Agent verarbeitet — in einer Mail, auf einer Website, in einem Ticket. Das Modell unterscheidet nicht zuverlässig zwischen „Text, den ich lesen soll“ und „Anweisung, der ich folgen soll“. Microsoft hat 2025 eine solche Lücke im M365 Copilot geschlossen (CVE-2025-32711, „EchoLeak“): eine harmlos aussehende Mail konnte den Kontext so verändern, dass begrenzte Daten abflossen (Microsoft Security Insider). Wie der Angriff funktioniert und was gegen ihn hilft, steht in unserem Beitrag zu Prompt Injection. Hier geht es um das, was danach passiert — weil der Agent handeln darf.

Der Agent erbt, was du ihm gegeben hast#

Ein Agent hat die Rechte des Zugangs, mit dem er eingerichtet wurde. Nicht weniger. Microsoft formuliert das für den eigenen Copilot unmissverständlich: Er erbt die Berechtigungen seiner Nutzer. Wer noch Zugriff auf Daten einer früheren Abteilung hat, bekommt sie über den Assistenten wieder zu sehen.

Das Szenario. Eine Agentur richtet einen Agenten ein, der für Kunden Beiträge im CMS anlegt. Angemeldet wird er 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 — aber er kann es. In der OWASP-Liste der zehn wichtigsten Risiken agentischer Anwendungen steht dieser Fall als eigener Punkt: ASI03 — Identity & Privilege Abuse (OWASP Top 10 for Agentic Applications 2026, veröffentlicht am 9. Dezember 2025).

Was durch die Werkzeuge nach draußen fließt#

Jedes Werkzeug, das der Agent bedienen darf, ist auch ein Weg nach draußen. Wer Mails verschicken darf, kann Daten verschicken. Wer HTTP-Aufrufe machen darf, kann alles an jede Adresse schicken, die im Text auftaucht.

Das Szenario. Ein Agent räumt das Support-Postfach auf und darf dazu 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. Niemand liest weiße Schrift — der Agent schon. Das BSI nennt genau das als Risiko: Agenten mit Zugriff auf personenbezogene Daten lassen sich dazu bringen, diese an Dritte weiterzugeben.

Zugangsdaten, die in der Konfiguration liegen#

Damit ein Agent arbeiten kann, braucht er Schlüssel: API-Token, Passwörter, OAuth-Zugänge. Die liegen irgendwo — in einer .env, in einer JSON-Datei neben der Konfiguration, im Repository. Und sie sind selten so eng geschnitten, wie sie sein müssten.

Das Szenario. Der Agent bekommt ein Deploy-Token, damit er ein Vorschaubild hochladen kann. Ausgestellt wurde es mit vollem Schreibzugriff auf alle Repositories der Organisation, weil das der voreingestellte Umfang war. Ein dokumentierter Fall zeigt, wie teuer das wird: Ein Angreifer nutzte ein „inappropriately scoped GitHub token“ in der Build-Konfiguration der Amazon-Q- Erweiterung für Visual Studio Code und bekam damit Schadcode in ein veröffentlichtes Release. Nur ein Syntaxfehler verhinderte die Ausführung (AWS Security Bulletin AWS-2025-015,

1. Juli 2025). Die Dokumentation des Model Context Protocol führt Scope Minimization deshalb als eigenen Abschnitt: Ein gestohlenes Token mit breiten Rechten öffnet Wege, die mit dem eigentlichen Auftrag nichts zu tun haben (MCP Security Best Practices).

Wenn niemand mehr gefragt wird#

Der wirtschaftliche Sinn eines Agenten liegt darin, dass er nicht bei jedem Schritt nachfragt. Genau das ist auch das Risiko — und die Schäden sind ungleich verteilt: Ein missratener Entwurf ist folgenlos, eine verschickte Serienmail ist es nicht.

Das Szenario. Ein Agent soll veraltete Beiträge aktualisieren. Er hält drei Artikel für redundant, legt einen neuen an und setzt die alten auf 410 Gone. Technisch sauber ausgeführt, inhaltlich vertretbar — und die drei URLs, die den meisten Traffic brachten, sind weg. Zurücknehmen kannst du das schon; die Rankings kommen nicht am selben Tag zurück.

Das BSI empfiehlt dafür den einfachsten verfügbaren Hebel: Bestätigungsabfragen vor kritischen Aktionen aktivieren. Dieselbe Logik steht in der MCP- Dokumentation, dort für den Moment, in dem ein neuer Werkzeug-Server eingerichtet wird — der vollständige Befehl muss angezeigt und ausdrücklich freigegeben werden, ungekürzt.

Hinterher weiß keiner, was passiert ist#

Ein Mensch, der etwas ändert, hinterlässt eine Spur im Kopf: Er weiß noch, was er getan hat. Ein Agent hinterlässt nur das, was du protokolliert hast. Wenn das nichts ist, bleibt eine veränderte Datenbank ohne Erklärung.

Das Szenario. 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? Ohne Protokoll dauert die Fehlersuche länger als die Korrektur. Dieselbe Ratlosigkeit kennt jeder, der schon einmal eine gehackte Website erkennen und zurückverfolgen musste — nur dass hier keine Malware zu finden ist, sondern eine Entscheidung.

Das BSI rät ausdrücklich, die Aktionsprotokolle regelmäßig durchzusehen. Das setzt voraus, dass es welche gibt.

Fremde Erweiterungen, fremde Server#

Ein Agent besteht selten nur aus dem Modell. Dazu kommen Erweiterungen, Werkzeug-Server, Pakete — meist aus fremder Hand, oft mit wenigen hundert Installationen. OWASP führt ASI04 — Agentic Supply Chain Vulnerabilities aus demselben Grund in der Top 10.

Das Szenario. 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. Die MCP-Dokumentation benennt diese Kette ausdrücklich — willkürliche Codeausführung, keine Sichtbarkeit für den Nutzer, Datenabfluss — und empfiehlt Sandboxing und minimale Standardrechte. Es ist dieselbe Abhängigkeit von fremdem Code, die auch Third-Party-Scripts auf einer Website zum Risiko macht.

Was ein kleiner Betrieb tatsächlich umsetzen kann#

Fünf Maßnahmen, absteigend nach Wirkung pro 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, sonst nichts. Eine halbe Stunde Arbeit, und die drei ersten Risikoarten sind auf einmal entschärft.

Bestätigung vor wirksamen Aktionen. Die Trennlinie verläuft nicht zwischen „wichtig“ und „unwichtig“, sondern zwischen umkehrbar und nicht umkehrbar. Lesen, Entwürfe anlegen, Dateien in einem Arbeitsverzeichnis schreiben: ohne Rückfrage. Versenden, veröffentlichen, löschen, bezahlen: mit.

Test getrennt von Produktion. Der Agent arbeitet auf einer Staging-Instanz mit Kopien, nicht am Livesystem. Einmalig Einrichtungszeit, und den meisten Fehlern sind die Folgen genommen.

Protokollieren, was er anfasst. Zeitstempel, Werkzeug, Ziel, Ergebnis — in einer Datei reicht. Wichtig ist nur, dass der Agent das Protokoll nicht selbst überschreiben kann.

Sicherung vor jedem Schreibzugriff. Datenbank-Dump vor dem Lauf, Dateien im Versionsverwaltungssystem. Nicht elegant, aber der Unterschied zwischen einem Ärgernis und einem Abend.

Wer das systematischer angehen will, findet im NIST AI Risk Management Framework (26. Januar 2023, ergänzt um das Generative AI Profile NIST AI 600-1 vom 26. Juli 2024) die vier Funktionen Govern, Map, Measure und Manage — als Gliederung brauchbar, auch für eine einzelne Website.

Wo Absicherung mehr kostet, als sie bringt#

Nicht jede Maßnahme lohnt sich in einem Betrieb mit fünf Leuten.

Eine Bestätigungsabfrage vor jedem einzelnen Schritt hebt den Nutzen auf. Wer vierzig Mal am Tag „Ja“ klickt, klickt beim einundvierzigsten Mal auch „Ja“. Bestätigungen wirken nur, solange sie selten sind — ein Argument für wenige Rückfragen an den richtigen Stellen, nicht für viele überall.

Ein eigenes Rechtesystem pro Werkzeug bauen sich Konzerne. Für alle anderen gilt: ein Zugang je Agent, eng geschnitten, Werkzeugliste kurz.

Vollständige Nachvollziehbarkeit der Modellentscheidungen ist nicht zu haben. Du kannst protokollieren, was der Agent getan hat, nicht zuverlässig, warum.

Und dann gibt es Prozesse, die für einen autonomen Agenten schlicht nicht taugen. 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, nicht als Formalie. Welche Abläufe sich überhaupt eignen, steht unter welche Prozesse sich automatisieren lassen.

Und was ist mit den Schutzmechanismen der Anbieter?#

Der naheliegende Einwand: Die Anbieter arbeiten daran, das ist ihr Geschäft. Stimmt. Nur sind die Mechanismen nicht so weit, wie die Produktseiten nahelegen.

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 — ohne böse Absicht, aber erfolgreich. Die Behörde zieht daraus keine Entwarnung, sondern eine offene Frage: Wie sehen vernünftige Rechte- und Rollenvergaben für KIs aus (BSI-Cybernation-Blog). KI-Agenten gelten dem BSI insgesamt als technologisch noch nicht ausgereift.

Das ist kein Grund, die Finger davon zu lassen — nur einer, die Absicherung selbst in die Hand zu nehmen, statt sie vorauszusetzen. Die fünf Maßnahmen oben funktionieren unabhängig davon, welches Modell darunter läuft.

Häufige Fragen#

Ist ein Agent gefährlicher als ein Chatbot? Nicht als Modell, sondern als Aufbau. Derselbe Fehler führt beim Chatbot zu einem falschen Satz und beim Agenten zu einer ausgeführten Handlung.

Reicht es, dem Agenten in den Anweisungen zu verbieten, bestimmte Dinge zu tun? Nein. Eine Anweisung im Prompt ist eine Bitte, keine Schranke. Was der Agent nicht tun soll, darf er technisch nicht können — über Rechte, nicht über Formulierungen.

Wie viele Rechte braucht ein Agent wirklich? Weniger als angenommen. Fang mit Lesezugriff an, lass ihn zwei Wochen laufen und schau, woran er scheitert. Die Liste der tatsächlich benötigten Rechte ist meist kürzer als die, die man vorab vergeben hätte.

Was tun, 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.

Gibt es dafür einen anerkannten Standard? Einen verbindlichen nicht. Als Orientierung dienen die OWASP Top 10 für agentische Anwendungen, das NIST AI Risk Management Framework und die BSI-Empfehlungen zu KI-Agenten.

Kurz gefasst#

Der Unterschied zwischen Chatbot und Agent ist nicht die Qualität der Antwort, sondern die Reichweite des Fehlers. Wer Werkzeuge vergibt, vergibt Wirkung.

Die Risiken sind absehbar: zu weite Rechte, Abfluss über die Werkzeuge, zu breite Tokens, Handlungen ohne Rückfrage, fehlende Protokolle, fremder Code in der Kette. Keines davon ist neu, alle sind beherrschbar.

Beherrschbar heißt nicht folgenlos. Ein eigener Zugang mit engen Rechten, eine Bestätigung vor allem Unumkehrbaren, eine Sicherung vorher — und die Bereitschaft, manche Abläufe gar nicht an einen Agenten zu geben.