Zugriffsrechte von KI-Agenten sicher steuern

Worum es geht

KI-Agenten handeln nicht nur, sie greifen zu. Ein Agent liest Datenbanken, verschickt E-Mails, veröffentlicht Beiträge, bucht in Fachsysteme. Damit er das tun kann, benötigt er eine wirksame Identität und Berechtigungen – entweder als eigenes Agentenkonto, über eine delegierte Nutzeridentität oder über eine Connector- bzw. Workload-Identität. Microsoft stellt dafür inzwischen eigenständige Agentenidentitäten bereit, die authentifiziert, autorisiert und verwaltet werden müssen^[1].

Das Problem beginnt dort, wo sich um diese Zugänge niemand kümmert. Beim Aufsetzen eines Agenten ist es bequem, ihm breite Rechte zu geben, damit „es sicher funktioniert“, statt exakt der Berechtigung, die die Aufgabe verlangt. Die Zugangsdaten landen dauerhaft in einer Konfigurationsdatei oder einem Passwort-Tresor, ohne Ablaufdatum. Und wenn der Agent seinen Zweck erfüllt hat, entzieht ihm niemand den Zugang, weil sich niemand zuständig fühlt.

Das ist längst kein Randthema. Branchenweit übersteigt die Zahl der Maschinenidentitäten die der Menschen deutlich: laut einer CyberArk-Erhebung von 2025 unter Organisationen ab 500 Mitarbeitern (n = 2.600) um mehr als das Achtzigfache^[2]. Diese Zahl umfasst alle Maschinenidentitäten – Dienstkonten, Workloads, Automatisierungen – und nicht nur KI-Agenten; sie steht hier für die Größenordnung, in der solche Zugänge anwachsen, nicht für Ihr Haus. Für den Mittelstand ist ohnehin eine kleinere Zahl entscheidend: Schon ein einziger überprivilegierter Agent, den niemand mehr im Blick hat, genügt für einen ernsten Schaden.

1. Der Agent als neuer Mitarbeiter ohne Personalakte

Stellen Sie sich einen KI-Agenten wie einen neuen Mitarbeiter vor, der am ersten Tag einen Schlüsselbund bekommt. Bei einem Menschen ist geregelt, wer den Schlüsselbund ausgibt, welche Türen er öffnet und wann er beim Austritt wieder eingezogen wird. Dieser Ablauf hat einen Namen: Onboarding und Offboarding, gesteuert über die Personalabteilung. Für den Agenten existiert dieser Ablauf in den meisten Unternehmen nicht (Abbildung 2).

Ein Beispiel, das dieses Papier begleitet: Ein Marketing-Team richtet einen Agenten ein, der selbstständig Beiträge in den sozialen Netzwerken veröffentlichen soll. Statt ihm genau dieses eine Recht zu geben, erhält er aus Bequemlichkeit vollen Administratorzugriff auf die gesamte Marketing-Suite, einschließlich der Funktion, Kundendaten zu exportieren. Der Agent läuft, die Beiträge erscheinen, alle sind zufrieden. Ein halbes Jahr später erinnert sich niemand mehr an den genauen Funktionsumfang dieses Zugangs. Der Agent ist da, er arbeitet, und über seine Rechte denkt niemand nach.

Genau darin liegt der blinde Fleck. In vielen Unternehmen gilt „privilegiert“ ausschließlich für Menschen: Laut CyberArk (2025, n = 2.600) definieren 88 Prozent der Organisationen privilegierten Zugriff nur für menschliche Nutzer, während zugleich 42 Prozent der Maschinenidentitäten privilegierten oder sensiblen Zugriff haben^[2]. Wer nur die Menschen absichert, übersieht potenziell die Mehrheit der Zugriffsberechtigten – in cloud-lastigen Umgebungen schon heute, im Mittelstand mit wachsender Automatisierung zunehmend.

Zwei Fälle, die alles Weitere bestimmen

Bevor Sie irgendetwas steuern können, müssen Sie eine Frage je Agent beantworten: Hat er ein eigenes Konto – oder handelt er unter der geliehenen Identität eines Mitarbeiters? Die beiden Fälle sehen im Alltag gleich aus und verhalten sich völlig verschieden (Abbildung 3).

Beim eigenen Konto greift alles, was dieses Papier beschreibt: Rechte am Agenten zuschneiden, Ablaufdatum setzen, inventarisieren, am Ende abschalten – ohne dass ein Mensch betroffen ist.

