KI-Agenten werden wertvoll in dem Moment, in dem sie aufhören, sich wie passive Assistenten zu verhalten und anfangen, mit realen Systemen zu interagieren. Dieser Wandel von Ausgaben zu Aktionen führt jedoch zu einem Governance-Dilemma, bei dem dieselbe Autonomie und Anpassungsfähigkeit, die die Effizienz steigern, auch beispiellose Sicherheitsrisiken schaffen.

An diesem Punkt wird die Zugriffskontrolle zu einer zentralen Designentscheidung. Traditionelle Berechtigungsmodelle wurden für Benutzer und feste Anwendungen entwickelt. Sie sind wesentlich unzuverlässiger, wenn ein Agent Abruf, Argumentation und Aktion über mehrere Systeme hinweg in einem einzigen Workflow kombinieren kann.

Für Gründer und CTOs ist die zentrale Frage, wie viel Autorität ein Agent in der Produktion haben sollte. Was kann er sehen, welche Tools kann er nutzen, welche Aktionen kann er ausführen, und wann benötigt er menschliche Genehmigung? Diese Grenzen bestimmen, ob ein Agent sich wie ein kontrolliertes System oder eine überprivilegierte Schwachstelle verhält.

Was Zugriffskontrolle für KI-Agenten tatsächlich bedeutet

Im Kontext agentischer Systeme ist die Zugriffskontrolle der umfassende Rahmen, der festlegt, worauf ein Agent zugreifen kann, welche Systeme er nutzen kann und welche Operationen er unter bestimmten Laufzeitbedingungen genau ausführen darf. Es ist eine Disziplin, die weit über einfache Benutzeranmeldungen oder statische API-Berechtigungen hinausgeht. Sobald Agenten Tools aufrufen und Workflows vorantreiben können, wird die Zugriffskontrolle zu einer Frage der Autorität. 

Nationales Kompetenzzentrum für Cybersicherheit des NIST (NCCoE) formuliert diese Herausforderung explizit als Notwendigkeit, sowohl den Zugriff als auch die von KI-Agenten durchgeführten Aktionen zu identifizieren, zu verwalten und zu autorisieren. Dies erfordert eine klare Unterscheidung zwischen der Identität des Agenten und der menschlichen Identität, in deren Namen er möglicherweise handelt. 

In der Praxis setzt eine effektive Zugriffskontrolle für Agenten Grenzen in vier Bereichen:

• Ressourcensichtbarkeit: Welche Daten der Agent abrufen kann.
• Tool-Funktionalität: Welche Tools und Funktionen er nutzen kann
• Entscheidungsrechte: Welche Entscheidungen oder Aktionen er ohne menschliche Genehmigung abschließen kann
• Prüfbarkeit: Wie seine Aktionen protokolliert und anschließend überprüft werden

Das ist der Unterschied zwischen einem Agenten Zugriff zu gewähren und ihm eine kontrollierte Autorität zu verleihen.

Bei Codebridge, die Praxis für KI-Agenten konzentriert sich auf die Einbettung dieser Grenzen in reale Systeme, von Identität und Tools bis hin zu Laufzeitrichtlinien und Audit.

Warum Agentensysteme die Grenzen traditioneller Berechtigungen aufzeigen

Die meisten Unternehmen setzen bereits auf Modelle wie RBAC und ABAC um den Zugriff über Benutzer, Anwendungen und Dienste hinweg zu verwalten. Diese Modelle sind auch in Agentensystemen weiterhin relevant. Das Problem ist, dass sie oft zu grob implementiert sind für Software, die Daten abrufen und mehrstufige Aktionen über Systeme hinweg mit begrenzter menschlicher Aufsicht ausführen kann.

KI-Agenten machen traditionelle Zugriffsmodelle nicht irrelevant. Sie zeigen auf, wo diese Modelle für sich genommen unvollständig werden. Eine Rolle kann eine breite Verantwortung definieren. Ein Attribut kann den Zugriff nach Kontext einschränken. Aber beides ist nicht ausreichend, wenn das System die delegierte Autorität nicht klar kontrollieren, die Werkzeugnutzung einschränken, den Lesezugriff von den Aktionsrechten trennen oder Genehmigungen zum Zeitpunkt der Ausführung durchsetzen kann.

