Capability-based Security für Agenten-Tools: minimale Rechte mit eng begrenzten Tokens und Object Capabilities

Wie setzt man bei KI-Agenten das Prinzip der geringsten Rechte durch?

Das Prinzip der geringsten Rechte (Least Privilege) setzen Sie bei KI-Agenten durch, indem Sie jedem einzelnen Werkzeug eine eng begrenzte Berechtigung geben statt einem globalen Schlüssel: ein Token, das genau eine Operation auf genau einem Objekt erlaubt und nach kurzer Zeit verfällt. Dieser Ansatz heißt Capability-based Security. Statt zu fragen „Wer ist dieser Agent und darf er das?“ trägt jede Anfrage selbst den Beweis ihrer Berechtigung mit sich — eine sogenannte Object Capability. Ein Agent, der nur Rechnungen lesen soll, erhält dann keinen Datenbankzugang, sondern eine Referenz, die ausschließlich auf den Lesepfad genau dieser Rechnungen zeigt. Kompromittiert ein Angreifer den Agenten über Prompt Injection, kann er nicht mehr tun, als das eine schmale Recht hergibt.

Genau das ist der Unterschied, der bei autonomen Agenten zählt. Ein klassisches Dienstkonto mit einem allmächtigen API-Schlüssel verwandelt jede Schwachstelle in einen Totalschaden. Eine Capability begrenzt den Schaden auf den Radius des einzelnen Werkzeugs. Im Folgenden zeige ich, warum gerade Agenten dieses Modell brauchen, wie Rechte pro Werkzeug technisch aussehen und welche Stolperfallen Sie in der Praxis vermeiden sollten.

Warum reicht rollenbasierte Zugriffskontrolle bei Agenten nicht aus?

Rollenbasierte Zugriffskontrolle (RBAC) wurde für Menschen und stabile Dienste entworfen. Ein Mitarbeiter hat eine Rolle, die Rolle hat Rechte, und diese Rechte ändern sich selten. Ein KI-Agent verhält sich anders: Er handelt im Sekundentakt, ruft Dutzende Werkzeuge in einer einzigen Sitzung auf und folgt Anweisungen, die teilweise aus nicht vertrauenswürdigen Quellen stammen — aus E-Mails, Dokumenten oder Webseiten, die er verarbeitet.

Das Kernproblem ist das Confused-Deputy-Problem, das schon 1988 von Norm Hardy beschrieben wurde. Ein Programm mit weitreichenden Rechten wird von einer Anweisung dazu gebracht, diese Rechte im Sinne eines Angreifers einzusetzen. Bei Agenten ist dieses Muster kein Randfall, sondern der Normalfall: Prompt Injection ist genau der Versuch, den „verwirrten Stellvertreter“ zu einer Handlung zu überreden, die im Namen des Nutzers, aber im Interesse des Angreifers geschieht. Solange der Agent über eine breite Identität verfügt, die alles darf, übersetzt sich jede gelungene Injection direkt in eine unautorisierte Aktion.

RBAC scheitert hier an einer strukturellen Schwäche: Die Berechtigung ist an die Identität gekoppelt, nicht an die konkrete Operation. Der Agent „ist“ jemand mit Rechten — und behält diese Rechte über die gesamte Sitzung, unabhängig davon, welche Aufgabe gerade läuft. Capability-based Security dreht diese Logik um. Nicht die Identität trägt die Macht, sondern die einzelne, übergebene Referenz auf ein Objekt. Wer die Referenz nicht hat, kann die Operation nicht ausführen — selbst wenn er der „richtige“ Agent ist.

Was sind Object Capabilities und eng begrenzte Tokens konkret?

Eine Object Capability ist eine nicht fälschbare Referenz, die zugleich der Beweis der Berechtigung ist. Klassisch wird das mit einem Schlüssel zu einem Zimmer verglichen: Wer den Schlüssel besitzt, darf hinein — es gibt keine zusätzliche Liste an der Tür, die prüft, ob der Träger berechtigt ist. Die bloße Existenz der Referenz in der Hand des Agenten ist die Autorisierung. In Software bedeutet das: Der Agent erhält keinen Namen einer Ressource, den er gegen eine zentrale Rechteliste eintauschen muss, sondern direkt ein Handle, das die erlaubte Operation kapselt.

