Agentenidentitätsauthentifizierung und Delegationskette

Jedes Compliance-Framework, das den Zugriff auf regulierte Daten regelt, stellt dieselbe grundlegende Frage: Wer hat dies autorisiert? Für menschliche Mitarbeitende ist die Antwort klar – authentifizierte Zugangsdaten, rollenbasierter Zugriff und ein Audit-Trail, der jedes Zugriffsereignis einer bestimmten Person zuordnet. Für KI-Agenten haben die meisten Unternehmen derzeit keine Antwort. Der Agent agiert über ein Servicekonto. Das Servicekonto authentifiziert sich am System. Und wenn der Auditor fragt, wer dem Agenten Zugriff auf diese Patientenakte, dieses CUI-Dokument oder dieses Kundenportfolio gewährt hat, lautet die ehrliche Antwort: Wir können es nicht sagen.

Dies ist keine theoretische Lücke. HIPAA §164.312(a)(2)(i) verlangt eine eindeutige Benutzeridentifikation für jede Person oder jedes Softwareprogramm, das auf ePHI zugreift. CMMC AU.2.042 fordert, dass die Aktivitäten von Prozessen, die im Namen autorisierter Anwender handeln, diesen Anwendern zuordenbar sind. Die SEC-Regel 204-2 verlangt, dass Beratungsaktivitäten autorisierten Personen zugeordnet werden können. Keine dieser Anforderungen macht eine Ausnahme für KI-Agenten – und keine wird durch ein Servicekonto erfüllt, das von fünf Agenten gemeinsam genutzt wird.

Dieser Beitrag erläutert, was eine authentifizierte Agentenidentität erfordert, wie die Delegationskette Agentenaktionen mit menschlicher Verantwortlichkeit verbindet und warum dies das grundlegende Governance-Element ist, auf dem jede andere Compliance-Kontrolle für KI-Agenten aufbaut.

Executive Summary

Kernaussage: Authentifizierte Agentenidentität bedeutet, dass jeder KI-Agent auf Workflow-Ebene über ein eindeutiges, überprüfbares Identitätszertifikat verfügt – getrennt von gemeinsam genutzten Servicekonten – und mit dem spezifischen Menschen verknüpft ist, der den Workflow autorisiert hat. Die Delegationskette ist der dokumentierte Nachweis dieser Verbindung: menschlicher Autorisierer zu Agentenidentität zu reguliertem Datenzugriffsereignis. Ohne diese Kette ist kein Audit-Trail vollständig, keine Zugriffskontrolle zuordenbar und keine Compliance-Strategie für KI-Agenten belastbar.

Warum das wichtig ist: Die Delegationskette ist keine reine Compliance-Formalität. Sie ist der Mechanismus, der jede andere KI-Governance-Kontrolle erst sinnvoll macht. Die ABAC-Richtlinie setzt voraus, dass bekannt ist, welcher Agent die Anfrage stellt. Manipulationssichere Audit-Logs benötigen eine eindeutige Zuordnung. Regulatorische Nachweispakete erfordern den Nachweis, wer was autorisiert hat. Eine KI-Implementierung ohne authentifizierte Agentenidentität und dokumentierte Delegationskette kann keine Compliance nachweisen – unabhängig davon, wie stark andere Kontrollen sind.

wichtige Erkenntnisse

1. Gemeinsam genutzte Servicekonten sind keine Agentenidentität. Ein Servicekonto authentifiziert ein System, nicht einen Agenten oder einen Workflow. Wenn mehrere Agenten dieselben Zugangsdaten nutzen, kann kein Zugriffsereignis im Log einem bestimmten Agenten, Workflow oder dem autorisierenden Menschen zugeordnet werden. Das ist kein unvollständiger Audit-Trail – sondern gar keiner.
2. Eindeutige Agentenidentität muss auf Workflow-Ebene, nicht auf Systemebene bereitgestellt werden. Die Authentifizierungseinheit ist die Workflow-Instanz: Dieser Agent, der diese Aufgabe ausführt, autorisiert von dieser Person, zu diesem Zeitpunkt. Servicekonten auf Systemebene bieten diese Granularität nicht. Identitätszertifikate auf Workflow-Ebene schon.
3. Die Delegationskette muss zum Zeitpunkt des Zugriffs erfasst werden, nicht nachträglich rekonstruiert. Wie Audit-Logs selbst können Delegationsketten nicht rückwirkend erstellt werden. Wenn das Authentifizierungsereignis den Agenten nicht im Moment der Ausstellung des Zertifikats und des Zugriffsereignisses mit dem menschlichen Autorisierer verknüpft, existiert diese Verbindung nie. Eine forensische Rekonstruktion ist später nicht möglich.
4. Menschliche Verantwortlichkeit endet nicht, wenn der Agent autonom handelt. Ein KI-Agent, der innerhalb eines Workflows autonom agiert, handelt weiterhin im Auftrag des Menschen, der den Workflow autorisiert hat. Die regulatorische Verantwortlichkeit folgt der Delegation, nicht der Ausführung. Der menschliche Autorisierer ist für das Handeln des Agenten im Rahmen der delegierten Aufgaben verantwortlich – deshalb muss die Delegationskette dokumentiert werden.
5. Agentenidentität ist Voraussetzung für jede weitere Compliance-Kontrolle. Die Bewertung von ABAC-Richtlinien erfordert eine bekannte Agentenidentität. Audit-Logging benötigt eine eindeutige Zuordnung. Zugriffsbegrenzung setzt einen definierten Principal voraus, dessen Berechtigungen eingeschränkt werden können. Ohne authentifizierte Agentenidentität funktionieren diese Kontrollen nicht wie vorgesehen.

