Was darf ein KI-Agent – und wie behält man die Übersicht?

Ein KI-Agent ruft APIs auf, liest und schreibt in Datenbanken und Services und stößt automatisierte Abläufe über mehrere Anwendungen an – autonom und im Minutentakt. Er handelt eigenverantwortlich, verhält sich wie eine eigene Identität, und es ist deshalb entscheidend, worauf diese Identität zugreifen darf. In der Praxis wird das selten bewusst entschieden: Der Agent übernimmt den Service-Account oder die Rechte des Menschen, der ihn gestartet hat. Diese Abkürzung lässt sich später nur mit großem Aufwand korrigieren.

Was unterscheidet einen KI-Agenten von einem klassischen Service-Account?

Ein Service-Account ist ein technisches Benutzerkonto für eine Anwendung, einen Dienst oder eine Maschine, nicht für eine echte Person – typischerweise für automatisierte Aufgaben wie Backups, Deployments oder Cloud-Zugriffe. Seine Rechte sind in der Regel fest umrissen und eng nach dem Least-Privilege-Prinzip gesetzt. Ein KI-Agent läuft zwar, im Idealfall, über ein ähnliches technisches Konto, entscheidet aber zur Laufzeit, welche Aktion als Nächstes folgt und welche Daten er dafür braucht. Stiehlt ein Angreifer den Token dieses Kontos, handelt er im Namen des Agenten. Weil der Agent Aufgaben über mehrere Systeme verkettet – etwa Kundendaten aus dem CRM lesen, einen Datensatz ändern und daraufhin eine E-Mail auslösen –, reicht ein einziger gestohlener Token weiter als bei einem Service-Account mit einer festen Aufgabe.

Ein Agent gehört damit weder mit einem Service-Account noch mit der Identität eines Menschen in einen Topf. Er braucht eine eigene Identität.

Wie groß ist das Problem wirklich?

Maschinen-Identitäten sind längst in der Mehrheit, und KI-Agenten wachsen darunter am schnellsten. Die Rechte, mit denen diese Agenten künftig laufen, werden schon jetzt vergeben – oft beiläufig. Viele KI-Funktionen wachsen aus einem MVP, und die großzügigen Zugangsdaten aus der Testumgebung wandern mit in die Produktion. Das geschieht ohne böse Absicht und schneller, als jede Governance nachkommt.

Schwerer als das Wachstum wiegt die fehlende Zuständigkeit. Oft ist nicht einmal klar, wozu ein bestimmter Agent überhaupt existiert und zu welchem Projekt er gehört. Solange niemand benennen kann, wem ein Agent gehört, entscheidet auch niemand, was er darf und wann seine Rechte enden.

Die beiden Zahlen stammen aus unterschiedlichen Erhebungen und sind bewusst getrennt genannt. In cloud-nativen Umgebungen liegt das Verhältnis laut der Cloud Security Alliance sogar bei 144:1; die 109:1 sind der branchenweite Durchschnitt aus der Palo-Alto-Auswertung von 2.930 Sicherheitsverantwortlichen.

Warum versagen klassische IAM- und PAM-Prozesse bei Agenten?

Weil diese Prozesse auf den Lebenszyklus eines Menschen ausgelegt sind. Ein Mitarbeiter erhält beim Eintritt Rechte und wird einmal im Jahr rezertifiziert. Ein Agent erledigt in einer einzigen Minute mehrere Aufgaben und bräuchte für jede nur die Rechte, die sie erfordert. Eine jährliche Prüfung kommt dafür viel zu spät.

So wächst ein Bestand an Rechten, die niemand mehr anfasst: Agenten, die für ein längst abgeschlossenes Projekt eingerichtet wurden und deren Zugänge bis heute bestehen.

Nur 8 % der Befragten trauen ihren bestehenden IAM-Systemen zu, KI- und Maschinen-Identitäten überhaupt zu verwalten. Der Grund liegt in den Prozessen: Statische Rechte und eine jährliche Rezertifizierung passen nicht zu einer Identität, deren Bedarf sich stündlich ändert.

Was bedeutet Least Privilege für einen KI-Agenten in der Praxis?

In der Praxis sind es drei Punkte, die aufeinander aufbauen:

1. Eine eigene Identität pro Agent. Sie ist die Voraussetzung für alles Weitere. Erbt der Agent die Rechte eines Menschen, lässt sich weder trennen, was der Mensch und was der Agent getan hat, noch dem Agenten etwas entziehen, ohne den Menschen auszusperren.
2. Rechte auf Zeit statt dauerhaft. Zero Standing Privilege und Just-in-Time bedeuten: Im Ruhezustand hat der Agent keine erhöhten Rechte; er erhält sie für die Dauer einer konkreten Aufgabe und verliert sie danach automatisch. Ein Agent, der nachts einen Report baut, braucht tagsüber keinen Zugriff.
3. Ein menschlicher Verantwortlicher. Zu jedem Agenten gehört eine benannte Person, die entscheidet, was er darf, und deren Rollenwechsel oder Austritt den Agenten mitnimmt. Ohne diesen Sponsor wird der Agent zur verwaisten Identität, wie sie oben als „seit über einem Jahr unverändert“ auftaucht.

