KI-Agenten als neue Angriffsfläche: Warum Autonomie auch Risiko bedeutet

Ein mittelständischer Fertigungsbetrieb führt einen KI-Agenten ein, der E-Mails aus dem Kundenservice liest, Bestellungen im ERP-System anlegt und bei Rückfragen automatisch antwortet. Die ersten Wochen laufen glänzend: Durchlaufzeiten sinken, das Team ist entlastet, der Business Case rechnet sich. Erst bei einem internen Sicherheitsaudit fällt auf, dass der Agent über einen gemeinsam genutzten Dienstkonto-Zugang verfügt, der weit mehr kann als Bestellungen anlegen – er darf auch Zahlungsdaten einsehen und Rechnungen freigeben. Niemand hat das böswillig so eingerichtet. Es war einfach der schnellste Weg, den Agenten zum Laufen zu bringen.

Genau dieses Muster beschäftigt Sicherheitsverantwortliche und Projektleiter gerade branchenübergreifend: KI-Agenten sind keine Chatbots, die auf Fragen antworten. Sie handeln – sie rufen Werkzeuge auf, lesen und schreiben Daten, lösen Folgeprozesse aus. Genau diese Handlungsfähigkeit macht sie zu einem neuen, eigenständigen Sicherheitsrisiko, das sich mit den Methoden der klassischen IT-Sicherheit nur teilweise fassen lässt.

Vom Chatbot zum Akteur: Warum Agenten anders zu bewerten sind

Ein klassisches KI-Sprachmodell antwortet – ein Agent handelt. Er verkettet Werkzeuge, ruft APIs auf, greift auf Datenbanken zu und trifft im Rahmen seines Auftrags eigenständig Zwischenentscheidungen. Damit verschiebt sich auch das Risiko: Es geht nicht mehr nur darum, ob eine Antwort fachlich falsch ist, sondern darum, was ein System mit realen Systemzugriffen tatsächlich tut, wenn es manipuliert, fehlgeleitet oder schlicht überfordert wird.

Die OWASP Gen-AI-Security-Initiative hat dafür inzwischen einen eigenen Kategorienkatalog für agentische Anwendungen entwickelt. Er macht deutlich, dass die Risiken nicht in erster Linie im Modell selbst liegen, sondern in der Art, wie Agenten in Systeme eingebettet werden: über welche Rechte sie verfügen, welchen Inhalten sie vertrauen und wie ihre Aktionen kontrolliert werden.

Wo die neue Angriffsfläche tatsächlich liegt

Vier Risikofelder tauchen in nahezu jeder aktuellen Analyse zu Agenten-Sicherheit auf:

Erstens die Zielmanipulation über Inhalte statt über Code. Ein Agent, der E-Mails, Dokumente oder Webseiten verarbeitet, kann durch geschickt platzierte Anweisungen in genau diesen Inhalten umgelenkt werden – ganz ohne dass jemand in die Software selbst eingreift. Für den Agenten sieht eine versteckte Anweisung in einer E-Mail-Signatur zunächst wie ein legitimer Auftrag aus.

Zweitens der Missbrauch legitimer Werkzeuge. Ein Agent, der berechtigterweise auf ein Dateisystem, eine Kommandozeile oder eine Cloud-Schnittstelle zugreifen darf, kann über täuschende Eingaben dazu gebracht werden, diese Werkzeuge auf eine Weise zu nutzen, die nie beabsichtigt war.

Drittens der Missbrauch von Identität und Berechtigungen. Viele Agenten laufen heute unter geteilten Dienstkonten mit weitreichenden, dauerhaft gültigen Zugriffsrechten – aus Bequemlichkeit bei der Einrichtung, nicht aus bewusster Entscheidung. Ein kompromittierter Agent mit einem solchen Zugang verursacht ungleich größeren Schaden als einer mit eng geschnittenen, zeitlich befristeten Rechten.

