ABAC vs. RBAC für KI-Agenten-Zugriffskontrolle: Warum Rollen nicht ausreichen

Die meisten Zugriffssteuerungsarchitekturen in Unternehmen basieren auf Rollen. Ein Kliniker erhält Zugriff auf Patientendaten. Ein freigegebener Mitarbeiter erhält Zugriff auf CUI-Repositorys. Ein Finanzberater erhält Zugriff auf Kundenportfolios. Die Rolle wird bei der Bereitstellung zugewiesen, der Zugriff folgt der Rolle, und dieses Modell funktioniert recht gut für Menschen mit stabilen Aufgabenbereichen und geregelten Arbeitszeiten.

KI-Agents haben keine stabilen Aufgabenbereiche. Sie werden für bestimmte Aufgaben eingesetzt, arbeiten über variable Datenbereiche hinweg, agieren mit Maschinen-Geschwindigkeit und können gleichzeitig Dutzende paralleler Workflows ausführen. Eine „Klinische Dokumentations-Agent“-Rolle, die Zugriff auf das PHI-Repository gewährt, drückt nicht aus, dass genau diese Agenteninstanz berechtigt ist, auf drei bestimmte Behandlungsdatensätze eines bestimmten Patienten, für eine bestimmte Dokumentationsaufgabe, delegiert von einem bestimmten Kliniker, mit Ablauf am Ende der aktuellen Sitzung zuzugreifen. RBAC wurde für die erste Art von Zugriff entwickelt. ABAC ist für die zweite gemacht.

Dieser Beitrag erläutert die architektonischen Unterschiede zwischen den beiden Modellen, wo RBAC in agentischen Umgebungen an seine Grenzen stößt und warum attributbasierte Zugriffskontrolle das Modell ist, das tatsächlich die Anforderungen von HIPAA, CMMC und anderen regulatorischen Rahmenwerken für KI-Agenten-Datenzugriff erfüllt.

Executive Summary

Kernaussage: RBAC vergibt Zugriffsrechte basierend darauf, wer der Anwender ist. ABAC vergibt Zugriffsrechte basierend darauf, wer der Anwender ist, was er tun möchte, auf welche Daten er zugreift und in welchem Kontext der aktuelle Workflow stattfindet – alles wird bei jeder Anfrage gleichzeitig bewertet. Für menschliche Anwender mit stabilen Rollen reicht das einfachere RBAC-Modell oft aus. Für KI-Agents mit dynamischen Aufgabenbereichen im großen Maßstab kann RBAC den minimal notwendigen Zugriff auf Operationsebene nicht durchsetzen. ABAC kann das.

Warum das wichtig ist: Das Minimalprinzip von HIPAA, CMMC AC.2.006 und NIST 800-171 Practice 3.1.2 verlangen, dass der Zugriff auf das für die jeweilige autorisierte Aufgabe erforderliche Minimum beschränkt wird – nicht nur auf das, was die Rolle des Anwenders grundsätzlich erlaubt. Für einen KI-Agenten kann dies nur durch ein Richtlinienmodell erfüllt werden, das den Kontext zum Zeitpunkt jeder Anfrage bewertet. RBAC tut das nicht. Eine KI-Implementierung, die ausschließlich von RBAC gesteuert wird, kann diese Anforderungen strukturell nicht erfüllen – egal, wie gut die Rollen definiert sind.

wichtige Erkenntnisse

1. RBAC vergibt Zugriff basierend auf der Rolle; ABAC vergibt Zugriff basierend auf dem bewerteten Kontext. Der Unterschied liegt im Zeitpunkt der Zugriffsentscheidung. RBAC trifft sie bei der Bereitstellung. ABAC trifft sie bei jeder Anfrage – mit voller Transparenz darüber, wer anfragt, was angefragt wird, warum und unter welchen Umständen.
2. Minimal notwendiger Zugriff kann mit RBAC allein nicht auf Operationsebene durchgesetzt werden. Eine Rolle gewährt eine Zugriffskategorie. Sie kann nicht bewerten, ob diese spezifische Operation auf diesen spezifischen Datensatz im autorisierten Rahmen dieses Workflows liegt. Diese Bewertung erfordert Attribute – und ABAC ist das Modell, das sie nutzt.
3. KI-Agents machen die Grenzen von RBAC strukturell, nicht konfigurierbar. Bei menschlichen Anwendern kann man das Risiko überberechtigter Rollen durch disziplinierte Bereitstellung mindern. Bei KI-Agents, die mit hoher Geschwindigkeit über Tausende täglicher Interaktionen agieren, ist die Lücke zwischen rollenbasiertem Zugriff und aufgabenbasierter Autorisierung kein Richtlinienproblem – es ist ein systemisches Compliance-Risiko, das keine Rollenneugestaltung schließen kann.
4. ABAC und RBAC schließen sich nicht gegenseitig aus. Die effektivsten Zugriffskontrollarchitekturen für regulierte Umgebungen nutzen beide: RBAC, um die äußere Grenze dessen festzulegen, worauf ein Agententyp grundsätzlich zugreifen darf, und ABAC, um die spezifische Autorisierung für jede Operation innerhalb dieser Grenze durchzusetzen. RBAC setzt die Obergrenze; ABAC sorgt für die Durchsetzung auf der operativen Ebene.
5. ABAC macht die Delegationskette operativ nutzbar. Zu wissen, dass Agent A von Anwender B autorisiert wurde, Aufgabe C auszuführen, bringt nichts, wenn die Zugriffskontrollschicht diese Autorisierung nicht zum Zeitpunkt jeder Datenanfrage bewerten kann. ABAC ist die Richtlinien-Engine, die die Delegationskette liest und sie in Echtzeit auf jede Zugriffsentscheidung anwendet.