Least Privilege begleitet einen Agenten damit über seinen gesamten Lebenszyklus, von der Einrichtung bis zum Entzug.

Wie entzieht man einem Agenten seine Rechte wieder?

Der Entzug ist der Teil, der in der Praxis am häufigsten fehlt. Die Vergabe wird geplant, der Widerruf bleibt oft dem Zufall überlassen. Drei Bausteine machen ihn belastbar:

• Ein zentrales Register. Entziehen lässt sich nur, was erfasst ist. Ein Verzeichnis aller Agenten mit Eigentümer, Zweck und vergebenen Rechten bildet die Grundlage; ohne es bleibt jeder Entzug Stückwerk.
• Rotation und Widerruf in Minuten. Ein kompromittierter Token muss sich sofort ungültig machen lassen. Kurze Gültigkeitsdauern und ein zentraler Widerruf sorgen dafür, dass ein gestohlenes Geheimnis schnell wertlos wird.
• Automatische Deprovisionierung. Endet das Projekt, wechselt der Sponsor die Rolle oder wird der Agent abgeschaltet, sollten seine Rechte automatisch verfallen und nicht auf einer To-do-Liste landen.

Der Mittelstand braucht dafür nicht sofort eine Enterprise-Plattform. Es genügt zunächst, für jeden produktiven Agenten drei Fragen beantworten zu können: Wer ist zuständig, wie lange gelten die Rechte, und wie wird man sie wieder los?

Was hat Prompt Injection mit der Rechtevergabe zu tun?

Beides hängt eng zusammen: Die Rechte eines Agenten bestimmen, wie weit eine manipulierte Anweisung überhaupt tragen kann. Ein Agent wird überwiegend über Sprache gesteuert, und Sprache lässt sich manipulieren. Eine untergeschobene Anweisung – eine Prompt Injection – ist dabei nur eines von mehreren Einfallstoren, über die ein Angreifer ihn zu nicht vorgesehenen Aktionen bewegen kann. Filter, die manipulierte Eingaben vorab abfangen sollen (Prompt-Filter), helfen dagegen nur bedingt. Verlässlicher ist die Rechtevergabe: Was ein manipulierter Agent anrichtet, hängt davon ab, was seine Identität darf. Ein Agent ohne Schreibrechte auf ein System löscht dort auch nach einer erfolgreichen Injection nichts.

Wie groß der Schaden über geerbte Zugänge werden kann, zeigte der Salesloft-Drift-Vorfall im August 2025: Angreifer stahlen die OAuth-Tokens einer KI-gestützten Chat-Integration und gelangten damit in die Salesforce-Umgebungen von mehr als 700 Organisationen. Der Zugriff lief nicht über eine Lücke in Salesforce, sondern über die weitreichenden Rechte, die der Integration einmal erteilt worden waren. Eng geschnittene und zeitlich begrenzte Rechte hätten diesen Radius begrenzt.

Womit fängt ein Mittelständler konkret an?

Der Einstieg besteht aus drei Schritten:

1. Inventar. Welche KI-Agenten laufen bereits produktiv, und mit welcher Identität? Häufig lautet die ehrliche Antwort: mit dem Account eines Menschen oder einem breit berechtigten Service-Account.
2. Eigentümerschaft. Jedem Agenten eine verantwortliche Person zuordnen. Das schließt die Lücke, die in der Hälfte der Organisationen offen ist.
3. Geteilte Zugänge abschaffen. Schritt für Schritt jedem produktiven Agenten eine eigene Identität mit eng geschnittenen, zeitlich begrenzten Rechten geben und die geerbten Zugänge entfernen.

Es ist die gleiche Logik wie bei privilegierten menschlichen Konten, nur enger getaktet. Wer den Zusammenhang von IAM und PAM einordnen möchte, findet ihn in unserem Beitrag PAM vs. IAM – was ist der Unterschied?. Steht die Bestandsaufnahme noch aus, ist das der richtige Einstiegspunkt – dafür haben wir unseren Security Kompass entwickelt.

Quellen

• Palo Alto Networks, 2026 Identity Security Landscape — Verhältnis von Maschinen- zu Mensch-Identitäten (109:1) und erwartetes KI-Agenten-Wachstum (85 %), Basis 2.930 Befragte. Die offizielle Report-Seite erfordert eine Registrierung; frei lesbare Einordnung der Zahlen bei Help Net Security.
• Cloud Security Alliance, The Non-Human Identity Governance Vacuum (Mai 2026) — fehlende Eigentümerschaft, Alter und Widerruf nicht-menschlicher Identitäten.
• Google Threat Intelligence Group, Datendiebstahl aus Salesforce-Umgebungen über die Salesloft-Drift-Integration (2025) — Ablauf und Umfang des OAuth-Token-Vorfalls.