TBAC: Aufgabenbasierte Zugriffskontrolle für das Zeitalter der Agenten

Die meisten produktiven Zugriffskontrollmodelle basieren nach wie vor auf einem stabilen Akteur: Wer fragt an, welche Attribute oder Beziehungen sind damit verknüpft und wozu berechtigen diese? Rollen beantworteten dies für das Organigramm, Attribute für den Kontext, Beziehungen für soziale Netzwerke. KI-Agenten stellen diese Grundannahme infrage – die Identität eines Agenten ist zwar stabil, seine Arbeit jedoch nicht: Er wird pro Aufgabe bereitgestellt, benötigt für jede Aufgabe einen anderen Berechtigungsausschnitt, arbeitet in Maschinengeschwindigkeit und folgt Anweisungen, die in den gelesenen Daten eingebettet sind. Die Frage, die das aktuelle Modell stellen muss, lautet: Welche Arbeit führst du gerade aus? Diese Frage hat eine lange Tradition – die aufgabenbasierte Zugriffskontrolle (Task-Based Access Control, TBAC), die in den 1990er Jahren von Thomas und Sandhu vorgeschlagen und nun in angepasster Form für agentische KI wiederbelebt wurde. Dieser Beitrag beleuchtet die Familie der Zugriffskontrollmodelle, erklärt, warum Agenten jedes dieser Modelle an seine Grenzen bringen, stellt TBAC in seinen modernen Ausprägungen vor und überträgt das geschichtete Ergebnis auf die Gateway-Konstrukte, die es implementieren, wobei die TrueFoundry-Abbildung auf öffentlicher Dokumentation basiert.

Ines, eine Sicherheitsarchitektin, erhielt die Prüfungsanfrage, die jedes Sicherheitsteam dieses Jahr bekommt: Genehmige einen Support-Agenten, der Tickets liest, die Bestelldatenbank abfragt und Rückerstattungen unter fünfzig Dollar ausstellt. Ihr Instinkt basierte auf zwanzig Jahren Berufserfahrung: Erstelle eine Rolle. Aber Support-Agent als Rolle fühlte sich bis zum Mittagessen falsch an. Eine Rolle wird einmalig zugewiesen und beschreibt eine stabile Tätigkeit; dieser Agent benötigte die Rückerstattungsberechtigung nur während der Rückerstattungsaufgaben, Zugriff auf die Datenbank nur für den Kunden des jeweiligen Tickets und dazwischen gar nichts. Schlimmer noch: Er würde alle gewährten Rechte dauerhaft behalten, über jede parallele Instanz hinweg und in Maschinengeschwindigkeit – und wenn ein bösartiges Ticket ihn dazu verleiten würde, etwas Kreatives mit seinen Berechtigungen anzustellen, könnte er dem folgen. Das Rollenmodell ließ ihr zwei schlechte Optionen: Überprivilegierung und damit ein ständiges Risiko in Kauf nehmen oder Unterprivilegierung und den Agenten funktionsunfähig machen. Sie wollte eine dritte Lösung: Berechtigungen, die pro Aufgabe zusammengestellt, auf die Objekte der Aufgabe begrenzt, für deren Dauer aktiv und nach Abschluss wieder gelöscht werden. Diese dritte Lösung existiert auf dem Papier bereits, seit bevor sie ihre Karriere begann.

1. Eine kurze, ehrliche Geschichte der BACs

Jede Generation der Zugriffskontrolle kodiert eine Annahme über den Akteur. Die früheste Trennung – diskretionäre Kontrolle (DAC), bei der Ressourcenbesitzer den Zugriff gewähren, gegenüber obligatorischer Kontrolle (MAC), bei der eine zentrale Instanz Kennzeichnungen und Freigaben verwaltet – setzte Personen mit Sicherheitsfreigaben voraus. RBAC, das in den 1990er Jahren von Ferraiolo, Kuhn und Sandhu formalisiert und später standardisiert wurde, band Berechtigungen an Rollen statt an Individuen: Eine Entwicklerrolle erhält Zugriff auf Repositories, eine Klinikrolle auf Patientenakten. Die grundlegende Annahme: Akteure haben stabile Arbeitsfunktionen die sich auf organisatorischer Ebene ändern – das gilt für Mitarbeiter und ist der Grund, warum RBAC in den meisten Unternehmen nach wie vor der Standard ist.