Deshalb ist die Kernfrage nicht, ob RBAC oder ABAC noch anwendbar sind. Es geht darum, ob die umgebende Berechtigungsarchitektur detailliert genug für das Agentenverhalten in der Produktion ist.

Praktische Kontrollmodelle: Den richtigen Ansatz wählen

Kein einzelnes Zugriffsmodell ist ausreichend für die Agentensteuerung in der Produktion. Die eigentliche Designfrage ist, welches Framework der tatsächlichen Arbeitsweise des Agenten entspricht. Manche Agenten haben stabile Verantwortlichkeiten. Andere benötigen Berechtigungen, die sich je nach Datensatz, Workflow-Phase, Mandant oder Beziehung ändern.

Wenn wir KI-Agenten mit Codebridge entwickeln, kombinieren wir RBAC, ABAC, PBAC und ReBAC auf eine Weise, die den tatsächlichen Verantwortlichkeiten, Datenbereichen und dem Risikoprofil des Agenten entspricht.

RBAC für stabile, rollenbasierte Agenten

Rollenbasierte Zugriffskontrolle (RBAC) funktioniert weiterhin, wenn der Agent eine klare, dauerhafte Rolle hat. Wenn ein interner Berichtsagent oder Support-Assistent eine begrenzte Anzahl von Aufgaben ausführt, sind rollenbasierte Berechtigungen oft der einfachste Weg, den Umfang verständlich zu halten. Die Schwäche zeigt sich, wenn die Rolle für die Aufgabe zu breit gefasst ist. Ein Agent mag im Allgemeinen die richtige Rolle haben, sollte aber dennoch nicht in der Lage sein, jeden Datensatz abzurufen, jedes Tool aufzurufen oder jede Aktion innerhalb dieser Rolle auszuführen.

ABAC für kontextsensitive Entscheidungen

Attributbasierte Zugriffskontrolle (ABAC) wird nützlicher, wenn der Zugriff vom Kontext abhängt. Es ermöglicht Teams, Berechtigungen anhand von Bedingungen wie Benutzer, Datensatztyp, Geografie, Workflow-Phase oder Datenvertraulichkeit zu definieren. Das macht es zu einer besseren Lösung für Agenten, die in regulierten oder mehrstufigen Workflows arbeiten. Ein Agent darf einen Datensatz während der Überprüfung für einen bestimmten Benutzer in einer bestimmten Region zusammenfassen, ihn aber nicht exportieren oder ändern.

PBAC für die zentrale Durchsetzung von Richtlinien

Richtlinienbasierte Zugriffskontrolle (PBAC) ist wichtig, wenn diese Regeln zentral durchgesetzt und aktualisiert werden müssen, ohne die Anwendungslogik neu schreiben zu müssen. Dies ist oft die praktische Lösung, wenn Teams Richtlinien zur Laufzeit basierend auf Risiko, Umgebung oder Genehmigungsstatus ändern müssen. In Agentensystemen ist diese Flexibilität entscheidend, da Zugriffsentscheidungen oft von mehr als nur der Identität abhängen.

ReBAC für datensatz- und beziehungsgesteuerte Systeme

Die beziehungsbasierte Zugriffskontrolle (ReBAC) definiert Berechtigungen basierend auf dem Beziehungsgeflecht zwischen Subjekten und Ressourcen. Dies ist unerlässlich für B2B-SaaS und regulierte Workflows, bei denen die Autorisierung von spezifischen Zuordnungen abhängt: „Dieser Agent kann auf diese Datei zugreifen, weil sie diesem spezifischen Vorgang zugeordnet ist.“ 

Googles Zanzibar ist die bemerkenswerteste Implementierung dieses Modells in großem Maßstab. Obwohl ReBAC sehr flexibel ist, kann es aufgrund der Notwendigkeit mehrerer Beziehungsabfragen pro Anfrage zu Performance-Overhead führen.

Der wichtige Punkt ist, dass diese Modelle sich nicht gegenseitig ausschließen. Die meisten Agentensysteme in der Produktion benötigen eine Kombination. RBAC kann umfassende Verantwortlichkeiten definieren. ABAC kann den Umfang kontextabhängig eingrenzen. PBAC kann Richtlinien zentralisieren und durchsetzen. ReBAC kann den Zugriff auf Datensatz- und Beziehungsebene handhaben. 