Bei der delegierten Identität gibt es kein Agentenkonto, das man stutzen oder löschen könnte. Der Agent erbt automatisch die Rechte des angemeldeten Mitarbeiters, oft also deutlich mehr, als seine Aufgabe verlangt. Der Hebel verschiebt sich auf drei andere Stellen: die Rechte des Nutzerkontos, den Funktionsumfang, den der Agent aufrufen darf, und die erteilte Zustimmung (Consent), mit der die Anwendung im Namen des Nutzers handelt. Offboarding heißt hier nicht Konto löschen, sondern Zustimmung widerrufen und Aktualisierungs-Tokens ungültig setzen. Und weil die Protokolle dann Aktivitätsdaten eines Menschen sind, ist die Überwachung mitbestimmungspflichtig – dazu Abschnitt 6.

Gerade im Mittelstand ist der zweite Fall häufig, weil viele Agenten als Funktion in bereits genutzter Software stecken. Prüfen Sie deshalb pro Agent, welcher Fall vorliegt, und halten Sie es im Inventar fest.

2. Ein Bestand, der unbemerkt wächst

In einer weiteren Erhebung von CyberArk (Report ursprünglich von Venafi), dem 2025 State of Machine Identity Security (n = rund 1.200, erhoben Januar 2025), rechnet eine deutliche Mehrheit der Organisationen mit einem weiteren, teils sprunghaften Anstieg ihrer Maschinenidentitäten; rund die Hälfte berichtet bereits von Sicherheitsverletzungen durch kompromittierte Maschinenidentitäten^[3].

Für Ihr Haus ist entscheidend, dass dieser Zuwachs schleichend passiert. Neue Zugänge entstehen dezentral: angelegt von der IT, von Fachabteilungen, von Dienstleistern, teils vom Agenten selbst. Sie tauchen in keiner Personalakte auf, und oft weiß die IT gar nicht, dass Marketing oder Vertrieb ein neues KI-Tool angebunden hat – 68 Prozent der Befragten geben an, über keine Identity-Kontrollen speziell für KI zu verfügen^[2]. Man muss kein Konzern sein, um den Überblick zu verlieren: Es genügt, dass mehrere Stellen unabhängig voneinander Agenten einrichten und niemand die Summe kennt.

3. Wie zu breite, ewige Rechte entstehen und bleiben

Drei Mechanismen sorgen dafür, dass Agenten-Rechte zu weit werden und es bleiben. Sie sind kein Zufall, sondern typische Muster. Die OWASP Non-Human Identities Top 10 (2025), eine offene Referenzliste der größten Risiken bei nicht-menschlichen Identitäten, benennt genau diese drei als eigene Risikoklassen^[4].

Überprivilegierung (OWASP NHI5). Bei Entwicklung und Wartung erhalten Konten häufig mehr Rechte als für ihre Aufgabe nötig, einfach weil das schneller geht und Fehler vermeidet. Jedes überzählige Recht vergrößert den möglichen Schaden im Ernstfall. Genau dieser Punkt – der Marketing-Agent mit vollem Admin-Zugriff statt nur der Veröffentlichungsfunktion – ist ein typisches Risikomuster^[4].

Langlebige Zugangsdaten (OWASP NHI7). Das Secret eines Agenten wird meist einmal erzeugt und dann dauerhaft hinterlegt: in einer Konfigurationsdatei, einem Secrets-Store oder direkt im Code. Wie haltbar solche Secrets sind, zeigt der State of Secrets Sprawl 2026 des Anbieters GitGuardian: Von den 2022 als gültig bestätigten Zugangsdaten waren Anfang 2026 immer noch über 64 Prozent gültig – über Jahre nie widerrufen^[5]. Die Zahlen stammen aus öffentlichen Repositorien und beschreiben die Hygiene von Entwicklern, nicht Ihr Unternehmensnetz; das Muster ist dennoch übertragbar: Ein einmal ausgestelltes Secret bleibt oft weit über seinen Zweck hinaus als Angriffsfläche bestehen.

Fehlendes Offboarding (OWASP NHI1). Wird ein Agent nicht mehr gebraucht oder wechselt der Mitarbeiter, der ihn eingerichtet hat, bleibt seine Identität meist einfach aktiv. Die OWASP-Liste unterscheidet den ruhenden Zugang (der Dienst ist abgeschaltet, das Konto besteht weiter) und den verwaisten Zugang (der ursprüngliche Verantwortliche ist weg, ein neuer wurde nie benannt)^[4]. Dass dies verbreitet ist, legt die Umfrage The State of Non-Human Identity and AI Security von CSA und Oasis Security nahe (n = 383, erhoben August bis September 2025, veröffentlicht Januar 2026): 78 Prozent der Organisationen haben keine dokumentierten Richtlinien für das Anlegen oder Entfernen von KI-Identitäten, und 92 Prozent trauen ihren bestehenden Identitätslösungen nicht zu, das Risiko von KI und nicht-menschlichen Identitäten zu bewältigen^[6].

