RBAC für KI-Agenten: rollenbasierte Zugriffskontrolle ohne Überrechte

Idee in 30 Sekunden

RBAC (Role-Based Access Control) für einen KI-Agenten definiert, wer welche Aktionen über Tools in Runtime ausführen darf.

Wann das nötig ist: wenn der Agent mit mehreren Rollen, mehreren Tenants arbeitet oder Zugriff auf write-Aktionen in realen Systemen hat.

Problem

Ohne RBAC wird ein Agent oft mit "breitem" Zugriff gestartet: eine Rolle, viele Tools, kaum Grenzen. Im Demo wirkt das bequem. In Production wird es schnell zur Incident-Quelle.

Ein einziger Planungsfehler des Agenten kann eine unnötige Aktion auslösen: falsches Tool, falscher Tenant, falsches Zugriffsniveau. Danach ist selbst eine Basisfrage schwer zu beantworten: wer genau bekam Zugriff und warum. Damit daraus kein Incident wird, muss die Zugriffsprüfung nicht im Prompt, sondern in der Policy-Layer vor jedem Tool-Aufruf stattfinden.

Analogie: das ist wie ein universeller Ausweis in einem Business-Center. Solange alles ruhig ist, sieht man keinen Unterschied. Im Störungsfall öffnet dieser Ausweis zu viele Türen.

Lösung

Die Lösung ist, Zugriffssteuerung in die Policy Layer der Runtime auszulagern. Jeder Tool-Aufruf wird anhand des user context (role, permissions und tenant scope) vor der Ausführung geprüft. Starte mit einer Basisregel: default deny und explizite Erlaubnisse nur für notwendige Rollen.

RBAC != nur allowlist

Allowlist definiert, welche Tools im System existieren.
RBAC definiert, wer sie wann aufrufen darf.

Eines ohne das andere funktioniert nicht:

ohne RBAC verschwimmen Zugriffsgrenzen zwischen Rollen
ohne allowlist wächst das Tool-Set unkontrolliert

Beispiel:

allowlist: Tool refund.create existiert und ist im System verfügbar
RBAC: nur Rolle billing_manager darf refund.create im eigenen Tenant aufrufen

Zugriffskontroll-Ebenen (RBAC layers)

Diese Prüfungen arbeiten bei jedem Agenten-Schritt zusammen.

Ebene	Was sie kontrolliert	Wichtige Mechaniken	Warum
Rollen (role mapping)	Wer die Aktion ausführt	role assignment service account policy	Verhindert "eine Rolle für alle"
Zugriffsrechte (permissions)	Was für die Rolle genau erlaubt ist	action-based permissions default deny allowlist	Schafft klare Grenzen für Tools und Aktionen
Tenant-Isolation (scope)	In welchem Datenraum gehandelt werden darf (Tenant ist ein isolierter Kundendatenraum)	tenant_id check resource scoping	Verhindert Zugriff auf fremde Tenants
Kontrolle von write-Aktionen	Riskante oder irreversible Aktionen	separate write permissions human approval	Reduziert das Risiko teurer Fehler

So sieht das in der Architektur aus

Die Policy Layer (Tool Gateway) steht zwischen Runtime und Tools und prüft jeden Aufruf. Jede Entscheidung (allow, deny, approval_required) wird im audit log festgehalten.

Flow: von Anfrage zu Entscheidung

Jeder Tool-Aufruf durchläuft diesen Flow vor Ausführung: Runtime führt keine Aktionen direkt aus, sondern delegiert die Entscheidung an die Policy-Layer.

Kurz zum Flow:

Runtime bildet eine Tool-Anfrage
RBAC Policy Layer prüft Rolle und tenant scope
allow -> Tool-Aufruf wird ausgeführt
deny -> stop reason + Eintrag im audit log
approval_required -> stop reason + Eintrag im audit log

Policy-Entscheidungen

Jeder Tool-Aufruf endet mit einer dieser Entscheidungen:

allow — Aktion wird ausgeführt
deny — Aktion ist verboten
approval_required — Bestätigung ist erforderlich

Das ist ein zentraler Punkt, durch den alle Entscheidungen vor Ausführung laufen. Diese Entscheidungen werden als Stoppgründe verwendet und im audit log protokolliert.

Beispiel