In der Welt der Web-Standards übernimmt diese Rolle das eng begrenzte Token. Ein gut entworfenes OAuth-2.1-Zugriffstoken ist im Idealfall genau das: eine Capability in Form einer Zeichenkette. Es trägt einen schmalen Geltungsbereich (Scope), bindet sich an ein Zielpublikum (Audience), läuft nach Minuten ab und lässt sich auf einen einzelnen Empfänger einschränken. Drei Eigenschaften machen aus einem gewöhnlichen Token eine echte Capability:

• Schmaler Geltungsbereich: Das Token erlaubt nur rechnungen:lesen, nicht rechnungen:* und schon gar nicht admin.
• Kurze Lebensdauer: Es verfällt nach wenigen Minuten, sodass ein abgegriffenes Token rasch wertlos wird.
• Bindung an Ziel und Aufruf: Das Token gilt nur für eine bestimmte Ressource (Audience-Restriction) und idealerweise nur für den vorgesehenen Aufrufer (Sender-Constraining via DPoP oder mTLS).

Object-Capability-Systeme im engeren Sinn gehen noch einen Schritt weiter. In Sprachen und Laufzeitumgebungen wie E, Pony oder im Härtungsmodell von Hardened JavaScript (SES) kann ein Programm nur das tun, wozu ihm eine Referenz übergeben wurde. Es gibt keine globalen Variablen, kein import beliebiger Mächtigkeit, keine versteckte Hintertür zum Dateisystem. Diese strenge Form — „keine Autorität außer durch Referenz“ — ist das theoretische Fundament, auf dem die pragmatischen Token-Modelle aufsetzen.

Wie sieht „Rechte pro Werkzeug“ beim Model Context Protocol aus?

Beim Model Context Protocol (MCP), dem De-facto-Standard für die Anbindung von Werkzeugen an KI-Agenten, ist die Frage nach geringsten Rechten besonders dringend. Ein MCP-Server stellt dem Agenten Werkzeuge bereit — und genau hier entscheidet sich, ob der Agent eine schmale Capability oder einen Generalschlüssel erhält.

Die seit 2025 gültige MCP-Autorisierungsspezifikation behandelt den MCP-Server als OAuth-2.1-Resource-Server. Konkret heißt das: Der Agent legt bei jedem Werkzeugaufruf ein Zugriffstoken vor, und dieses Token muss zwei Bedingungen erfüllen. Erstens muss es per Resource Indicators (RFC 8707) explizit an genau diesen MCP-Server als Audience gebunden sein — ein Token für Server A darf bei Server B nicht funktionieren. Zweitens muss sein Scope so eng sein, dass er nur die tatsächlich benötigte Operation abdeckt. Ein Agent, der Kalendereinträge lesen soll, bekommt ein Token mit calendar:read, nicht eines, das zusätzlich calendar:write oder gar mail:send erlaubt.

Damit das praktisch funktioniert, sollten Sie folgende Regeln bei der Gestaltung von Rechten pro Werkzeug beachten:

• Ein Token je Werkzeug-Klasse, nicht je Agent. Trennen Sie lesende von schreibenden Operationen und destruktive von nicht-destruktiven.
• Audience-Bindung erzwingen. Lehnen Sie Tokens ab, deren Audience nicht exakt auf Ihren Server zeigt — das verhindert das Weiterreichen gestohlener Tokens an fremde Dienste (Token-Passthrough gilt in MCP ausdrücklich als Anti-Muster).
• Bestätigung des Nutzers bei folgenreichen Aktionen. Schreiben, Löschen, Zahlen oder das Versenden von Nachrichten sollten eine explizite Freigabe (Human-in-the-Loop) auslösen, selbst wenn das Token sie technisch erlaubt.
• Kurze Token-Lebensdauer plus Rotation. Lange gültige Bearer-Tokens sind die häufigste Quelle stiller Rechteausweitung.

Capability-Token versus klassischer API-Schlüssel: der direkte Vergleich

Der Unterschied zwischen einem traditionellen, weit gefassten Zugang und einer eng begrenzten Capability lässt sich gut gegenüberstellen. Die folgende Tabelle zeigt, warum das Capability-Modell den Schadensradius systematisch verkleinert.

Eigenschaft	Klassischer API-Schlüssel / breite Rolle	Eng begrenztes Capability-Token
Geltungsbereich	Breit, oft alles, was der Dienst kann	Eine Operation auf einem definierten Objekt
Lebensdauer	Langlebig, oft Monate oder unbefristet	Minuten, danach Verfall
Bindung an Ziel	Keine, funktioniert überall	An eine Audience gebunden (RFC 8707)
Bindung an Aufrufer	Keine (Bearer: wer es hat, nutzt es)	Sender-constrained (DPoP / mTLS) möglich
Schaden bei Diebstahl	Vollzugriff, Totalschaden	Begrenzt auf das eine schmale Recht
Widerruf	Schwierig, betrifft alles	Granular, einzelne Capability entziehbar
Confused-Deputy-Schutz	Gering	Hoch, da Recht an Operation gekoppelt

