Die Reception verbindet einen neuen Termin-Agenten mit dem Kalender. Am schnellsten geht es mit dem bestehenden Microsoft- oder Google-Login einer Mitarbeiterin. OAuth bestätigen, Zugriff funktioniert, Pilot läuft.
Drei Monate später wechselt die Mitarbeiterin die Stelle. Ihr Account wird gesperrt. Plötzlich fallen Termine aus — oder schlimmer: Ein altes Token funktioniert weiter, niemand weiss genau, welche Automation noch darunter arbeitet, und im Audit-Log sieht jede Aktion so aus, als hätte die ehemalige Mitarbeiterin sie selbst ausgeführt.
Das ist kein exotischer Security-Fall. Es ist ein Identitätsproblem.
Ein AI-Agent, der selbstständig auf CRM, Kalender, Dateien oder APIs zugreift, sollte nach Möglichkeit eine eigene technische Identität haben: Service Account, Managed Identity oder ein vergleichbares Workload-Identity-Konzept. Der Name hängt vom Anbieter ab. Die Idee bleibt gleich: Die Automation arbeitet nicht „als Anna“ oder „als Chef“, sondern als klar benannter technischer Akteur mit eigenem Lebenszyklus.
Der AI Agent Service Account löst ein Verantwortungsproblem
Berechtigungen ohne eigene Identität sind schwer sauber zu verwalten. Wenn drei Automationen denselben Mitarbeiter-Login verwenden, können Sie zwar theoretisch Rechte einschränken. Praktisch wissen Sie aber später kaum noch, welche Aktion zu welchem Prozess gehörte.
NIST beschreibt in seiner Zero-Trust-Architektur Identität als zentrale Grundlage für Zugriffsentscheidungen. SP 800-207A erweitert diesen Gedanken ausdrücklich auf Anwendungen und Services in cloud-nativen Umgebungen. Microsoft beschreibt Managed Identities als eigenständige Workload-Identitäten, deren Zugang nicht an ein menschliches Benutzerkonto gebunden werden muss.
Für ein KMU ist der Nutzen sehr konkret: Wenn der Termin-Agent eine eigene Identität hat, kann man nur diesen Agenten deaktivieren, seine Rechte ändern oder seine Aktivitäten filtern, ohne gleichzeitig den Arbeitsplatz eines Menschen lahmzulegen.
Bestätigter Fakt: moderne Identity-Systeme unterstützen nichtmenschliche bzw. Workload-Identitäten und feinere Zugriffssteuerung.
Empfehlung: Jede produktive Automation, die eigenständig Aktionen ausführt, bekommt nach Möglichkeit eine klar benannte technische Identität und einen menschlich Verantwortlichen.
Was schiefgeht, wenn der Agent „als Mitarbeiter“ arbeitet
Das offensichtliche Problem ist zu viel Zugriff. Ein Geschäftsführer-Account sieht vielleicht Mail, Drive, Rechnungen und Personaldokumente. Der Agent braucht für seinen Job aber nur zwei Kalender und drei CRM-Felder. Wer den menschlichen Account wiederverwendet, startet häufig mit einem viel zu grossen Berechtigungsumfang.
Das zweite Problem ist Attribution. Im Log steht „maria@example… hat Termin geändert“. War das Maria? Der Agent? Ein Skript? Ein Integrationstool? Bei einem Fehler wird die Spur unnötig unscharf.
Das dritte Problem ist Offboarding. Menschen wechseln Rollen, gehen in Ferien, ändern Passwörter oder verlassen die Firma. Eine Automation sollte nicht heimlich an diesem Lebenszyklus hängen.
Und das vierte Problem ist Incident Response. Wenn etwas auffällig wird, möchten Sie die betroffene Automation isolieren. Mit einer geteilten Identität bedeutet „Zugang sperren“ möglicherweise auch: Mitarbeiter kann nicht mehr arbeiten.
Ein Beispiel aus einer Garage: Ein Agent darf aus einer Website-Anfrage einen Terminwunsch im Werkstattkalender vormerken. Dafür braucht er vielleicht „Kalender lesen“, „vorläufigen Termin schreiben“ und einen engen CRM-Zugriff. Er braucht nicht automatisch das persönliche Postfach des Werkstattleiters.
Eine gute Machine Identity ist mehr als ein neuer Benutzername
Ein Service Account mit Vollzugriff ist keine Verbesserung. Die technische Identität wird erst nützlich, wenn sie wie ein kleines, eigenes Arbeitskonto behandelt wird.
Ein sinnvoller Setup-Ablauf:
- Einen Zweck pro Identität definieren. Zum Beispiel
agent-booking-prod, nichtai-master-account. - Nur notwendige Scopes vergeben. Lesen und Schreiben getrennt betrachten; ganze Drives oder Mailboxen vermeiden, wenn einzelne Ressourcen reichen.
- Menschlich Verantwortliche und Systemverantwortliche dokumentieren. Wer entscheidet fachlich über den Prozess, wer kann Credentials oder Zugänge ändern?
- Credential-Lebenszyklus festlegen. Wo möglich Managed Identity statt statischem Secret; andernfalls Rotation, Ablauf und sichere Ablage definieren.
- Widerruf testen. Ein echter Test muss zeigen, dass die Identität deaktiviert werden kann und der Agent danach keine Aktion mehr ausführt.
- Logs eindeutig markieren. In Audit- und Business-Logs sollte erkennbar sein, dass die Aktion vom Agenten kam.
Besonders wichtig: Produktions- und Testidentitäten nicht vermischen. Ein Test-Agent, der mit echten Kundenrechten arbeitet, zerstört genau die Grenze, die man eigentlich schaffen wollte.
Ausnahmen, Delegation und Break-glass
Nicht jedes SaaS-Produkt bietet eine perfekte Machine Identity. Manche KMU-Tools unterstützen nur normale Benutzerkonten. Dann ist die zweitbeste Lösung oft ein dedizierter technischer Benutzer mit minimalen Rechten, klarer Kennzeichnung und ohne interaktive Alltagsnutzung.
Bei Aktionen im Namen eines Mitarbeiters kann Delegation sinnvoll sein. Der Agent hat weiterhin eine eigene Identität, protokolliert aber zusätzlich, für wen und auf Basis welcher Freigabe er gehandelt hat. So bleibt der technische Akteur sichtbar.
Für Notfälle braucht es einen Break-glass-Weg. Wenn die Automation ausfällt, muss ein Mensch den Prozess weiterführen können. Das bedeutet nicht, dass der Agent ein gemeinsames Passwort mit dem Team bekommt. Es bedeutet, dass der Betrieb weiss, wie Termine, Offerten oder Tickets manuell übernommen werden.
Die Übergabe greift auch bei Berechtigungsproblemen: Wenn ein Agent für eine legitime Aufgabe plötzlich mehr Zugriff benötigt als sein normales Profil erlaubt, sollte er nicht selbst seine Rechte erweitern. Die Aufgabe geht an einen Verantwortlichen.
Der kleinste sichere Pilot
Nehmen Sie einen Prozess mit überschaubarem Schadenpotenzial. Geben Sie dem Agenten eine eigene Identität und exakt die Rechte für diesen Ablauf. Kein „vorübergehend Admin, bis alles funktioniert“.
Testen Sie drei Dinge absichtlich: eine erlaubte Aktion, eine verbotene Aktion und den vollständigen Widerruf. Danach prüfen Sie die Logs. Können Sie ohne Rätsel erkennen, welcher Agent was, wann und in welchem Datensatz getan hat?
Für den Pilot reichen fünf Kennzahlen: Anteil der Aktionen mit eindeutiger Agenten-Attribution, Anzahl abgelehnter Zugriffe ausserhalb des Scopes, Zeit zum Sperren der Identität, Zahl manueller Berechtigungsausnahmen und Anteil der Credentials mit definiertem Ablauf oder Rotation.
Der wichtigste Test ist nicht, ob der Agent funktioniert. Das schafft fast jeder Demo-Aufbau. Der wichtigere Test ist: Können Sie ihn in zwei Minuten sauber abschalten, ohne einen Mitarbeiter zu sperren oder andere Automationen zu zerstören?
Eine eigene Machine Identity macht einen Agenten nicht automatisch sicher. Sie macht seine Rechte, seinen Lebenszyklus und seine Verantwortung aber steuerbar. Genau das braucht ein KMU, bevor aus einem kleinen Pilot ein Prozess wird, auf den Kunden und Mitarbeitende sich verlassen.
Die Berechtigungs- und Audit-Log-Prüfung erklärt, was ein Agent tun darf. Das Agent-Inventar hält fest, wo er läuft. Die eigene Identität verbindet beides: Sie macht den Eintrag technisch abschaltbar.
Quellen
FAQ
Braucht wirklich jeder kleine Agent einen eigenen Account?
Nicht jede interne Textfunktion. Sobald eine Automation eigenständig auf Geschäftssysteme zugreift oder schreibt, ist eine separate Identität jedoch sehr sinnvoll.
Ist ein Service Account dasselbe wie ein Managed Identity?
Nicht exakt. Die Implementierung unterscheidet sich je Plattform. Beide Konzepte trennen aber technische Workloads von menschlichen Benutzeridentitäten.
Darf ein Agent den Account eines Mitarbeiters delegiert nutzen?
Besser ist eine eigene Agentenidentität mit dokumentierter Delegation. So bleibt nachvollziehbar, wer technisch gehandelt hat.
Was tun, wenn die Software keine Service Accounts unterstützt?
Nutzen Sie wenn möglich einen dedizierten technischen Benutzer mit minimalen Rechten und prüfen Sie, ob der Anbieter bessere Workload-Identitäten plant.
Wie oft sollten Rechte überprüft werden?
Mindestens bei Prozessänderungen, neuen Tools, Rollenwechseln und Sicherheitsvorfällen; zusätzlich ist ein regelmässiger Review sinnvoll.