Das richtige Modell ist Teil eines Kontroll-Stacks, der dem tatsächlichen Verhalten des Agenten entspricht.

Der Boundary Stack: Ein Architektur-Framework

RBAC, ABAC, PBAC und ReBAC helfen bei der Modellierung des Zugriffs, steuern aber nicht von sich aus das Agentenverhalten in der Produktion über Identität, Delegation, Tools, Aktionen, Genehmigungen und Auditierbarkeit hinweg.

In der Praxis ist die Kontrolle von Agenten auf Produktionsebene eine Kette von Grenzen, die festlegen, was der Agent tun darf, unter wessen Autorität, in welchen Systemen und mit welchen Nachweisen danach. Das Zugriffsmodell liefert die Logik. Der Boundary Stack wandelt diese Logik in eine operative Kontrollschicht um.

Ein praktischer Boundary Stack für KI-Agenten sollte acht Schichten umfassen:

1. Agenten-Identitätsgrenze

Jeder Produktionsagent muss eine eigene, eindeutige Identität besitzen. Ohne diese können Teams später keine zuverlässige Verantwortung zuweisen oder Missbrauch untersuchen. Wenn das System nicht klar erkennen kann, welcher Agent gehandelt hat, wird jede nachgelagerte Kontrolle schwächer.

2. Delegationsgrenze 

Das System muss definieren, ob der Agent als er selbst, im Auftrag eines Benutzers oder unter einer anderen delegierten Autorität handelt. Dies ist eine der wichtigsten Grenzen im Agentendesign. Agenten sollten niemals standardmäßig stillschweigend umfassende menschliche Zugriffsrechte erben.

3. Ressourcenzugriffsgrenze

Ein Agent sollte nur in der Lage sein, die Daten, Datensätze, Mandanten und Systeme abzurufen, die für die Aufgabe relevant sind. Hier ist eine feingranulare Autorisierung am wichtigsten. Ein breiter Zugriff auf der Datenebene verwandelt einen nützlichen Agenten schnell in einen übermäßig exponierten.

4. Tool-Grenze

Der Agent sollte nur die Tools und Funktionen aufrufen können, die er wirklich benötigt. Der Tool-Zugriff sollte so aggressiv wie möglich eingeschränkt werden. Zum Beispiel sollte ein Tool zum Lesen von E-Mails nicht die Möglichkeit haben, Nachrichten zu senden oder Einstellungen zu ändern.

5. Aktionsgrenze

Der Zugriff auf ein System ist nicht gleichbedeutend mit der Berechtigung, darin Aktionen auszuführen. Teams sollten die Rechte für Lesen, Zusammenfassen, Entwerfen, Empfehlen, Aktualisieren, Genehmigen, Löschen oder Ausführen trennen. Ein generischer „Systemzugriff“ ist für das Agentenverhalten in der Produktion zu grob.

6. Genehmigungsgrenze

Aktionen mit hoher Auswirkung, wie Finanztransaktionen oder Code-Deployments, sollten eine explizite Bestätigung durch einen Menschen erfordern.

7. Laufzeitrichtliniengrenze

Agentenberechtigungen sollten nicht statisch bleiben, wenn sich die Umgebungsbedingungen ändern. Die Autorisierung muss möglicherweise basierend auf dem Workflow-Status, dem Sensibilitätsgrad, der Umgebung, Anomaliesignalen oder der Quelle der Anweisung verschärft werden. 

8. Audit-Grenze

Jeder bedeutsame Zugriff oder jede Aktion sollte eine Spur hinterlassen, die zeigt, welcher Agent gehandelt hat, welche Berechtigung er genutzt hat, welche Ressource oder welches Tool er berührt hat, welche Richtlinie dies erlaubt hat und ob eine Genehmigung erforderlich war. Wenn diese Kette später nicht rekonstruiert werden kann, ist das System nicht wirklich steuerbar.

Zugriffssteuerung für KI-Agenten ist ein geschichtetes Kontrollsystem. RBAC, ABAC, PBAC und ReBAC helfen, die Berechtigungslogik zu gestalten, aber der Grenzschicht-Stack ist das, was diese Logik in operative Einschränkungen umwandelt.