Hinter allen drei Mustern steht dieselbe Lücke: fehlende Eigentümerschaft (Abbildung 4). Das Diskussionspapier The Non-Human Identity Governance Vacuum der Cloud Security Alliance benennt das Fehlen klarer Zuständigkeit als die grundlegendste Governance-Lücke bei nicht-menschlichen Identitäten^[7]. Ökonomisch ist das ein klassisches Delegationsproblem: Wer Aufgaben an einen Beauftragten abgibt, kann dessen Handeln nur begrenzt beobachten und trägt trotzdem das Ergebnis. Beim KI-Agenten kommt eine Besonderheit hinzu – seine Anweisungen können von außen manipuliert werden, der Auftraggeber konkurriert also mit einem Dritten um das Verhalten seines eigenen Beauftragten. Ein Konto, für das sich niemand zuständig fühlt, wird von niemandem hinterfragt und von niemandem entzogen.

4. Der Ernstfall: Wenn die Rechte des Agenten zu den Rechten des Angreifers werden

Solange alles normal läuft, fällt ein überprivilegierter Agent nicht auf. Das ändert sich, wenn er manipuliert wird. Ein KI-Agent lässt sich über eine Prompt Injection täuschen: über eine in harmlos aussehende Inhalte eingeschleuste Anweisung (etwa in einer E-Mail, einem Dokument oder einer Webseite), die der Agent als legitimen Auftrag missversteht. Die Mechanik dieser Angriffe ist Thema eines eigenen Whitepapers zur Angriffssicherheit von KI-Agenten und hier nicht der Punkt. Entscheidend ist die Folge – und die Tatsache, dass zwischen Auslöser und Schaden mehrere Kontrollen liegen, von denen die Rechtevergabe nur eine ist (Abbildung 5).

Diese Folge trägt in der OWASP Top 10 for LLM Applications (2025) einen eigenen Namen: Excessive Agency (LLM06:2025), zu weit reichende Handlungsvollmacht – die Schwachstelle, „die es ermöglicht, dass schädliche Aktionen als Reaktion auf unerwartete, mehrdeutige oder manipulierte Ausgaben eines Sprachmodells ausgeführt werden“. Als Wurzel nennt die Liste drei Ursachen: zu viele Funktionen, zu viele Rechte, zu viel Autonomie^[8]. Fachlich ist das ein seit Jahrzehnten bekanntes Muster, das Confused-Deputy-Problem^[9]: Eine Instanz mit hohen Rechten wird von einem Dritten dazu gebracht, diese Rechte in dessen Sinne einzusetzen. Der Auslöser muss dabei nicht einmal ein Angreifer sein – auch eine Fehlinterpretation reicht. Minimale Rechte schützen in beiden Fällen.

Der Mechanismus ist für Agenten belegt. Die OWASP Top 10 for Agentic Applications (2026) führen „Tool Misuse and Exploitation“ (ASI02) und „Identity and Privilege Abuse“ (ASI03) als eigene Spitzenrisiken^[10]. Zwei Fälle zeigen den Weg vom Text zur Wirkung:

Eine Einschränkung bleibt ehrlich zu benennen: Beide Fälle wurden von Sicherheitsforschern gefunden und vom Hersteller geschlossen, es sind keine bezifferten Schadensfälle. Ein öffentlich bestätigter Fall in freier Wildbahn, bei dem die Dauerrechte eines autonomen Agenten der entscheidende Multiplikator waren, ist bislang selten dokumentiert. Die folgenden Vorfälle stammen daher aus der verwandten Welt klassischer Maschinenidentitäten – Service-Konten und OAuth-Anwendungen, keine autonomen KI-Agenten. Sie zeigen dasselbe Schadensmuster und zugleich etwas, das für Ihre Reihenfolge wichtiger ist als jede Marktzahl: Der Einstieg war jedes Mal eine Lücke in der Basis-Hygiene (Abbildung 6).

Im Detail: Bei Microsoft fand sich hinter dem Testkonto eine veraltete Test-OAuth-Anwendung mit „erhöhtem Zugriff auf die Microsoft-Unternehmensumgebung“; über sie gelangten die Angreifer an Postfächer. Microsofts eigene Lehre: Rechte würden oft „über das erforderliche Maß hinaus“ vergeben^[13]. Bei CircleCI durfte der gekaperte Zugang Produktions-Token erzeugen; der Anbieter musste allen Kunden empfehlen, sämtliche Zugangsdaten zu rotieren^[14]. Bei Okta hatte das übernommene Service-Konto Einsicht in Support-Fälle – zunächst 134 betroffene Kunden^[15], Ende November 2023 korrigiert auf nahezu alle Nutzer des Support-Systems^[16]. Und bei GitHub genügten die gestohlenen OAuth-Token zweier Drittanbieter, um private Code-Bestände dutzender Organisationen herunterzuladen^[17]. Saubere Basis-Hygiene hätte jeweils den Einstieg verhindert, sauber geführte Maschinenidentitäten den Schaden klein gehalten.