Der entscheidende Punkt steht in der vorletzten Zeile: Bei einem klassischen Schlüssel müssen Sie im Schadensfall alles widerrufen und neu ausstellen. Bei Capabilities entziehen Sie genau die eine Referenz, die missbraucht wurde — der Rest des Systems läuft ungestört weiter.

Welche Fehler unterlaufen Teams bei der Umsetzung am häufigsten?

Das Modell ist überzeugend, doch in der Praxis verwässern Teams es oft, bis kaum mehr Schutz übrig bleibt. Vier Muster begegnen mir besonders häufig.

Der „eine Token für alles“-Pragmatismus. Aus Bequemlichkeit stellt das Team ein einziges Token mit weitem Scope aus, das alle Werkzeuge eines Agenten abdeckt. Damit ist die Capability-Idee tot, bevor sie wirkt — der Schadensradius ist wieder der gesamte Dienst. Die Trennung pro Werkzeug ist kein Detail, sondern der Kern.

Token-Passthrough. Ein MCP-Server nimmt das Token des Nutzers entgegen und reicht es ungeprüft an einen nachgelagerten Dienst weiter. Damit umgeht er die Audience-Bindung und macht den eigenen Server zum „verwirrten Stellvertreter“. Die MCP-Spezifikation untersagt dieses Muster ausdrücklich; jeder Server muss prüfen, dass ein Token für ihn selbst ausgestellt wurde.

Vergessene Ablaufzeiten und fehlende Rotation. Ein Capability-Token, das ein Jahr gültig bleibt, ist faktisch ein klassischer Schlüssel im neuen Gewand. Kurze Lebensdauer ist keine optionale Verschärfung, sondern Teil der Definition. Ohne automatische Rotation sammeln sich langlebige Geheimnisse an, die niemand mehr überblickt.

Verwechslung von Authentifizierung und Autorisierung. Dass ein Agent korrekt authentifiziert ist — also kryptografisch belegen kann, wer er ist —, sagt nichts darüber aus, was er tun darf. Capability-based Security verlagert das Gewicht bewusst auf die Autorisierung der einzelnen Handlung. Wer beides vermengt, baut am Ende wieder ein identitätszentriertes Modell und verliert den Vorteil.

Wie führt man Capability-based Security schrittweise ein?

Sie müssen Ihr System nicht über Nacht umbauen. Ein gangbarer Weg hin zu geringsten Rechten für Agenten verläuft in Stufen, die jeweils für sich genommen Sicherheit gewinnen.

Beginnen Sie mit einer Inventur der Werkzeuge und ihrer wahren Anforderungen. Notieren Sie für jedes Werkzeug, welche Operation es auf welchem Objekt tatsächlich braucht. Häufig zeigt sich dabei, dass die Hälfte der erteilten Rechte nie genutzt wird. Diese Erkenntnis allein erlaubt schon eine erste Verschmälerung der Scopes.

Im zweiten Schritt trennen Sie Lesen von Schreiben und ziehen folgenreiche Operationen heraus. Geben Sie dem Agenten standardmäßig nur lesende Capabilities und verlangen Sie für schreibende oder löschende Aktionen ein separates, kurzlebiges Token plus eine explizite Freigabe. Damit fangen Sie den größten Teil des Risikos aus Prompt Injection ab, ohne den Funktionsumfang einzuschränken.

Schließlich verankern Sie die Bindungen technisch: Audience-Restriction über Resource Indicators, kurze Ablaufzeiten mit Rotation und, wo möglich, Sender-Constraining per DPoP oder mTLS, damit ein gestohlenes Token außerhalb des vorgesehenen Aufrufers wertlos ist. Begleiten Sie das mit lückenloser Protokollierung jedes Werkzeugaufrufs — denn auch die beste Capability hilft nur, wenn Sie Missbrauch erkennen und die betroffene Referenz gezielt entziehen können.

Capability-based Security ist kein Produkt, das Sie kaufen, sondern eine Entwurfshaltung: Jede Berechtigung ist eine bewusst übergebene, eng begrenzte Referenz — nie ein Generalschlüssel. Für autonome Agenten, die fremde Anweisungen verarbeiten, ist diese Haltung die wirksamste Antwort auf das Confused-Deputy-Problem, das ihr Wesen ausmacht.