Wie RBAC funktioniert und wo es für KI-Agents versagt

Rollenbasierte Zugriffskontrolle weist Berechtigungen Rollen zu und Rollen anschließend Anwendern oder Systemen. Ein klinischer Dokumentationsagent kann beispielsweise die Rolle „PHI Read“ erhalten, die Lesezugriff auf das Patientendatensystem gewährt. Ein CUI-Verarbeitungsagent erhält die Rolle „CUI Repository Access“. Die Zuweisung erfolgt bei der Bereitstellung; der Zugriff folgt automatisch.

Für einen menschlichen Kliniker ist dieses Modell praktikabel. Die Rolle spiegelt die berufliche Funktion wider, der gewährte Zugriff passt im Großen und Ganzen zu dieser Funktion, und das professionelle Urteilsvermögen des Menschen steuert, worauf tatsächlich zugegriffen wird. Die Rolle ist ein vernünftiger Proxy für autorisierten Zugriff, weil menschliche Aufgabenbereiche stabil und relativ vorhersehbar sind.

Für einen KI-Agenten führt dasselbe Modell zu einem anderen Ergebnis. Die Rolle „PHI Read“ gewährt dem Agenten Lesezugriff auf alle Patientendaten, die die Rolle abdeckt – nicht nur auf die für die aktuelle Aufgabe relevanten Datensätze. Die Rolle „CUI Repository Access“ gewährt Zugriff auf das gesamte Repository – nicht nur auf die spezifischen Dokumente, die der aktuelle Workflow benötigt. Die Rolle ist eine grobe Annäherung an das, was der Agent tatsächlich in einem bestimmten Moment tun darf. Und weil Agents mit hoher Geschwindigkeit über viele parallele Workflows agieren, ist der kumulierte Überzugriff kein Randphänomen – sondern der Standardzustand der Implementierung.

Die drei Compliance-Lücken, die RBAC für KI-Agents schafft

Wie ABAC adressiert, was RBAC nicht kann

Attributbasierte Zugriffskontrolle trifft die Zugriffsentscheidung zum Zeitpunkt der Anfrage anhand einer Richtlinie, die mehrere Attribute gleichzeitig bewertet. Die Richtlinie ist keine statische Zuweisung – sie ist ein bedingter Ausdruck, der Antragsteller, Ressource, Aktion und Umgebung gemeinsam berücksichtigt, bevor Zugriff gewährt oder verweigert wird.

Für eine KI-Agenten-Datenanfrage könnte eine ABAC-Richtlinienbewertung so aussehen:

Eine Anfrage, die alle vier Attributbewertungen besteht, wird erlaubt. Scheitert eine Bewertung, wird die Anfrage verweigert – und die Ablehnung mit dem verursachenden Attribut protokolliert. Das ist die Zugriffseinschränkung auf Operationsebene, die das Minimalprinzip von HIPAA und CMMC AC.2.006 verlangen: Nicht „darf dieser Agententyp auf PHI zugreifen?“, sondern „darf diese spezifische Agenteninstanz, unter dieser spezifischen Autorisierung, diese spezifische Operation auf diesem spezifischen Datensatz genau jetzt ausführen?“

ABAC als Richtlinien-Engine für die Delegationskette