Solche Vorfälle sind keine Seltenheit: In der CSA-Umfrage von 2024 (n = 818) hatte knapp jede fünfte Organisation bereits einen Sicherheitsvorfall im Zusammenhang mit nicht-menschlichen Identitäten; als häufigste Ursachen wurden unter anderem fehlende Rotation der Zugangsdaten und überprivilegierte Konten genannt^[18]. Der oben genannte Wert von rund der Hälfte^[3] misst etwas anderes – Sicherheitsverletzungen durch kompromittierte Maschinenidentitäten, andere Stichprobe, anderes Jahr. Beide Zahlen sind als Größenordnung zu lesen, nicht als vergleichbare Messreihe.

Zurück zum Marketing-Agenten. Eine manipulierte Anfrage nutzt genau den überzähligen Zugriff, an den sich längst niemand mehr erinnert: die Funktion zum Kundendaten-Export. Der Agent tut, wozu er scheinbar beauftragt wurde, und zieht die Kundenliste ab. Hätte er nur das Recht gehabt, Beiträge zu veröffentlichen, wäre der mögliche Schaden auf genau das begrenzt geblieben: ärgerlich vielleicht, aber kein Abfluss der Kundendaten (Abbildung 7).

5. Die Lösung: Lebenszyklus-Management für Maschinenidentitäten

Die gute Nachricht: Das Problem ist beherrschbar, und zwar mit bewährten Prinzipien, die nur konsequent auf nicht-menschliche Identitäten übertragen werden müssen. Der rote Faden ist der Lebenszyklus jeder Agenten-Identität: Vergabe, Verwaltung, Entzug (Abbildung 8).

Vergabe: erst den Funktionsumfang, dann die Rechte

Am wirksamsten ist die Frage, was ein Agent überhaupt können soll. Die OWASP-Empfehlung zu Excessive Agency verlangt zweierlei: die Rechte eines Agenten „auf das notwendige Minimum begrenzen“ und ebenso die Zahl seiner verfügbaren Funktionen klein halten^[8]. Gerade für kleinere Teams ist die zweite Hälfte der wirksamere Hebel, weil sie kein Rechtesystem voraussetzt: Was ein Agent gar nicht erst aufrufen kann, muss man auch nicht mühsam über Rechte einhegen. Für den Marketing-Agenten hieße das: die Funktion „Beitrag veröffentlichen“, und sonst keine.

Erst danach kommt das Prinzip der minimalen Rechtevergabe, Least Privilege: Jede Identität erhält nur die Berechtigungen, die ihre Aufgabe zwingend verlangt. Das Prinzip ist alt – Saltzer und Schroeder formulierten es 1975 als Entwurfsgrundsatz sicherer Systeme^[19] – und gilt nicht nur für Menschen: NIST SP 800-53 verlangt es in Kontrolle AC-6 ausdrücklich auch für Systemprozesse^[20], die OWASP-NHI-Liste erlaubt Verwaltungsrechte nur, wenn unumgänglich^[4], ISO/IEC 27001 führt Zugangssteuerung und Identitätsverwaltung in Anhang A als eigene Maßnahmen (A.5.15 bis A.5.18)^[21], und der IT-Grundschutz des BSI widmet dem Thema einen Baustein, dessen Zielsetzung ausdrücklich auch IT-Komponenten erfasst^[22]. Maschinenidentitäten stehen normativ also nicht am Rand.

Praktisch scheitert Least Privilege selten am Prinzip, meist an der Frage, welche Rechte ein Agent wirklich braucht. Zwei Wege führen hin: eng anfangen und anhand der Fehlermeldungen im Testbetrieb erweitern – oder die Zugriffsprotokolle eines laufenden Agenten auswerten und streichen, was er über Monate nie genutzt hat. Der zweite Weg ist bei bestehenden Agenten der schnellere.

Verwaltung: kurzlebig statt ewig, mit Inventar und Owner

Im laufenden Betrieb entscheiden sieben Hebel.

Rechte auf Zeit statt dauerhaft

Ein Recht, das einmal zugewiesen ist, bleibt zugewiesen – auch wenn der Agent es nur einmal im Quartal braucht. Die zweite Achse aus Abbildung 1 setzt genau hier an: Kritische Rechte werden nicht dauerhaft vergeben, sondern für einen Vorgang aktiviert und danach automatisch wieder entzogen (Just-in-Time-Rechtevergabe). Das Ziel dahinter heißt Zero Standing Privileges: außerhalb des Vorgangs besitzt die Identität das kritische Recht schlicht nicht, es kann also auch nicht missbraucht werden. Für den Marketing-Agenten hieße das, dass die Export-Funktion – wenn sie denn gebraucht wird – nicht dauerhaft an seiner Rolle hängt, sondern anlassbezogen freigeschaltet und danach wieder entzogen wird.