Viertens die wachsende Lieferkette an Werkzeugen und Erweiterungen. Agenten binden zur Laufzeit oft zusätzliche Tools und Plug-ins ein, deren Herkunft und Sicherheitsstand nicht immer geprüft ist. Jede neue Anbindung vergrößert die Angriffsfläche, ohne dass dies im ursprünglichen Sicherheitskonzept berücksichtigt wurde.

Der blinde Fleck: Identität für Maschinen

Der wohl unterschätzteste Punkt ist die Identitätsfrage. Menschen haben in den meisten Unternehmen einen klar geregelten Zugriffs-Lebenszyklus: Konto anlegen, Rechte zuweisen, regelmäßig überprüfen, bei Bedarf entziehen. Für KI-Agenten existiert dieser Prozess in vielen Organisationen schlicht noch nicht. Sie erben Zugänge von Entwicklern, teilen sich API-Schlüssel mit anderen Diensten oder erhalten pauschal großzügige Rechte, „damit es funktioniert". Das Ergebnis sind unauffällige, aber sehr mächtige Zugänge, die im Ernstfall kaum einem einzelnen Vorfall zuzuordnen sind – und die sich nur schwer schnell entziehen lassen.

Was Projekt- und Sicherheitsverantwortliche konkret tun können

Ein paar Grundregeln haben sich in der Praxis bewährt und lassen sich unabhängig von der eingesetzten Technologie anwenden:

Das Prinzip der minimalen Handlungsfähigkeit: Ein Agent erhält nur die Rechte und Werkzeuge, die seine konkrete Aufgabe erfordert – nicht mehr, auch wenn das kurzfristig bequemer wäre.

Eigene, kurzlebige Identitäten statt geteilter Konten: Jeder Agent bekommt eine eigene, nachvollziehbare Identität mit zeitlich befristeten, aufgabenbezogenen Zugriffstoken, die nach Erledigung automatisch verfallen.

Trennung von Inhalt und Anweisung: Daten, die ein Agent verarbeitet, sollten technisch klar von Anweisungen getrennt werden, denen er folgt – damit eine manipulierte E-Mail nicht versehentlich zum Befehl wird.

Freigabe kritischer Aktionen durch Menschen: Bei Handlungen mit echten Konsequenzen – Zahlungen, Löschungen, externe Kommunikation – bleibt eine menschliche Bestätigung sinnvoll, wobei diese Bestätigung auf nachvollziehbaren, vollständigen Informationen beruhen muss und nicht nur auf der Zusammenfassung, die der Agent selbst liefert.

Lückenlose Protokollierung: Jede Aktion eines Agenten sollte nachvollziehbar dokumentiert sein, damit im Zweifelsfall rekonstruierbar ist, was warum geschehen ist.

Entscheidend ist, diese Fragen bereits in der Projektplanung zu stellen – als Teil des Risikomanagements, nicht als nachträgliche Sicherheitsprüfung kurz vor dem Go-Live.

Ein typisches Beispiel

Ein Dienstleistungsunternehmen führt einen Agenten ein, der Angebote automatisch aus CRM-Daten erstellt. In der Pilotphase erhält er testweise weitreichenden Zugriff, um schnell iterieren zu können – „das schrauben wir vor dem Rollout noch zurück". Weil der Go-Live-Termin drängt, passiert genau das nicht. Erst ein externes Sicherheits-Assessment vor einer Kundenzertifizierung deckt auf, dass der Agent theoretisch auch auf Verträge anderer Kunden zugreifen könnte. Der Fehler lag nicht im Modell, sondern in der Governance rund um den Agenten – einem Punkt, der im ursprünglichen Projektplan schlicht nicht vorgesehen war.

Auf den Punkt

KI-Agenten sind keine reine IT-Frage mehr, sondern ein Thema für die Projektplanung selbst: Wer Handlungsfähigkeit einführt, führt auch neue Risiken ein. Wer von Anfang an mit minimalen Rechten, eigenen Identitäten und klarer Freigabelogik arbeitet, verhindert die teuersten Fehler – nicht durch Misstrauen gegenüber der Technologie, sondern durch dieselbe Sorgfalt, die man auch menschlichen Mitarbeitenden mit weitreichenden Befugnissen entgegenbringen würde.