Hier verbinden sich ABAC und die authentifizierte Agentenidentität aus Post 11. Die Delegationskette legt die Autorisierung fest: Wer hat was an wen delegiert, mit welchem Umfang, unter welchen Bedingungen. ABAC ist der Durchsetzungsmechanismus, der diese Delegation liest und auf jede Datenanfrage in Echtzeit anwendet. Ohne ABAC ist die Delegationskette ein Protokoll – nützlich für Audits, aber nicht als Kontrolle wirksam. Mit ABAC wird die Delegationskette zur aktiven Richtlinie: Jede Anfrage des Agenten wird gegen die spezifischen Bedingungen der aktuellen Autorisierung geprüft, und jede Anfrage, die diese Bedingungen überschreitet, wird blockiert, bevor Zugriff erfolgt.

RBAC + ABAC: Die empfohlene Architektur

RBAC vollständig durch ABAC zu ersetzen ist weder notwendig noch ratsam. RBAC bietet eine klare, revisionssichere äußere Grenze: Der Agententyp „klinische Dokumentation“ darf niemals auf Finanzdaten zugreifen – unabhängig davon, was eine individuelle Agentenberechtigung sagt. Dieser kategorische Ausschluss lässt sich effizient als Rolle ausdrücken und durch RBAC durchsetzen. Was RBAC nicht leisten kann, ist die Durchsetzung der operationellen, kontextsensitiven, aufgabenspezifischen Einschränkung innerhalb dieser Grenze. Das ist die Aufgabe von ABAC.

Die kombinierte Architektur: RBAC definiert die äußere Zugriffsschranke für jeden Agententyp. ABAC erzwingt die spezifische Autorisierung für jede Operation innerhalb dieser Grenze, wobei die Delegationskette als maßgebliche Quelle für die aktuellen Workflow-Berechtigungen dient. Anfragen, die an RBAC scheitern, erreichen die ABAC-Bewertung nicht. Anfragen, die RBAC bestehen, werden dennoch gegen die vollständige ABAC-Richtlinie geprüft, bevor Zugriff gewährt wird. Keine Ebene allein reicht aus; gemeinsam bieten sie sowohl kategorische Zugriffsgovernance als auch Compliance-Durchsetzung auf Operationsebene.

Wie Kiteworks ABAC für KI-Agenten-Zugriffskontrolle implementiert

Das Private Data Network von Kiteworks erzwingt Zugriffskontrolle durch eine kombinierte RBAC/ABAC-Architektur, wobei die Data Policy Engine als ABAC-Bewertungsschicht für jede KI-Agenten-Datenanfrage dient.

Fordert ein Agent Zugriff auf regulierte Daten an, bewertet die Data Policy Engine gleichzeitig vier Attributkategorien: die authentifizierte Identität des Agenten und Delegationskettenattribute, die Klassifizierung und Sensitivität der angeforderten Daten, die spezifische angeforderte Operation sowie den aktuellen Workflow-Kontext einschließlich Zeit, Sitzungsstatus und Anomalie-Signalen. Zugriff wird nur gewährt, wenn alle vier Kategorien auf „erlauben“ stehen. Zugriff wird verweigert – und mit vollständiger Attribution protokolliert – wenn eine Kategorie auf „verweigern“ steht.

Diese Bewertung erfolgt auf der Datenebene, unabhängig vom Modell. Ein Modell-Update, das das Agentenverhalten verändert, eine Prompt-Injection, die die Anfragen des Agenten umleitet, oder ein falsch konfigurierter System-Prompt können die Richtlinienbewertung nicht umgehen. Die Data Policy Engine interpretiert keine Modellanweisungen; sie bewertet Zugriffsanfragen anhand der Richtlinie. Die Governance wird auf einer Ebene durchgesetzt, die das Modell nicht erreichen kann.

Das Ergebnis ist eine Zugriffskontrolle, die das Minimalprinzip von HIPAA auf Datensatzebene, CMMC AC.2.006 auf Operationsebene und die NIST 800-171 Practices 3.1.1 bis 3.1.3 für jede KI-Agenten-CUI-Interaktion erfüllt – mit einem vollständigen, manipulationssicheren Audit-Trail jeder Erlaubnis- und Ablehnungsentscheidung, der direkt ins SIEM des Unternehmens eingespeist wird.

Für regulierte Unternehmen, die Zugriffskontrolle auf Operationsebene für KI-Agents benötigen – nicht nur rollenbasiertes Zugriffsmanagement – bietet Kiteworks die Architektur, die dies möglich macht. 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 KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 beim Datenschutz Russisch Roulette spielen
• Blog Post
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blog Post
  Regulierungsbehörden wollen nicht mehr wissen, ob Sie eine KI-Richtlinie haben. Sie wollen den Beweis, dass sie funktioniert.