Was eine authentifizierte Agentenidentität erfordert

Authentifizierte Agentenidentität ist nicht dasselbe wie Systemauthentifizierung. Ein Server, der sich mit einem Servicekonto an einer Datenbank anmeldet, beweist lediglich, dass der Server autorisiert ist. Es sagt nichts darüber aus, welcher Agent auf dem Server gerade agiert, unter welcher Workflow-Autorisierung oder im Auftrag welcher Person. Für die Compliance sind diese Unterschiede entscheidend.

Eindeutige Identität pro Workflow-Instanz

Compliance-Frameworks verlangen, dass Zugriffsereignisse einer bestimmten autorisierten Entität zugeordnet werden können. Bei KI-Agenten ist diese Entität die Workflow-Instanz: der spezifische Agent, der eine bestimmte Aufgabe unter einer bestimmten menschlichen Autorisierung ausführt. Das erfordert, dass Identitätszertifikate auf Workflow-Ebene bereitgestellt werden – nicht agentübergreifend geteilt, nicht sitzungsübergreifend wiederverwendet, nicht für verschiedene Agententypen gebündelt. Ein Zertifikat, das eindeutig „der Clinical-Documentation-Agent, der die Entlassungszusammenfassung für Patient Encounter #4471 bearbeitet, autorisiert von Dr. Chen um 9:14 Uhr am 15. März“ identifiziert, unterscheidet sich grundlegend von einem Zertifikat für „das Clinical-Documentation-Servicekonto“.

Die praktische Umsetzung ist ein Identitätstoken, das bei der Initialisierung des Workflows ausgestellt wird: Der menschliche Autorisierer authentifiziert sich, delegiert einen bestimmten Aufgabenbereich an den Agenten, und das resultierende Zertifikat verknüpft die Identität des Agenten mit der des Autorisierers für die Dauer des Workflows. Das Token trägt die Delegationskette in seinen Attributen – und jeder nachfolgende Datenzugriff des Agenten unter diesem Token wird automatisch sowohl dem Agenten als auch dem menschlichen Autorisierer zugeordnet.

Authentifizierung unabhängig vom Modell

Die Authentifizierung der Agentenidentität muss auf der Data-Governance-Ebene erfolgen, nicht im Modell selbst. Ein Modell, das „weiß“, dass es als Agent A agiert, speichert dieses Wissen als Prompt-Inhalt – der durch Injection überschrieben, durch Modell-Updates verändert oder bei Modell-Drift ignoriert werden kann. Die Authentifizierung auf der Datenebene, durch die Governance-Infrastruktur, die den Zugriff auf regulierte Daten steuert, kann nicht durch das Modellverhalten umgangen werden. Der Agent präsentiert Zugangsdaten, die Governance-Schicht prüft diese, und der Zugriff wird je nach Berechtigung gestattet oder verweigert. Das Wissen des Modells über seine eigene Identität ist dabei irrelevant.

Zertifikatsumfang auf den autorisierten Workflow beschränken

Das Identitätszertifikat muss den autorisierten Aufgabenbereich des Agenten kodieren – nicht nur, wer er ist, sondern auch, was er tun darf. Ein Zertifikat, das den Agenten identifiziert, aber weitreichenden Repository-Zugriff gewährt, erfüllt weder das HIPAA-Minimalprinzip noch die CMMC-Anforderung AC.2.006 zum minimal notwendigen Zugriff. Das Zertifikat sollte die autorisierten Datenkategorien, erlaubte Operationen und den Workflow-Kontext enthalten. Das ist die Brücke zwischen authentifizierter Identität und ABAC-Richtlinien: Die Identität legt fest, wer der Agent ist; die Umfangsattributen des Zertifikats legen fest, was er tun darf.

Die Delegationskette: Was sie ist und was sie enthalten muss

Die Delegationskette ist der dokumentierte Nachweis, der ein reguliertes Datenzugriffsereignis – ausgeführt von einem KI-Agenten – mit dem Menschen verbindet, der den zugrundeliegenden Workflow autorisiert hat. Sie ist keine einzelne Aufzeichnung, sondern eine verknüpfte Abfolge: Menschlicher Autorisierer autorisiert Workflow, Workflow stellt Agentenzertifikat aus, Agentenzertifikat regelt Datenzugriff, Datenzugriff erzeugt Audit-Log-Eintrag, Audit-Log-Eintrag verweist auf Agentenidentität und ursprüngliche Autorisierung. Jeder Link dieser Kette muss vorhanden und manipulationssicher sein, damit die Kette regulatorischen Anforderungen genügt.