Kurzlebige statt dauerhafter Zugangsdaten

Die dritte Achse betrifft nicht das Recht, sondern den Schlüssel: Statische Langzeit-Secrets gehören durch kurzlebige, automatisch ablaufende ersetzt. Das Zero-Trust-Referenzmodell NIST SP 800-207 verankert Zugriffsentscheidungen „pro Anfrage“ und mit den „geringsten für die Aufgabe nötigen Rechten“^[23]. Cloud-Anbieter setzen das um: Temporäre Zugangsdaten laufen nach Minuten oder Stunden ab^[24]; föderierte Verfahren, bei denen sich der Agent ausweist, statt einen dauerhaften Schlüssel zu hinterlegen, können statische Schlüssel weitgehend ersetzen^[25]. Zwei Einschränkungen gehören dazu: Beides setzt voraus, dass Sie Identitäts- und Laufzeitumgebung selbst kontrollieren, und die Sicherheit hängt daran, wie eng die Vertrauensbeziehung gefasst ist – eine zu weit konfigurierte Föderation ist der klassische Fehler. Und innerhalb seiner Laufzeit ist auch ein kurzlebiges Token verwendbar: Kurzlebigkeit verkleinert das Zeitfenster, sie schließt es nicht (Abbildung 9).

Rotation, sichere Ablage und Aufspüren abgeflossener Secrets

Wo statische Schlüssel unvermeidbar sind, gehören sie automatisiert rotiert und in einem Secrets-Store verwahrt, nicht in Konfigurationsdateien oder im Code. Die OWASP-Empfehlung zum Umgang mit Secrets rät ausdrücklich zu dynamischen, kurzlebigen Zugangsdaten, die nach einem Neustart bereits abgelaufen wären^[26]. Drei Punkte werden dabei regelmäßig übersehen. Erstens ist Rotation kein Widerruf: Ein neuer Schlüssel macht den alten nicht ungültig, das muss ausdrücklich geschehen. Zweitens braucht jeder Secrets-Store selbst einen ersten Schlüssel, mit dem sich der Agent bei ihm anmeldet – dieser eine bleibt kritisch und gehört an die Plattform gebunden, nicht in eine Datei. Drittens sollten Sie aktiv suchen, ob Zugangsdaten bereits abgeflossen sind; Werkzeuge, die Code-Bestände und öffentliche Quellen auf Secrets durchsuchen, gehören inzwischen zum Standard.

Inventar und Eigentümerschaft

Man kann nur kontrollieren, was man kennt. Deshalb braucht es ein laufend gepflegtes Inventar aller Agenten-Identitäten und für jede einen benannten menschlichen Verantwortlichen. Der Vergleich liegt näher, als es klingt: Für Ihre Maschinen führen Sie ein Anlagenverzeichnis mit Verantwortlichem und Nutzungsdauer – für Ihre digitalen Mitarbeiter führen Sie keines. Große Plattformen bieten dafür inzwischen Governance-Funktionen, bei denen jede Agenten-Identität einen Verantwortlichen erhält, Zugriff zeitgebunden vergeben wird und Aktivität einsehbar ist^[27]. Prüfen Sie vor der Planung allerdings zwei Dinge: ob diese Funktionen in Ihrer Lizenz enthalten sind – die Governance-Funktionen für Agentenidentitäten setzen bei Microsoft eine gehobene Lizenzstufe voraus, die in den verbreiteten Mittelstandspaketen typischerweise fehlt^[27] – und ob Sie sich damit an einen Anbieter binden. Ein gepflegtes Tabellenblatt erfüllt denselben Zweck und ist der realistische Einstieg.

Wiederkehrende Überprüfung

Prüfen Sie turnusmäßig, ob jede erteilte Berechtigung noch gebraucht wird, und entziehen Sie, was nicht mehr nötig ist. Rechte, die einmal vergeben wurden, verschwinden sonst nie von selbst; sie sammeln sich an, bis niemand mehr weiß, warum ein Agent sie hat. Damit die Prüfung nicht zur Formsache wird, sollte sie eine Folge haben: Wer bis zum Stichtag nicht bestätigt, dass ein Zugang noch gebraucht wird, verliert ihn automatisch.

Menschliche Freigabe für kritische Aktionen

Für folgenreiche Schritte – Datenexport, Zahlungen, Löschungen – sollte ein Mensch bestätigen müssen. Die OWASP-Empfehlung nennt diese Human-in-the-Loop-Kontrolle als eigene Maßnahme gegen Excessive Agency^[8]. Beim Marketing-Agenten hätte eine Freigabepflicht für den Kundendaten-Export den Abfluss allein schon gestoppt. Damit sie wirkt, muss die Freigabe aber selten genug sein, dass sie noch gelesen wird, und aussagekräftig genug, dass der Freigebende erkennt, was er freigibt – „Agent möchte eine Aktion ausführen“ ist wertlos, „Agent möchte 12.400 Kundendatensätze exportieren“ ist eine Entscheidung. Eine Freigabe, die zwanzigmal am Tag erscheint, wird durchgeklickt.