Wo die Zugriffssteuerung für Agenten in realen Implementierungen versagt

Weitgehende delegierte Befugnisse 

Im März 2026, legte Meta einen SEV1-Sicherheitsvorfall offen nachdem ein interner KI-Agent fehlerhafte technische Anweisungen gegeben hatte, die zu einem unbefugten Zugriff von Mitarbeitern auf sensible Unternehmens- und Benutzerdaten für mehr als zwei Stunden führten. 

Meta erklärte, dass keine Benutzerdaten missbraucht wurden, aber der Vorfall ist ein deutliches Beispiel dafür, was passiert, wenn Agentenratschläge oder Aktionspfade zu nah an privilegierten Workflows operieren, ohne klare Berechtigungsgrenzen.

Fehlende Genehmigungsgrenzen 

In Australien, Deloitte hat einen Regierungsbericht teilweise zurückerstattet im Wert von etwa A$440.000 nachdem festgestellt wurde, dass das Dokument offenbar KI-generierte Fehler und gefälschte Rechtszitate enthielt. Das Problem war nicht nur die Modellgenauigkeit. Es lag daran, dass schwache Überprüfungs- und Genehmigungskontrollen eine Ausgabe mit geringer Zuverlässigkeit in ein vertrauenswürdiges Ergebnis gelangen ließen.

Unkontrollierte automatisierte Entscheidungsrechte

In den USA, erklärte sich iTutorGroup bereit, 365.000 US-Dollar zu zahlen, um eine EEOC-Klage beizulegen mit der Behauptung, dass ihre Einstellungssoftware ältere Bewerber automatisch ablehnte, wobei Frauen über 55 und Männer über 60 aussortiert wurden. Auch das ist ein Grenzversagen. Eine folgenreiche Entscheidung wurde effektiv an die Automatisierung delegiert, ohne ausreichende Kontrolle darüber, was das System entscheiden durfte.

Trotz unterschiedlicher Kontexte zeigen alle drei Fälle dasselbe Fehlermuster: Unklare Zuständigkeiten machten die Automatisierung zu einem Betriebsrisiko.

Checkliste für Führungskräfte: Ist Ihr Agent tatsächlich steuerbar?

Bevor ein Agent live geht, sollte die Führungsebene diese Fragen ohne Zögern beantworten können:

1. Hat jeder Produktionsagent eine eigene, eindeutige Identität?
2. Können wir erklären, ob der Agent eigenständig oder unter delegierter menschlicher Autorität handelt?
3. Sind seine Berechtigungen auf nur die für die Aufgabe benötigten Tools und Funktionen beschränkt?
4. Sind Lese-, Schreib-, Genehmigungs- und Ausführungsrechte klar getrennt?
5. Sind folgenreiche Aktionen wie Zahlungen, Löschungen oder Bereitstellungen blockiert, bis ein Mensch sie überprüft hat?
6. Kann die Autorisierung je nach Workflow-Phase, Datenvertraulichkeit oder Betriebskontext variieren?
7. Können wir sehen, welche Richtlinie oder Regel eine bestimmte Aktion zugelassen hat?
8. Können wir rekonstruieren, welcher Agent auf welches Tool, System oder welchen Datensatz zugegriffen hat?
9. Wurden ungenutzte Tools, Test-Plugins und überflüssige Berechtigungen aus der Produktion entfernt?
10. Würde dieses Design einer internen Prüfung oder einer Sicherheitsüberprüfung durch Kunden standhalten?

Wenn diese Antworten unklar sind oder auf Annahmen basieren, ist das System wahrscheinlich nicht produktionsreif. Steuerbare Agenten zeichnen sich dadurch aus, wie klar ihre Befugnisse begrenzt und erklärt werden können.

Fazit

Bei der Zugriffskontrolle für KI-Agenten geht es darum zu entscheiden, wo die Befugnisse eines Agenten beginnen und wo sie enden. Die sichersten und wertvollsten Agentensysteme sind nicht die mit der fortschrittlichsten Denkfähigkeit, sondern die mit klar definierten Identitäten, eng gefassten Berechtigungen, kontrollierten Aktionen und transparenten Genehmigungspfaden.