Kurz gesagt
Sobald ein Agent Daten abruft, einen Entwurf ablegt oder einen Vorgang anstößt, reicht die Frage nach dem Login nicht mehr. Ein geteilter Team-Account kann zwar kurzfristig funktionieren, verschleiert aber im Audit, in der Fehleranalyse und beim Entzug, ob eine Person, ein Workflow oder ein Agent gehandelt hat.
Für Lumesco ist eine Agentenidentität kein Plattform-Feature zum Abhaken. Sie verbindet einen engen Prozess mit einem verantwortlichen Owner, den minimal nötigen Rechten und einem klaren Ende des Zugriffs. So bleibt ein Agent überprüfbar, ohne ihn wie einen menschlichen Mitarbeitenden zu behandeln.
Die wichtigsten Punkte
- Google Cloud beschreibt für Gemini-Agenten eigene Identitäten, Berechtigungen und einen Agenten-Audit-Trail; das bleibt eine Anbieterbeschreibung.
- OpenAI bündelte am 16. Oktober 2026 globale und app-spezifische External-access-Kontrollen für Enterprise-Apps.
- Ein geteilter Login ist keine Agentenidentität: Er trennt technische Handlung, fachliche Verantwortung und späteren Entzug nicht sauber.
- Für einen ersten produktiven Fall reichen Name, Owner, minimale Rechte, Protokollort und ein vorab entschiedener Stopppunkt.
Was in der Praxis sichtbar wird
Der aktuelle Produkttrend geht in Richtung Agenten, die über mehrere Tools arbeiten und länger laufende Aufgaben übernehmen. Google Cloud stellt dafür eigene Agentenidentitäten und zuordenbare Protokolle in Aussicht. OpenAI verweist für Enterprise-Apps auf zentrale Kontrollmöglichkeiten für Freigaben, verbundene Nutzer und das Abschalten eines Zugriffs. Beide Quellen beschreiben Funktionen ihrer Produkte, keine pauschale Schutzwirkung.
Für Unternehmen ist die operative Lücke oft banaler als die Architektur: Ein Agent läuft unter einem geteilten Funktionskonto oder über die Sitzung einer Person. Im Normalfall wirkt das effizient. Sobald ein Ergebnis falsch ist, ein Zugang nicht mehr gebraucht wird oder eine Prüfung ansteht, fehlt jedoch die klare Antwort auf drei Fragen: Wer oder was hat gehandelt, wer verantwortet den Zweck und wo wird der Zugriff beendet?
NIST liefert dafür keine fertige Agentenkarte. Der Rahmen macht aber deutlich, dass Rollen, Dokumentation und fortlaufendes Risikomanagement zusammengehören. Für einen kleinen Start lässt sich das auf eine überprüfbare Arbeitsidentität herunterbrechen, statt sofort ein organisationsweites Governance-Programm zu bauen.
Einordnung von Lumesco
Die richtige Trennung lautet nicht Mensch gegen Agent, sondern fachliche Verantwortung gegen technische Ausführung. Ein Mensch bleibt Owner eines Prozesses. Der Agent erhält eine eigene, eng beschriebene technische Rolle. Damit lassen sich Logs lesen, Rechte reduzieren und ein Zugriff entfernen, ohne nebenbei die Arbeitszugänge eines Teams zu beschädigen.
Warum ein geteilter Login den falschen Kontext liefert
Ein geteilter Zugang beantwortet nur, ob etwas technisch möglich ist. Er sagt nicht, ob die konkrete Handlung zum erlaubten Prozess gehört. Wenn Mitarbeitende und Agent denselben Account verwenden, vermischen sich persönliche Arbeit, automatisierte Schritte und nachträgliche Korrekturen in einem Verlauf.
Das Problem zeigt sich selten beim Demo-Chat. Es erscheint beim ersten Sonderfall: Eine Nachricht wurde vorbereitet oder versendet, ein Datensatz verändert oder ein Zugriff bleibt nach einem Projekt bestehen. Dann braucht das Team keine Vermutung, sondern eine zuordenbare technische Rolle und einen fachlichen Ansprechpartner.
- Geteilter Login: schnell eingerichtet, aber schwer einer konkreten Ausführung zuzuordnen
- Eigene Agentenidentität: beschreibbarer Zweck, begrenzte Rechte und getrennte Protokollspur
- Fachlicher Owner: entscheidet über Nutzen, Ausnahmefälle und Erweiterungen
- Technischer Entzug: kann erfolgen, ohne das Arbeitskonto eines Teams zu sperren
Die kleinste brauchbare Agentenkarte
Für einen ersten produktiven Fall braucht es keine überladene Berechtigungslandschaft. Eine kurze Agentenkarte reicht, sofern sie vor dem Zugriff festgehalten wird. Sie macht aus einer abstrakten KI-Funktion eine Rolle, die ein Team prüfen, ändern und bei Bedarf stoppen kann.
Der Name sollte den Prozess spiegeln, nicht das Modell: etwa „Anfragen-Vorprüfung“ oder „Angebotsentwurf Dokumente“. So wird bei einem Log oder einer Rückfrage sofort sichtbar, wofür die Identität existiert.
- Zweck: Welchen einen Prozessschritt bearbeitet der Agent?
- Owner: Wer ist fachlich für Ergebnis und Ausnahmen zuständig?
- Rechte: Welche Quelle darf er lesen und welche Aktion darf er höchstens vorbereiten?
- Nachweis: Wo stehen Lauf, Eingaben, Ergebnis und menschliche Freigabe?
- Rückweg: Wer pausiert oder entzieht den Zugriff bei Fehlern, Wechsel oder Prozessende?
Lesen, vorbereiten und auslösen getrennt entscheiden
Eine eigene Identität ist nur dann hilfreich, wenn sie nicht pauschal die Rechte eines Mitarbeitenden erbt. Ein Agent kann für einen Prozess Dokumente lesen und einen Entwurf erstellen, ohne eine externe Nachricht abzusenden, einen Preis zu ändern oder einen Vertrag anzulegen.
Diese Stufen sind kein Bürokratie-Extra. Sie erlauben einen produktiven Test mit überschaubarem Risiko. Wenn die vorbereiteten Ergebnisse fachlich verlässlich sind, lässt sich eine klar definierte Aktion später gezielt ergänzen. Wenn nicht, bleibt die Grenze sichtbar statt still im Hintergrund zu wachsen.
- Lesen: nur die Quellen, die für den konkreten Vorgang nötig sind
- Vorbereiten: Zusammenfassung, Entwurf oder Entscheidungsvorlage für eine Person
- Auslösen: externe Nachricht oder Änderung nur mit expliziter Regel und angemessener Freigabe
- Erweitern: neue Rechte erst nach dokumentierter Prozesswirkung und erneuter Owner-Entscheidung
Der Entzugspfad ist Teil der Einführung
Agenten werden angepasst, Prozesse enden und Verantwortliche wechseln. Deshalb muss die Frage nach dem Entfernen eines Zugriffs vor dem ersten Lauf beantwortet sein. Ein sauberer Entzugspfad verhindert, dass ein alter Pilot unbemerkt weiter Zugriff behält oder dass ein Team für eine Bereinigung unnötig seinen gesamten Arbeitszugang verliert.
Praktisch genügt zu Beginn ein benannter Owner, eine dokumentierte Stelle für die Rechteverwaltung und ein kurzer Test: Kann die Identität pausiert werden, ohne andere Arbeitsabläufe zu blockieren? Erst wenn dieser Rückweg funktioniert, ist ein Agentenzugriff betrieblich belastbar genug für den nächsten Scope.
- Pause: Lauf und weitere Aktionen sofort anhalten
- Entzug: Zugriffsrechte für die Agentenidentität entfernen
- Übergabe: neuen Owner und Zweck dokumentieren, bevor Rechte weiterlaufen
- Review: bei neuer Datenquelle, neuer Aktion oder verändertem Prozess erneut entscheiden
Entscheidungsfilter
Bevor daraus ein Projekt wird, sollten diese Fragen klar beantwortet sein.
- Hat der Agent eine eindeutige technische Identität statt eines geteilten Mitarbeiter- oder Team-Logins?
- Welcher fachliche Owner darf Zweck, Rechte und Erweiterungen dieser Rolle freigeben?
- Welche Systeme und Aktionen sind erlaubt – und welche bleiben bewusst bei einer Person?
- Wo ist nachvollziehbar, welche Handlung der Agent wann ausgelöst oder vorbereitet hat?
- Wie wird die Identität pausiert oder entzogen, wenn der Prozess endet, der Owner wechselt oder ein Fehler auffällt?
Eigene Evidenz & Quellen
Die Einordnung basiert auf Lumesco-Projektmustern und öffentlich prüfbaren Quellen.
- Aus ProjektenLumesco Scoping-Muster für KI-Governance
Wiederkehrende Projektfrage bei produktiven KI-Workflows: Für jeden Zugriff muss sichtbar bleiben, welcher fachliche Zweck, welcher technische Account, welche erlaubte Aktion und welcher verantwortliche Mensch zusammengehören.
Quelle öffnen - QuelleGoogle Cloud: Gemini-Agenten mit eigener Identität und Audit-Trail
Google Cloud beschreibt für Gemini-Agenten eigene Identitäten, fein abgestufte Berechtigungen und einen Audit-Trail, der Handlungen dem Agenten zuordnet. Das ist eine Anbieterbeschreibung, kein allgemeiner Sicherheits- oder Wirksamkeitsnachweis.
Quelle öffnen - QuelleOpenAI: zentrale External-access-Kontrollen für Enterprise-Apps
OpenAI nennt zentrale globale und app-spezifische Freigaben, verbundene Nutzer sowie das Deaktivieren von App-Zugriff. Das ersetzt keine eigene Rollen- und Rechteplanung für einen konkreten Agentenfall.
Quelle öffnen - QuelleNIST AI RMF Core: Govern, Map, Measure, Manage
Der NIST AI Risk Management Framework Core ordnet dokumentierte Rollen, Prozesse und laufendes Risikomanagement als kontinuierliche Aufgabe ein. Der freiwillige Rahmen ist keine Produkt- oder Rechtszusage.
Quelle öffnen
Bildidee für Distribution
Empfohlenes Motiv: Eine klar beschriftete Agenten-Identitätskarte zwischen einem Prozess-Owner und drei begrenzten Systemzugängen; daneben ein sichtbarer Pause- oder Entzugspfad. Keine Roboterfigur, keine Gesichtserkennung-Ästhetik.
Nächster sinnvoller Schritt
Nehmen Sie einen Agentenfall, der bereits auf interne Daten oder Tools zugreifen soll. Notieren Sie auf einer Karte: Name des Agenten, fachlicher Owner, erlaubte Systeme, erlaubte Aktionen, Protokollort und Auslöser für Entzug oder Pause. Wenn ein Punkt offen ist, sollte der Agent vorerst nur vorbereiten – nicht selbst auslösen.