ABAC – die attributbasierte Zugriffskontrolle, kanonisch behandelt in NIST SP 800-162 – ersetzte die Rollenabfrage durch eine Richtlinienbewertung basierend auf Attributen von Subjekt, Ressource, Aktion und Umgebung: Erlaube, wenn Abteilung = Finanzen und Klassifizierung ≤ intern und während der Geschäftszeiten. Es erkauft sich Flexibilität auf Kosten der Komplexität bei der Richtlinienerstellung, und wie Sicherheitsanalysen für Agenten feststellen, bewertet es den Kontext zwar gut, versteht aber von Natur aus nicht die Absicht hinter einer Anfrage. ReBAC – beziehungsbasierte Zugriffskontrolle, bekannt geworden durch Googles Zanzibar-Paper – leitet Berechtigungen aus Graph-Beziehungen ab: Sie können dieses Dokument bearbeiten, weil Sie Eigentümer des übergeordneten Ordners sind. Daneben existieren PBAC als Oberbegriff für Policy-Engine-Ansätze sowie Just-in-Time-Zugriff aus dem Bereich Privileged Access Management – eine Vorschau aus der Welt der Menschen auf zeitlich begrenzte Berechtigungen. Jedes dieser Modelle beantwortet die Frage: „Wer bist du und wozu berechtigt dich das?“ – und zwar bevor die Arbeit beginnt. Genau diese Annahme verletzen Agenten.

2. Warum Agenten identitätszentrierte Zugriffskontrolle aushebeln

Die Belastung ist struktureller Natur, und die Fachliteratur zur Agentensicherheit ist sich in der Diagnose einig. Erstens: Agenten haben keine feste Stellenbeschreibung: Sie werden für spezifische Aufgaben eingesetzt, operieren über variable Datenbereiche hinweg, agieren mit Maschinengeschwindigkeit und führen parallele Instanzen aus – eine Rolle als „Agent für klinische Dokumentation“, die Zugriff auf ein PHI-Repository gewährt, kann nicht ausdrücken, dass diese Instanz autorisiert ist für diese drei Datensätze für diesen Behandlungskontakt, wie es eine ABAC-versus-RBAC-Analyse formuliert. Zweitens: Agenten können ihre Berechtigungen voll ausschöpfen, programmatisch und in großem Maßstab – Osos Formulierung trifft es am besten: Mitarbeiter ignorieren den Großteil ihrer Berechtigungen; Agenten tun das nicht. Eine Überprivilegierung, die bei Menschen nur unordentlich ist, wird für einen Akteur, der seinen Berechtigungsraum mit Maschinengeschwindigkeit erkunden kann, zu einer aktiven Angriffsfläche. Drittens: Agenten lassen sich zu Dingen überreden: Prompt-Injection bedeutet, dass Anweisungen über die Daten gelangen, die ein Agent liest. Eine dauerhafte Berechtigung ist somit ein dauerhaftes Ziel – das Problem des „Confused Deputy“ mit einer Sprachschnittstelle.

Viertens, und das wird am wenigsten beachtet: Delegationsketten verwischen die Verantwortlichkeit. „On-behalf-of“-Abläufe eskalieren stillschweigend – der Agent erbt den vollständigen Sitzungsumfang des Benutzers, einschließlich Berechtigungen, die für die Aufgabe irrelevant sind – und Multi-Agenten-Übergaben reichen Befugnisse ohne erneute Prüfung weiter. Die Empfehlungen für die Praxis laufen auf eine Bindung an den Anfragekontext hinaus: Jeder nachgelagerte Aufruf muss den ursprünglichen Benutzer, die Aufgabe und die Autorisierungsentscheidung enthalten, da die Privilegiengrenze vom Zeitpunkt der Anmeldung auf den Zeitpunkt der Anfrage verschoben werden muss. Die Kosten für das Versäumnis zeigen sich in der Literatur zu Sicherheitsverletzungen: Branchenberichte, die sich auf die IBM-Studie zu den Kosten einer Datenpanne 2025 beziehen, zeigen, dass die überwiegende Mehrheit der Unternehmen mit KI-bezogenen Sicherheitsvorfällen keine angemessenen KI-Zugriffskontrollen hatte. Zudem weist der Identitäts-Expositionsbericht 2026 von SpyCloud auf die großflächige Offenlegung von API-Schlüsseln und Tokens hin, einschließlich Anmeldedaten, die mit KI-Tools verknüpft sind. Die für Menschen entwickelten Modelle halten diesen Berichten zufolge den Anforderungen von Agenten nicht stand.

3. TBAC: Eine alte Idee, deren Zeit endlich gekommen ist