Überwachung und Alarmierung

Protokollieren Sie, was Agenten-Identitäten tun, und lassen Sie Auffälliges melden. Nützliche Signale: ungewöhnliche Massenexporte, Anmeldung aus einem nie genutzten Netz, erstmalige Nutzung eines lange ruhenden Rechts, verändertes Aufrufmuster gegenüber dem eigenen Normalbetrieb, fehlgeschlagene Autorisierungen in Serie. Das gängige Signal „Zugriff außerhalb der Betriebszeiten“ trägt hier wenig – viele Maschinenidentitäten laufen rund um die Uhr; aussagekräftig ist die Abweichung vom bisherigen Takt. Ein Alarm auf den Kundendaten-Export hätte den Abfluss beim Marketing-Agenten früh sichtbar gemacht. Halten Sie außerdem fest, welcher Auftrag eine Aktion ausgelöst hat – ohne diese Zuordnung lässt sich hinterher nicht klären, ob der Agent manipuliert wurde. Für Anbieter von Hochrisiko-KI-Systemen verlangt Art. 12 EU AI Act automatische Protokollierung; Betreiber müssen die Protokolle, soweit sie ihrer Kontrolle unterliegen, nach Art. 26 Abs. 6 mindestens sechs Monate aufbewahren^[28].

Wenn Rechte allein nicht reichen

Rechtebeschneidung ist wirksam, aber nicht die einzige und oft nicht die schnellste Kontrolle. Vier Maßnahmen wirken unabhängig vom Identitätstyp und lassen sich meist auch dort einrichten, wo der Anbieter kein feines Rechtesystem bietet:

• Nur lesen als Voreinstellung. Ein Agent, der Vorschläge macht und einen Menschen ausführen lässt, kann nichts Falsches auslösen. Für viele Anwendungsfälle reicht das.
• An der Datenschicht begrenzen. Felder mit Personenbezug maskieren, Sichten beschränken, Exportmengen deckeln. Ein Agent, der pro Vorgang zehn Datensätze sehen darf, kann keine Kundenliste abziehen – egal, was seine Rolle sonst erlaubt.
• Abfluss begrenzen. Festlegen, wohin ein Agent Daten überhaupt senden darf. Genau diese Kontrolle beendete den ForcedLeak-Angriff^[12] – nicht eine Rechteänderung.
• Ausführung isolieren. Agenten mit Werkzeugzugriff abgeschottet laufen lassen, damit ein Ausbruch dort endet.

Sie ersetzen das Lebenszyklus-Management nicht, kaufen Ihnen aber Zeit, bis es steht – und machen einen Agenten auch dann tragbar, wenn sich seine Rechte nicht fein genug schneiden lassen.

Entzug: konsequent abmelden wie einen Mitarbeiter

Am Ende steht das Offboarding. Ein Agent, der seinen Zweck erfüllt hat, muss ebenso konsequent abgemeldet werden wie ein ausgeschiedener Mitarbeiter: entdecken, onboarden, außer Dienst stellen^[29]. Der billigste Weg dorthin führt über einen Prozess, den Sie schon haben – ergänzen Sie die Austritts- und Wechselcheckliste Ihrer Personalabteilung um eine Zeile: „Betreut diese Person Agenten oder automatisierte Zugänge? Wenn ja, an wen gehen sie über?“ Das schließt die häufigste Ursache verwaister Zugänge, ohne ein neues Verfahren zu erfinden.

„Abmelden“ heißt dabei mehr als das Konto zu löschen. Ein Agent hängt oft an einer Kette von Zugängen, die einzeln bestehen bleiben, wenn man nur das Hauptkonto deaktiviert. Welche Schritte Sie selbst ausführen können, hängt davon ab, was Ihr Anbieter freigibt – den Rest übernimmt Ihre interne IT, Ihr IT-Dienstleister oder der Anbieter auf Anfrage.

6. Compliance: Was Recht und Aufsicht verlangen – und was nicht

Die genannten Maßnahmen zahlen auf regulatorische Pflichten ein; für viele Unternehmen ein zusätzlicher Grund zu handeln. Wichtig ist dabei eine Unterscheidung: Das Recht schreibt Ergebnisse vor – Zugriffe zu begrenzen, Daten zu minimieren, die Verarbeitung sicher zu gestalten –, nicht ein bestimmtes technisches Mittel. Just-in-Time-Zugriff oder kurzlebige Tokens sind kluge Wege, diese Ergebnisse zu erreichen, aber nicht selbst gesetzlich vorgeschrieben (Abbildung 10).