Ein Support-Agent (role = support_agent) erhält eine Rückerstattungsanfrage. Tool refund.create ist nur für Rolle billing_manager im eigenen Tenant erlaubt.

Ergebnis:

support_agent -> refund.create -> deny("permission_denied")
role mismatch oder tenant scope mismatch -> deny("permission_denied")
Event wurde mit Ablehnungsgrund im audit log gespeichert

RBAC stoppt den Fehler auf Ausführungsebene durch Zugriffsprüfung vor jeder Aktion.

Im Code sieht das so aus

PYTHON

decision = rbac.check(user_context, tool, tenant_id, args)
if not decision.allowed:
    audit.log(user_context, tool, tenant_id, decision.outcome, reason=decision.reason)
    return deny(decision.reason)

if decision.requires_approval and not approval.ok():
    audit.log(user_context, tool, tenant_id, "approval_required", reason="approval_required")
    return stop("approval_required")

result = tool.execute(args)
audit.log(user_context, tool, tenant_id, decision.outcome, reason=decision.reason, result=result)
return result

So sieht das während der Ausführung aus

TEXT

Szenario 1: Zugriff verboten (deny)

Anfrage: Nutzer bittet um refund
Runtime: Tool-Aufruf erstellt -> refund.create
Policy: Prüfung role + tenant scope + permissions
Decision: deny (permission_denied)
Audit: decision=deny, role=support_agent, action=refund.create, reason=permission_denied
Stop: Aktion nicht ausgeführt

---

Szenario 2: Zugriff erlaubt (allow)

Anfrage: derselbe Fall für billing_manager im eigenen Tenant
Runtime: Tool-Aufruf erstellt -> refund.create
Policy: Prüfung role + tenant scope + permissions
Decision: allow
Tool: refund.create ausgeführt
Audit: decision=allow, role=billing_manager, action=refund.create, result=ok
Return: Ergebnis an Client zurückgegeben

Typische Fehler

eine "service"-Rolle für alle Agenten und Nutzer
fehlende default-deny allowlist
Prüfung nur nach Rolle, ohne tenant scope
fehlende zentrale Policy Layer
gleiche Rechte für read und write Aktionen
RBAC-Logik nur in UI oder Prompt
fehlender audit trail: role, action, tenant, policy decision reason

Im Ergebnis wirkt das System kontrolliert, aber Zugriffsgrenzen verlieren mit der Zeit ihre Schärfe.

Selbst-Check

Schneller RBAC-Check vor Production-Start:

Es gibt eine explizite role -> allowed tools/actions Zuordnung
Die Access-Policy folgt dem Prinzip default deny
Jeder Tool-Aufruf geht durch eine zentrale Policy-Layer
Für jede Aktion wird tenant scope geprüft
Write-Aktionen haben separate Permissions und (wo nötig) approval
Jede Policy-Entscheidung hat einen expliziten stop reason oder outcome
Audit logs enthalten role, action, tenant und policy decision reason
Es gibt einen kill switch für den Not-Stopp im Incident

Fortschritt: 0/8

⚠ Grundlegende Governance-Kontrollen fehlen

Vor production brauchen Sie mindestens Zugriffskontrolle, Limits, audit logs und einen Not-Stopp.

FAQ

Q: Wie arbeiten wir mit tools, die GitHub, Jira oder andere externe APIs aufrufen?
A: Gib dem Agenten keinen gemeinsamen Schlüssel für alles. Nutze lieber user-scoped credentials, OAuth-Tokens oder separate service-account policy mit klaren Grenzen.

Q: Worin unterscheidet sich role von tenant scope?
A: Role definiert, was getan werden darf. Tenant scope definiert, wo es getan werden darf.

Q: Wie fügt man sicher ein neues Tool in RBAC ein?
A: Über ein explizites permission-Modell: default deny, getrennte read/write Rechte und tenant-scope Prüfung.

Q: Was zuerst einführen: RBAC oder approval?
A: Zuerst RBAC mit default deny und tenant scope. Danach approval für riskante write-Aktionen.

Q: Reicht RBAC allein für Production?
A: Nein. Zusätzlich braucht ihr execution limits, Budgets, audit logs und kill switch.

Wo RBAC im Gesamtsystem liegt

RBAC ist eine der Ebenen von Agent Governance.
Zusammen mit Budgets, Limits, approval und audit bildet es ein einheitliches System zur Ausführungskontrolle.