Was jeder Link enthalten muss

Die Kette ist nur so stark wie ihr schwächstes Glied. Ein Autorisierungsereignis, das den delegierten Umfang nicht dokumentiert. Ein Agentenzertifikat, das keine Verbindung zum autorisierenden Menschen herstellt. Ein Datenzugriffs-Log, das die Operation, aber nicht die Agentenidentität aufzeichnet. Jede Lücke unterbricht die Kette – und eine unterbrochene Kette kann nicht als Nachweis autorisierten Zugriffs vorgelegt werden.

Warum die Kette im Log erhalten bleiben muss – und nicht daraus rekonstruiert werden kann

Ein häufiger Irrtum ist, dass sich Delegationsketteninformationen nachträglich aus bestehenden Logs ableiten lassen – durch Abgleich von Zeitstempeln, Verknüpfung von Servicekonto-Aktivitäten mit Kalenderdaten, Abgleich von API-Aufrufen mit Workflow-IDs. Dieser Prozess liefert keine Delegationskette, sondern nur eine Hypothese über mögliche Abläufe. Regulatoren verlangen Beweise, keine Hypothesen. Die Delegationskette muss als Teil der Architektur in jedem Zugriffs-Logeintrag enthalten sein – nicht nachträglich aus Indizien rekonstruiert werden.

Wie Kiteworks authentifizierte Agentenidentität und Delegationsketten-Erhalt umsetzt

Das Private Data Network von Kiteworks implementiert authentifizierte Agentenidentität und den Erhalt der Delegationskette als grundlegende Architektur – als ersten der vier Governance-Checkpoints, die jede KI-Agenteninteraktion mit regulierten Daten vor dem Zugriff durchläuft.

Ausstellung von Workflow-spezifischen Zertifikaten

Wenn ein menschlicher Autorisierer über Kiteworks einen Workflow an einen KI-Agenten delegiert, stellt die Plattform ein eindeutiges Identitätszertifikat für diese Workflow-Instanz aus. Das Zertifikat ist an den spezifischen menschlichen Autorisierer gebunden, kodiert den autorisierten Datenumfang und die erlaubten Operationen, enthält ein Ablaufdatum entsprechend der Workflow-Dauer und kann nicht für andere Workflows oder Agenten wiederverwendet werden. Keine zwei Workflow-Instanzen teilen sich ein Zertifikat – so kann jedes Zugriffsereignis eindeutig einem Workflow, einem Agenten und einem menschlichen Autorisierer zugeordnet werden.

Delegationskette in jedem Audit-Log-Eintrag

Jedes über Kiteworks abgewickelte Datenzugriffsereignis erzeugt einen Audit-Log-Eintrag, der die vollständige Delegationskette enthält: die authentifizierte Identität des menschlichen Autors, das workflow-spezifische Agentenzertifikat, die abgerufenen Daten, die ausgeführte Operation, das Ergebnis der Richtlinienbewertung und einen manipulationssicheren Zeitstempel. Dieser Eintrag wird zum Zeitpunkt des Zugriffs erstellt – nicht nachträglich rekonstruierbar. Er fließt direkt in das SIEM des Unternehmens ein und erfüllt gleichzeitig die Anforderungen von HIPAA §164.312(a)(2)(i), CMMC AU.2.042 und SEC Rule 204-2 für jede KI-Agenten-Interaktion mit regulierten Daten.

Integration mit ABAC-Richtlinienbewertung

Die authentifizierte Agentenidentität und die Delegationskette erfüllen nicht nur Audit-Anforderungen – sie ermöglichen es der Data Policy Engine, jede Zugriffsanfrage präzise zu bewerten. Die Richtlinienbewertung fragt nicht: „Darf dieser Agententyp auf diese Datenkategorie zugreifen?“, sondern: „Darf diese spezifische Agenteninstanz, autorisiert von diesem Menschen, diese konkrete Operation an diesem Datensatz zu diesem Zeitpunkt ausführen?“ Diese Granularität ist nur durch Identität und Delegationskette möglich. Ohne sie verkommt die Richtlinienbewertung zu Sitzungs- oder Agententyp-Ebene – was weder dem HIPAA-Minimalprinzip, noch CMMC AC.2.006 oder NIST 800-171 Praktiken 3.1.1 und 3.1.2 genügt.

Authentifizierte Agentenidentität und der Erhalt der Delegationskette sind keine Features einer konformen KI-Implementierung – sie sind das Fundament, auf dem jede andere Compliance-Kontrolle aufbaut. Erfahren Sie mehr über Kiteworks Compliant AI oder vereinbaren Sie eine Demo.

Weitere Ressourcen

• Blog Post
  Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz
• Blog Post
  Wie 77 % der Unternehmen bei der KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blog Post
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blog Post
  Regulierungsbehörden wollen keinen KI-Policy-Nachweis mehr – sie verlangen Belege für die Wirksamkeit.