Die Datenschutz-Grundverordnung (DSGVO) verlangt Datenminimierung (Art. 5 Abs. 1 lit. c), datenschutzfreundliche Voreinstellungen (Art. 25) sowie angemessene technische und organisatorische Maßnahmen einschließlich Zugriffskontrolle (Art. 32)^[30]. Ein Agent mit unnötigem Zugriff auf Kundendaten steht dazu im direkten Widerspruch. Die Verarbeitung gehört zudem ins Verzeichnis von Verarbeitungstätigkeiten (Art. 30) – nicht jeder Agent als eigener Eintrag, sondern als Teil der jeweiligen Tätigkeit, samt Zugriffen und Schutzmaßnahmen. Die Ausnahme für kleinere Organisationen (Art. 30 Abs. 5) entlastet kaum, weil ihre Rückausnahmen fast immer greifen.

Meist übersehen wird dabei: Ein Agent, der eine Kundenliste abzieht, löst eine Meldepflicht aus. Die Aufsichtsbehörde ist binnen 72 Stunden zu informieren (Art. 33 Abs. 1), bei hohem Risiko auch die Betroffenen (Art. 34); zu dokumentieren sind alle Vorfälle, auch die nicht meldepflichtigen (Art. 33 Abs. 5)^[30]. Die Frist läuft ab Kenntnis – und Kenntnis setzt voraus, dass Sie überhaupt sehen, was ein Agent tut. Das ist der eigentliche Grund, warum die Protokollierung aus Abschnitt 5 keine Kür ist. Bei umfangreicher Verarbeitung sensibler Daten kommt vorab eine Datenschutz-Folgenabschätzung nach Art. 35 in Betracht.

Die KI-Verordnung der EU (EU AI Act) greift enger, als oft angenommen, unterscheidet aber nach Rolle, Risiko und Zeitpunkt. Nach Rolle: Wer einen zugekauften Agenten einsetzt, ist regelmäßig Betreiber; die Pflichten für Hochrisiko-Systeme stehen vor allem in Art. 26 – bestimmungsgemäße Nutzung, menschliche Aufsicht, Beobachtung des Betriebs, Aufbewahrung der Protokolle. Die technischen Systempflichten (Art. 12, 14, 15) treffen in erster Linie den Anbieter^[28]. Die Zuordnung ist aber nicht fix: Wer ein zugekauftes Hochrisiko-System unter eigenem Namen anbietet, es wesentlich verändert oder seine Zweckbestimmung ändert, gilt nach Art. 25 selbst als Anbieter. Nach Risiko: Die strengen Pflichten gelten nur für hochriskant eingestufte Systeme; ein gewöhnlicher Marketing- oder Produktivitäts-Agent fällt nur darunter, wenn sein Verwendungszweck eine Hochrisiko-Kategorie erfüllt.

Zwei Pflichten gelten dagegen unabhängig von der Risikoeinstufung und betreffen praktisch jeden Leser: Art. 4 verlangt ein ausreichendes Maß an KI-Kompetenz bei den Personen, die im Auftrag des Unternehmens mit KI-Systemen umgehen – und gilt bereits. Art. 50 verlangt bei direkter Interaktion mit Menschen einen Hinweis auf die KI-Interaktion, soweit das nicht ohnehin offensichtlich ist. Nach Zeitpunkt: Eine Änderungsverordnung, die das Europäische Parlament am 16. Juni 2026 billigte und der der Rat am 29. Juni 2026 zustimmte, verschiebt die Hochrisiko-Regeln auf den 2. Dezember 2027 (eigenständige Systeme) bzw. 2. August 2028 (produktintegrierte Systeme)^[31]. Sobald ein Agent personenbezogene Daten verarbeitet, bleibt die DSGVO unabhängig davon relevant.

Für viele Mittelständler wichtiger als der AI Act ist allerdings NIS2 – und dieser Punkt wird regelmäßig übersehen. Die EU-Richtlinie gilt in Deutschland seit dem 6. Dezember 2025 über das novellierte BSI-Gesetz; das BSI rechnet mit rund 29.500 betroffenen Unternehmen. Erfasst sind, je nach Sektorzugehörigkeit, bereits Betriebe ab 50 Mitarbeitern beziehungsweise mit mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme (§ 28 BSIG). Fällt Ihr Unternehmen darunter, sind Zugriffskontrolle und die Verwaltung der IT-Werte (§ 30 Abs. 2 Nr. 9) sowie Mehr-Faktor-Authentisierung (Nr. 10) keine Empfehlung mehr, sondern Pflicht – ein Agenten-Inventar mit benannten Verantwortlichen ist genau die Bestandsaufnahme, die das verlangt. Für Sicherheitsvorfälle gelten gestufte Meldefristen: eine erste Meldung binnen 24 Stunden, eine Bewertung binnen 72 Stunden und ein Abschlussbericht binnen eines Monats nach der 72-Stunden-Meldung (§ 32 BSIG). Und die Verantwortung liegt ausdrücklich oben: Die Geschäftsleitung muss die Maßnahmen umsetzen und ihre Einhaltung überwachen, haftet dem Unternehmen gegenüber für Pflichtverletzungen und muss sich regelmäßig schulen lassen (§ 38 BSIG)^[32]. Ob Ihr Betrieb in den Anwendungsbereich fällt, ist eine Prüfung wert, bevor Sie das Thema vertagen.

