Wenn KI handelt: Zugriffskontrolle und Identity Access Management

Eine gute Agent-Identität beantwortet nicht nur die Frage «Wer ist das?», sondern zusätzlich drei Fragen, die bei menschlichen Identitäten meist implizit beantwortet sind:

1. Wer ist verantwortlich (Owner)?
2. Wie lange gilt die Identität (Ablauf)?
3. In wessen Auftrag handelt der Agent gerade (Delegation)?

So wie ein Mitarbeitender ein Benutzerkonto mit definierten Attributen hat, erhält der KI-Agent ein eigenes, vollständiges Profil. Das nachfolgende Beispiel illustriert eine Agent-Identität im Verzeichnisdienst:

Das bekannte Least Privilege Grundprinzip gilt auch für KI-Agenten, muss jedoch neu gedacht werden, um der modernen hybriden Praxisrealität zwischen Menschen und Maschinen gerecht zu werden.

Least-Privilege folgt dem Prinzip: Jede Entität erhält nur die Berechtigungen, die sie für eine konkrete Aufgabe zwingend benötigt, nicht mehr. Bei menschlichen Usern oder klassischen Systemkonten ist das eine weitgehend gelöste Disziplin. Bei KI-Agenten versagt dieses Modell in seiner klassischen Form, weil drei Grundannahmen nicht mehr zutreffen:

• Aufgaben sind nicht vorhersehbar. Ein Agent erhält häufig breite Instruktionen und entscheidet selbst, welche Tools er dafür einsetzt.
• Berechtigungen sind keine binäre Entscheidung. Ein Agent, der E-Mails lesen darf, kann unter Umständen auch senden, weiterleiten oder löschen, je nach API-Granularität.
• Kontext verändert den Bedarf dynamisch. Was ein Agent in Aufgabe A benötigt, ist in Aufgabe B irrelevant, aber die Berechtigung bleibt bestehen.

A) Taskbasierte statt rollenbasierte Berechtigungen
Klassisches IAM vergibt Rollen (z.B. «HR-Manager»). Für KI-Agenten ist ein taskbasierter Ansatz zielführender: Der Agent erhält nur die Berechtigungen, die für den spezifischen, aktuellen Task notwendig sind und diese verfallen nach Abschluss automatisch.

Statt: Agent hat dauerhaft Lesezugriff auf alle Finanzdaten
Besser: Agent erhält für Task X Lesezugriff auf Rechnungen aus Q2 2026; gültig für 15 Minuten.

B) Scoped Tokens statt permanenter API-Keys
API-Keys mit breitem Scope sind das Äquivalent eines Generalschlüssels. Für KI-Agenten sollten stattdessen kurzlebige, eng begrenzte Tokens verwendet werden analog zu OAuth-Scopes, aber granularer auf Ressourcenebene definiert.

C) Tool-Level Permissions
Jedes Tool, das einem Agenten zur Verfügung steht, sollte einzeln und explizit freigegeben werden, nicht als Paket. Die Faustregel: Wenn ein Tool nicht zwingend für den definierten Anwendungsfall benötigt wird, ist es nicht verfügbar.

D) Hierarchische Agent-Berechtigungen in Multi-Agent-Architekturen
Wenn ein Orchestrator-Agent mehrere Sub-Agenten koordiniert, darf kein Sub-Agent mehr Berechtigungen erhalten als der Orchestrator selbst besitzt ( siehe dazu Teil 1 dieser Serie). Berechtigungen können delegiert, aber nie eskaliert werden. Dieses Prinzip wird in der Literatur als Privilege Containment bezeichnet.

Die kurze Antwort lautet: Nein, nicht automatisch. Nur wenn die Architektur das explizit erzwingt.
Das ist ein wichtiger Punkt, den man als CISO nicht schönreden sollte: Vollständige Nachvollziehbarkeit ist keine Eigenschaft, die KI-Agenten von sich aus mitbringen. Sie ist eine Architekturentscheidung, die aktiv eingebaut werden muss. Ohne diese Vorkehrungen entstehen typischerweise drei Lücken:

1. Delegationsketten verlieren sich. Agent A beauftragt Agent B, der Agent C beauftragt — wenn nicht jede Weitergabe explizit protokolliert wird, bleibt am Ende nur sichtbar, dass etwas passiert ist, nicht warum und in wessen ursprünglichem Auftrag. Ein Agent handelt nicht einfach im Auftrag einer definierten Abteilung, sondern erhält pro Aktion eine delegierte Autorisierung.

