Man stelle sich einen Massenexport von Kundendaten im Audit-Log vor, ausgeführt unter dem Konto eines Entwicklers – kein Einbruch, kein geleaktes Passwort, keine fremde IP. Ein KI-Agent hat die Zugangsdaten dieses Entwicklers benutzt und genau das getan, wozu er beauftragt war. Mit KI-Systemen, die dauerhaft mitarbeiten, rückt dieses Szenario näher. Itamar Apelblat, Mitgründer und CEO des Sicherheitsanbieters Token Security, beschreibt den Wandel in einem von seiner Firma gesponserten Beitrag auf BleepingComputer als dritte Welle der arbeitsbezogenen KI.
Seine These: Die ersten beiden Wellen ließen sich noch in bestehende Zugriffsmodelle einordnen. Die dritte nicht. Sobald KI-Systeme dauerhaft existieren, eigene Aufgaben verfolgen und über Monate hinweg Zugriff auf Daten und Infrastruktur behalten, verhalten sie sich weniger wie Werkzeuge und mehr wie Kollegen. Kollegen brauchen eine Identität. Wer verstehen will, warum die aktuellen Sicherheitsmodelle an dieser Stelle reißen, muss sich anschauen, woher sie kommen – und was sie stillschweigend vorausgesetzt haben.
Drei Wellen, ein Muster: Vom Chatfenster zum Kollegen
Die erste Welle waren sitzungsgebundene Chats. Das Risiko lag in dem, was das Modell sagt: Halluzinationen, Datenlecks in der Antwort, unbedachte Formulierungen. Die Branche antwortete mit Prompt-Filtern, Guardrails und Klassifizierung von Ausgaben – Werkzeuge, die auf Text schauen. Die zweite Welle brachte aufgabenbezogene Agenten. Hier verschob sich das Risiko von der Aussage zur Handlung. Plötzlich ging es nicht mehr darum, was ein Modell behauptet, sondern was es tatsächlich tut: welche API es aufruft, welche Datei es schreibt, welchen Datensatz es verschiebt. Die Antwort darauf waren Zugriffskontrollen und Freigabeprozesse. Ein Mensch muss vor der heiklen Aktion nicken.
Genau dort stehen die meisten Unternehmen heute. Apelblat hält das für eine Momentaufnahme. Die Torpfosten, so seine Argumentation, wurden bereits weitergeschoben, und die dritte Welle steht unmittelbar bevor: dauerhaft existierende KI-Coworker, die nicht für eine einzelne Aufgabe starten und danach verschwinden, sondern bleiben. Ein Indiz findet er in der Wortwahl der Anbieter. Microsoft spricht von Agenten als „digitalen Kollegen“, Sam Altman skizzierte die Vision virtueller Mitarbeiter bereits im Februar 2025. Vokabular ist keine technische Spezifikation, aber es verrät, wohin die Produkte führen sollen.
Für das Sicherheitsmodell bedeutet das einen Bruch. Man kann sich das mit dem Firmenausweis vorstellen: Ein heutiger Agent borgt sich den Ausweis eines Menschen, benutzt ihn eine Weile und gibt ihn danach zurück. Ein persistenter Coworker gibt ihn nie zurück. Er behält ihn, arbeitet weiter, sammelt neue Berechtigungen – und ist irgendwann mit einem Zugriffsprofil unterwegs, das niemand bewusst entworfen hat.
Warum Persistenz aus einem Werkzeug einen Mitarbeiter macht
Freigabe für Freigabe funktioniert nur, solange jemand da ist, der freigeben kann. Ein Coworker, der nachts, am Wochenende oder parallel in zwanzig Threads arbeitet, kann nicht für jede einzelne Aktion auf einen Menschen warten. Für Apelblat folgt daraus: Zugriff muss vorab bereitgestellt werden, gepaart mit der Möglichkeit, bei Bedarf zusätzliche Rechte anzufordern. Das ist ein anderes Modell als die ereignisgesteuerte Einzelfreigabe, die heute als sicherer Standard gilt.
Dazu kommt, dass Identitäten speziell für KI-Agenten bislang die Ausnahme sind. Der Normalfall sieht anders aus: OAuth-Grants, Übergaben innerhalb einer Sitzung und Service-Accounts. Bei den ersten beiden Varianten ist der Mensch die primäre Entität, auch wenn der Agent handelt. Der Service-Account wiederum wurde selten für einen Agenten geschaffen, sondern meist für eine andere Maschine und dann zweckentfremdet. In allen drei Fällen fehlt genau das, was ein dauerhafter Coworker bräuchte: eine eigene, klar umrissene Identität mit dokumentiertem Zweck.
Persistenz erzeugt zusätzlich Standing Privileges, also dauerhaft bestehende Berechtigungen, die einfach da sind, ob genutzt oder nicht. Bei Menschen ist das ein altbekanntes Problem, das niemand sauber gelöst hat. Bei Maschinen wird es ärger. Ein digitaler Kollege braucht einen Lebenszyklus, der das Deprovisioning ausdrücklich einschließt: Was passiert, wenn das Projekt endet, das Team aufgelöst wird oder die verantwortliche Person das Unternehmen verlässt? Wer diese Frage beim Anlegen nicht beantwortet, baut einen Zugang, den niemand mehr kontrolliert.
Verschärft wird das durch Access Creep. Wer lange genug im Unternehmen ist, sammelt Rechte – das ist der älteste ungelöste Fall der Identity Governance. Für Maschinen rechnet Apelblat mit einer schlimmeren Dynamik, aus zwei Gründen: Zugriff akkumuliert sich schneller, und Agenten nutzen tendenziell alles, was sie bekommen. Mehrere für sich genommen vernünftige Einzelberechtigungen können zusammen eine Reichweite ergeben, die niemand beabsichtigt hat. Der Schlüsselbund wächst nicht durch böse Absicht, sondern durch Gleichgültigkeit gegenüber dem, was schon dranhängt.
Was die großen Plattformen heute tatsächlich ausgeben
Praktisch heißt das: Die zwei am weitesten verbreiteten Agentenplattformen geben ihren Agenten derzeit keine eigenen Credentials. Nach Darstellung des Autors betreiben weder Anthropic noch OpenAI den OAuth-Client-Credentials-Grant in ihren gehosteten Chat-Produkten, und die Konnektoren von ChatGPT lehnen Service-Accounts sowie JWT-Assertions ab. Entwickler können einem Agenten über die APIs ein statisches Bearer-Token mitgeben. Das ist keine Identität, sondern ein Schlüssel ohne Namen.
Die Folge ist kein theoretisches Risiko. Wenn ein KI-System unter den Rechten eines Menschen handelt, steht im Audit-Trail in der Regel der Mensch als Akteur. Die Protokolle werden dadurch unzuverlässig. Eine Untersuchung, die auf solchen Logs baut, kann nicht sauber unterscheiden, ob ein Mitarbeiter um drei Uhr nachts gehandelt hat oder ein Agent in seinem Namen. Attribution ist keine Formalität. Ohne sie lassen sich Sicherheitsvorfälle nicht aufklären.
Zugleich belastet der Wunsch, den Menschen in der Schleife zu behalten, genau diesen Menschen. OAuth geht davon aus, dass jemand einen Zustimmungsbildschirm liest und eine feste Liste von Scopes absegnet. Agenten geben sich mit ihrer initialen Berechtigung selten zufrieden, sie entdecken Werkzeuge zur Laufzeit und wollen sie benutzen. Alle paar Minuten eine sensible Aktion zu bestätigen ist nervig und sicherheitsschädlich zugleich, denn Aufmerksamkeit ist eine endliche Ressource. Wer hundertmal klickt, klickt beim hundertundersten Mal ohne hinzusehen.
Googles Chip und der Praxistest aus dem Podcast
Die Anforderung ist real. Ein Blick auf die Menschen, die solche Produkte bauen, zeigt das. Tara Seshan, die bei OpenAI das Produkt für ChatGPT Work und Codex verantwortet, beschrieb in einem Podcast-Interview, was einen Agenten tatsächlich nützlich macht. Modellintelligenz sei nur ein Teil davon. Der Rest sei das, was sie als handfestes Alltagsgeschäft bezeichnete: Zugang zu Daten, Cloud-Infrastruktur und Verlässlichkeit. Ihr Vergleich: Man stellt jemanden ein und sperrt ihn dann in einen Raum ohne Google Docs, Slack und Unternehmensdatenbank. Dieser Kollege wird nicht wirksam sein. Ein isolierter Cloud-Agent, so ihr Argument, aus genau demselben Grund ebenso wenig.
Seshan beschrieb außerdem, dass ihr Agent Unteragenten startet, um Arbeit zu parallelisieren, und eine nahe Zukunft, in der ihre Agenten und die ihrer Kollegen gemeinsam an Aufgaben arbeiten. Beide Richtungen sind plausibel. Beide setzen ein Identitätsmodell voraus, das es noch nicht gibt. Denn wenn der Agent einer Person Arbeit an den Agenten einer anderen Person übergibt, gehört das ausführende Credential dem Menschen, der die Kette irgendwann gestartet hat. Verantwortung und Ausführung fallen auseinander.
Der Rückblick lohnt. Google hat 2024 auf der I/O einen Workspace-Agenten namens Chip vorgestellt, mit eigenem Workspace-Konto, zugewiesener Rolle, konfigurierten Berechtigungen und einem festen Zielkatalog. Chip trat Chaträumen bei und antwortete aus dem Verlauf, den er sehen durfte. Die damalige Workspace-Vizepräsidentin Aparna Pappu sagte, es sei noch viel Arbeit nötig, bevor solche virtuellen Teammitglieder produktreif seien. Chip blieb eine Demo. Ausgeliefert wurden stattdessen Agenten, die die Autorität eines Menschen erben – das Gegenteil des ursprünglichen Entwurfs.
Fünf Schritte, die der Anbieter empfiehlt
Aus dieser Analyse leitet Apelblat einen konkreten Katalog ab. Man muss ihn nicht übernehmen, aber als Prüfrahmen taugt er für jedes Unternehmen, das Agenten laufen hat oder laufen lassen will.
Erstens: Schatten-Coworker finden. Ein Register erfasst nur die Agenten, an die jemand gedacht hat. Die anderen erkennt man an ihrem Authentifizierungsverkehr – an OAuth-Grants, API-Schlüsseln und Login-Mustern, die kein Mensch erklären kann.
Zweitens: Jeder persistente Agent bekommt eine eigene Identität. Solange er sich als Mensch authentifiziert, kann keine nachgelagerte Kontrolle die beiden auseinanderhalten, und keine Untersuchung ordnet eine Aktion korrekt zu.
Drittens: Ein menschlicher Eigentümer wird festgehalten. Verwaiste Agenten mit aktiven Credentials sind laut dem Autor die häufigste Quelle agentenbezogener Standing Privileges – Zugänge ohne Ansprechpartner, die niemand mehr hinterfragt.
Viertens: Berechtigungen werden auf den Agenten zugeschnitten, nicht auf die Person, die ihn gestartet hat. Ein Agent, der Jira liest, sollte kein Token halten, das auch in den Cloud-Provider schreiben darf, nur weil der auslösende Entwickler zufällig beides durfte.
Fünftens: Vorab festlegen, wann der Agent stirbt. Digitale Coworker sind nicht projektgebunden, aber deshalb nicht unsterblich. Bedingungen wie eine aufgelöste Teamstruktur, ein ausscheidender Eigentümer oder eine definierte Leerlaufzeit gehören in die Konfiguration, nicht ins Nachdenken danach.
Was daraus folgt
Nebeneinander gelegt ergibt sich ein Muster. In Welle eins lag das Risiko in der Ausgabe, die Antwort waren Filter und Guardrails. In Welle zwei verlagerte es sich auf Handlungen, die Antwort waren Zugriffskontrolle und Freigaben. In Welle drei verschwindet der Mensch aus der Schleife, während der Zugriff bestehen bleibt. Nicht die Autonomie allein macht die Sache unangenehm, sondern die Autonomie mit dauerhaften Rechten.
Die Plattformanbieter haben begonnen zu reagieren. Microsoft liefert Entra Agent ID mit eigenständigen Agenten-Identitäten und einem benannten menschlichen Sponsor. Okta hat Agenten-Identitäten ins Universal Directory aufgenommen, mit kurzlebigen, begrenzten Tokens und einem Widerrufspfad. SailPoint und CyberArk haben vergleichbare Angebote. Der Haken ist strukturell: Jede dieser Lösungen sichert Agenten innerhalb der eigenen Umgebung. Wer plattformübergreifend arbeiten muss, findet den einzigen durchsetzbaren Kontrollpunkt bei der Identität, weil Identität den Zugriff auf jede einzelne Aktion regelt.
Transparenz gehört dazu: Der zitierte Beitrag ist gesponserter Content des Anbieters Token Security und endet mit einem Produktaufruf. Die technische Analyse ist deshalb nicht falsch, aber sie ist nicht interessefrei. Wer die Empfehlungen umsetzt, sollte sie als Prüfliste lesen und nicht als Einkaufsliste – die fünf Schritte funktionieren unabhängig davon, welches Werkzeug am Ende darunter steht.
Für dich und dein Team heißt das vor allem: Bestandsaufnahme vor Werkzeugauswahl. Wie viele Agenten authentifizieren sich in eurer Umgebung gerade mit den Zugangsdaten von Menschen? Wer ist der Eigentümer, und was passiert, wenn diese Person geht? Die Antworten darauf sind unangenehmer als jede Produktentscheidung – und genau daran zeigt sich, ob euer Sicherheitsmodell die dritte Welle übersteht. Ein Kollege bekommt einen Ausweis, bevor er eine Aufgabe bekommt. Für Maschinen sollte dieselbe Reihenfolge gelten.
Quelle: bleepingcomputer.com