Schließlich ein Punkt, der regelmäßig übersehen wird und ein Projekt nachträglich stoppen kann: Mitbestimmung. Die in Abschnitt 5 empfohlene Protokollierung des Agentenverhaltens betrifft, wenn der Agent unter einer delegierten Nutzeridentität läuft, unmittelbar Aktivitätsdaten von Mitarbeitern. Technische Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung der Arbeitnehmer zu überwachen, unterliegen nach § 87 Abs. 1 Nr. 6 BetrVG der Mitbestimmung des Betriebsrats – nach ständiger Rechtsprechung genügt dafür die objektive Eignung zur Überwachung, eine entsprechende Absicht ist nicht erforderlich^[33]. Wo ein Betriebsrat besteht, gehört er früh eingebunden; nachträglich eingeführte Überwachung ist angreifbar, und die damit erhobenen Daten sind es auch.

7. Handlungsplan für die nächsten Monate

Sie müssen nicht alles auf einmal lösen. Die folgenden Schritte sind nach Wirkung und Umsetzbarkeit sortiert.

1. Inventar anlegen. Beginnen Sie mit dem technischen Abgleich, nicht mit der Umfrage: Erteilte App- und OAuth-Freigaben sowie Dienstkonten in Ihren zentralen Plattformen (Microsoft 365, Google Workspace, Cloud-Konten) lassen sich auslesen und zeigen genau die vergessenen Zugänge. Ergänzen Sie eine Rundfrage an alle Abteilungen – aber sagen Sie dazu, was passiert: Wer einen Zugang meldet, bekommt ihn legitimiert, nicht abgeschaltet. Ohne diese Zusage meldet niemand ein Werkzeug, an dem seine Arbeit hängt. Priorisieren Sie danach die Zugänge mit Kunden- und Finanzdaten.
2. Eigentümerschaft zuordnen – mit Verfallsdatum. Jede Agenten-Identität bekommt einen namentlich verantwortlichen Menschen, fachlich und technisch. Wirksam wird das erst durch die Gegenprobe: Jeder Zugang erhält ein Ablaufdatum, und wer bis dahin nicht bestätigt, dass er noch gebraucht wird, verliert ihn. Aus „niemand kümmert sich“ wird so „der Zugang endet von selbst“.
3. Funktionen und Rechte stutzen. Fragen Sie zuerst, welche Funktionen ein Agent überhaupt aufrufen können muss, und schalten Sie den Rest ab – das wirkt schneller als jede Rechtefeinarbeit. Reduzieren Sie danach die Berechtigungen auf das Aufgabenminimum, beginnend bei den Zugängen zu sensiblen Daten. Wo das nicht fein genug geht, greifen die Kontrollen aus Abschnitt 5.
4. Zugangsdaten befristen. Ersetzen Sie dauerhafte Secrets schrittweise durch kurzlebige; wo das Tool das nicht hergibt, richten Sie Rotation und sichere Ablage ein und prüfen, ob Zugangsdaten bereits abgeflossen sind.
5. Offboarding verankern. Ergänzen Sie die bestehende Austrittscheckliste um Agenten und legen Sie fest, wer abschaltet, sobald eine Identität nicht mehr gebraucht wird.

Ein ehrliches Wort zu Aufwand, Kosten und Grenzen: Die ersten beiden Schritte sind vor allem Organisation – für einen Betrieb mit einer Handvoll Agenten erfahrungsgemäß ein bis zwei Personenwochen, verteilt über einige Wochen, und keine neue Lizenz; ein gepflegtes Tabellenblatt genügt. Teurer wird es erst bei Stufe 3: Kurzlebige Zugangsdaten, automatisierter Entzug und Verhaltensüberwachung setzen Werkzeuge voraus, die in den verbreiteten Mittelstandspaketen meist fehlen. Das ist die erste echte Investitionsentscheidung – und sie lässt sich vertagen, bis die Grundlagen stehen. Und Least Privilege senkt das Risiko erheblich, beseitigt es nicht: Ein korrekt eingegrenzter Agent kann weiterhin manipuliert werden; nur bleibt der Schaden auf seinen engen Rahmen begrenzt.

Quellen