2. Reasoning ist nicht deterministisch. Zwei identische Anfragen können zu unterschiedlichen Handlungen führen. Das «Warum hat der Agent so entschieden» lässt sich oft nur über die protokollierten Zwischenschritte (Reasoning-Trace) reproduzieren, allerdings weder zuverlässig noch präzise.

3. Drittanbieter-Tools sind Blackboxes. Sobald ein Agent eine externe API oder ein SaaS-Tool aufruft, endet die eigene Sichtbarkeit an der Systemgrenze.

Nachvollziehbarkeit ist somit möglich, allerdings nur mit expliziten Kontrollpunkten entlang der gesamten Kette (delegation chain). Fakt ist, ohne eine saubere Architektur wird der Einsatz von KI-Agenten schnell zur forensischen Schnitzeljagd, die teuer werden kann.

Gerade weil Agentic AI eigenständig Entscheidungen treffen, Tools nutzen und mit Umsystemen interagieren dann, braucht es Entscheidungs- und Aktionsprovenienz: Jede relevante Aktion muss technisch, organisatorisch und fachlich rückverfolgbar sein. Das passt auch zum Zero-Trust-Gedanken, bei dem jeder Zugriff geprüft wird, sowie zu AI-Governance- und TRiSM-Ansätzen, die Monitoring, Nachvollziehbarkeit, Daten- und Risikokontrolle verlangen.

Während die geschilderten Faktoren 2-4 auf die Prävention einzahlen, leistet der Faktor Accountability jene Sichtbarkeit, ohne die Least Privilege, Context und Continuous Verification blind blieben. Eine präventive Wirkung der Accountability entsteht, sobald selbige mit Echtzeit-Auswertung gekoppelt ist. Damit verwandelt sich die reine Dokumentation in einen Auslöser für automatische Gegenmassnahmen.

Hier kommt SIEM/XDR ins Spiel — als Bindeglied, welches die detektivische Accountability in eine reaktive, teils präventive Kontrolle verwandelt und Agentenaktionen ins SOC-Sichtfeld rückt. Nicht als exotische KI-Logs in irgendeinem Nebenraum, sondern inegriert in: SIEM, SOAR, XDR, IAM, DLP, ERP Audit Logs, API Gateway Logs, CASB/SASE-Kontext. SIEM (Log-Korrelation) und XDR (systemübergreifende Detektion und Response) sind die Ebenen, die aus einzelnen Audit-Spuren ein zusammenhängendes Bild flechten und daraus Aktionen ableiten.

Konkret sind das folgende vier Aktionsprameter:

A) Korrelation über Systemgrenzen hinweg
Ein einzelner Agentenzugriff auf System A sieht harmlos aus. Erst wenn SIEM erkennt, dass derselbe Agent innerhalb von 90 Sekunden auf System A, dann B, dann C zugreift, das heisst, Systeme, die fachlich nichts miteinander zu tun haben, entsteht ein Muster «laterale Bewegung». Diese Korrelation ist genau das, was die Delegationskette und die einzelnen Agent-Logs erst auswertbar macht.

B) Verhaltens-Baselining für Agenten
XDR lernt das normale Verhalten eines Agenten: Welche Systeme spricht ein spezifischer Agent üblicherweise an? In welcher Frequenz? Zu welchen Zeiten? Weicht das Verhalten ab (wie beispielsweise der Zugriff auf ein Finanzsystem, welches nie im normalen Profil vorkam), schlägt das System an. Hierbei handelt es sich um eine Anomalie-Erkennung, angewandt auf Non-Human Identities.

C) Automatische Response als präventiver Hebel
Hier findet die Verwandlung statt, weg von etwas, das erkannt wurde hin zu etwas, das verhindert wird. Definierte Playbooks können so beispielsweise bei erkannter lateraler Bewegung sofort greifen:

• Token des Agenten sofort invalidieren
• Agent-Session isolieren / in Quarantäne setzen
• Betroffene Systeme temporär für diese Agent-ID sperren
• Menschliche Eskalation auslösen

Der entscheidende Punkt: Diese automatisierte Response passiert in Sekunden, das heisst während der Vorfall läuft, nicht Stunden später bei der Log-Auswertung. Damit wird jede weitere laterale Bewegung verhindert, auch wenn die erste bereits stattgefunden hat. Die Ausbreitung wird verhindert und der Blast Radius damit wirkungsvoll eingedämmt.