Task-based Access Control ist kein neues Konzept – genau das macht seine Wiederbelebung so glaubwürdig. In den 1990er Jahren schlugen Roger Thomas und Ravi Sandhu aufgabenbasierte Autorisierungskontrollen als Wechsel von einer subjektzentrierten hin zu einer aktivitätszentrierten Autorisierung vor: Berechtigungen werden in Aufgaben gebündelt, als minimal erforderliches Set für eine spezifische Aktivität gewährt, für deren Dauer aktiviert und im Verlauf des Workflows verbraucht oder entzogen. Die Idee war ihrer Infrastruktur voraus – die Workflow-Systeme der 90er Jahre benötigten sie nicht dringend genug. KI-Agenten hingegen schon. Ein aktuelles arXiv-Paper zu risikoadaptiver Zugriffskontrolle für agentenbasierte Systeme baut auf TBAC auf, „aufgrund der natürlichen Übereinstimmung mit der zielorientierten Natur von KI-Agenten“ – ein Agent ist, anders als ein Mitarbeiter, tatsächlich nur seine aktuelle Aufgabe.

Die modernen Formulierungen erweitern das ursprüngliche Konzept in zwei Richtungen. Der Ansatz von Cisco Outshift – Tool-, Transaktions- und aufgabenbasierte Zugriffskontrolle – positioniert TBAC explizit als die Ebene jenseits von RBAC, ABAC und ReBAC für agentenbasierte KI: Die Autorisierung ist nicht darauf beschränkt, wer der Agent ist, sondern auf die Tools, die er aufrufen darf, die Transaktionen, die er abschließen kann, und die Aufgabe, die er gerade ausführt. Die Forschungsgrenze untersucht, wie die „Aufgabe“ überhaupt beurteilt wird: Die Arbeit auf arXiv nutzt ein LLM als unsicherheitsbewussten Richter, der prüft, ob eine Aktion der autorisierten Aufgabe dient – vielversprechend, frühzeitig und ehrlich in Bezug auf die noch offenen Probleme. Zwischen dem Konsens der Praktiker und der Forschung zeichnet sich eine Arbeitsdefinition ab. TBAC im Zeitalter der Agenten bedeutet: ein aufgabenbezogenes Berechtigungsbündel (minimale Tools und Daten für dieses Ziel), Dauerbindung (kurzlebige, aufgabenbezogene Anmeldedaten mit einer Gültigkeitsdauer von wenigen Minuten), Delegationserfassung (die Aufgabe enthält Informationen darüber, wer sie autorisiert hat und in wessen Namen), und transaktionale Kontrollpunkte (irreversible Schritte erhalten eine explizite Freigabe). Nichts davon ersetzt die älteren Modelle – es baut auf ihnen auf, was die Design-Erkenntnis ist, die in den nächsten Abschnitten konkretisiert wird.

4. Das Schichtenmodell: Wo jedes BAC seinen Platz behält

Die Fachliteratur ist sich in einem Punkt einig: RBAC vollständig zu ersetzen, ist weder notwendig noch ratsam. Die Modelle lassen sich kombinieren, und in einem LLM/RAG/MCP-Stack hat jedes seine Daseinsberechtigung. RBAC bleibt die äußere Grenze – welche Teams und Dienste überhaupt auf welche Modelle, MCP-Server und Agenten zugreifen dürfen; grob, prüfbar, an der Organisationsstruktur orientiert – genau das, was eine äußere Grenze sein sollte. Richtlinien im ABAC-Stil greifen zum Zeitpunkt der Anfrage – Team, Umgebung, Datenklassifizierung und Kosten-Metadaten entscheiden darüber, ob dieser Aufruf in diesem Kontext ausgeführt wird; bei RAG ist dies der Ort, an dem Berechtigungen auf Dokumentebene angesiedelt sind, sodass der Abruf die Zugriffsrechte des anfragenden Benutzers und nicht die der Pipeline berücksichtigt. ReBAC steuert die Struktur der Daten selbst – Eigentum und Vererbung –, was besonders wichtig ist, wenn Agenten Inhaltsgraphen wie Laufwerke und Wikis durchlaufen. TBAC bindet die Arbeit: das aufgabenbezogene Tool-Bundle, die aufgabenbezogene Berechtigung, der Delegationsdatensatz, der Kontrollpunkt für irreversible Aktionen.

Als Stack gelesen, beantworten die Modelle vier Fragen zu einer Agentenanfrage: Ist dieser Principal hier überhaupt zugelassen (RBAC), ist diese Anfrage im Kontext akzeptabel (ABAC), erlaubt die Struktur der Daten dies (ReBAC), dient diese Aktion der autorisierten Aufgabe innerhalb ihrer Grenzen (TBAC)? Wenn Sie alle vier an einem Kontrollpunkt durchsetzen und mit einem einzigen Audit-Datensatz verknüpfen, erhalten Sie das, was das Zeitalter der Agenten erfordert. Dieser Punkt ist das Gateway – und hier hört das Argument auf, konzeptionell zu sein, denn diese Konstrukte existieren als dokumentierte, ausgelieferte Funktionen.

‍

‍