D) Wirkung auf Least Privilege, Context und Continuous Verification
SIEM/XDR-Erkenntnisse fliessen zurück in die Policy Engine: Ein Agent, der auffällig wurde, kann automatisch strengeren Continuous-Verification-Regeln unterworfen oder in seinen Berechtigungen (Least Privilege) heruntergestuft werden. Das schliesst den Kreis zwischen detektiver und präventiver Kontrolle.

Für die Architektur heisst das konkret: Accountability-Logs sind wertlos, wenn sie nur in ein Archiv geschrieben werden, das niemand in Echtzeit auswertet. Der Wert entsteht erst in der Kopplung. Die Audit-Spuren der Agenten müssen nativ und strukturiert in die SIEM/XDR-Pipeline fliessen, mit Agent-ID, Delegationskette und Kontext als korrelierende Felder. Erst dann wird aus «Wir wissen hinterher, wer es war.» ein «Wir stoppen es, während es passiert.»

Was das für Sie inder Rolle als CISO konkret bedeutet
Das Least-Privilege-Prinzip bleibt richtig — aber es muss für KI-Agenten operationalisiert werden.
Drei Massnahmen mit sofortiger Wirkung:

1. Just-in-Time Access einführen: Berechtigungen werden on-demand für einen definierten Zeitraum und Scope ausgestellt und danach automatisch entzogen.
2. Agent Identity Registry aufbauen: Jeder KI-Agent erhält eine eigene, eindeutige Identität im Verzeichnisdienst — mit definierten Berechtigungen, Owner und Review-Zyklus.
3. Berechtigungs-Audits für Agenten als regulären Prozess etablieren: Nicht jährlich, sondern bei jeder Änderung des Aufgabenprofils eines Agenten.

Grundsätzlich sollte das Ziel nicht darin bestehen, die Berechtigungen für KI-Agenten einzuschränken, sondern die kleinstmögliche Angriffsfläche bei maximaler Funktionsfähigkeit sicherzustellen. Ist das eine Frage der Sicherheitsphilosophie? Nein. Es ist eine Frage der Systemarchitektur. So lautet die zentrale Leitfrage lautet nicht mehr: „Welche Berechtigungen braucht ein KI-Agent?“, sondern: „Welchen Vertrauensgrad erhält dieser Agent für welcheAufgabe unter welchen Bedingungen?“

Daraus ergibt sich ein modernes Berechtigungsmodell mit fünf Kernprinzipien, die in folgender Formel als struktureller Wegweiser zusammengefasst werden können:
Identity × Least Privilege × Context × Continuous Verification × Accountability = kontrollierte Handlungsfähigkeit von KI-Agenten
Die multiplikative Logik zwischen dem Bogen aus «Wer → Was → Warum → Noch gültig? → Wer haftet» verdeutlicht, dass ein einziger vernachlässigter Faktor die gesamte Sicherheit auf Null setzt. Ein KI-Agent kann perfekt identifiziert, minimal berechtigt, kontextsensibel und lückenlos verifiziert sein. Wenn im Schadensfall keine Verantwortlichkeit zugeordnet werden kann (Accountability = 0), ist das ganze Modell seitens Governance wertlos.

Die Kernprinzipien zusammengefasst:

1. Identity first: Jeder Agent besitzt eine eindeutige Identität.
2. Least Privilege: Minimale, aufgabenbezogene Rechte statt pauschaler Zugriffe. 
3. Context: Berechtigungen ändern sich abhängig von Situation, Risiko und Zweck.
4. Continuous Verification: Das ist der Zero Trust Anker, das heisst, jede Aktion wird fortlaufend geprüft und autorisiert.
5. Full Accountability: Jede Entscheidung und jede Aktion eines Agenten ist nachvollziehbar und einer verantwortlichen Stelle zugeordnet.

Dieses Modell folgt dem Zero-Trust-Sicherheitsansatz und lässt sich gut mit aktuellen Konzepten wie Agent Identity, AI Governance und AI TRiSM (AI Trust, Risk and Security Management) verbinden, die sich zunehmend als Referenz für den sicheren Einsatz agentischer KI etablieren.

Folgende Best Practices dienen als Handlauf beim IAM für für KI-Agenten:

• Human-in-the-Loop (HITL): Kritische Aktionen (z. B. das Versenden von Angeboten oder Vertragsänderungen) sollten vor der Ausführung von menschlichen Mitarbeitenden genehmigt werden.
• Einsatz von AI-Gateways: Nutzen Sie standardisierte Schnittstellen und Gateways (z. B. AI-Gateways), um die Zugriffe der KI zu überwachen und zu protokollieren.