Wie schränkt fähigkeitsbasierte Zugriffskontrolle die Berechtigungen von Agenten-Tools ein?

Berechtigungsbasierte Zugriffskontrolle begrenzt einen Agenten, indem sie Autorität als explizite, an eine Ressource gebundene Fähigkeit behandelt, statt als implizite Berechtigung, die von jedem Tool-Aufruf übernommen wird.

Auf einem Heimserver kann dadurch ein Agent ein Backup-Ziel prüfen, ein anderer einen einzelnen Dienst neu starten und ein dritter einen Fotoordner lesen, ohne dass ein gemeinsames Master-Passwort erforderlich ist.

Eine Fähigkeit bindet Autorität an eine bestimmte Ressource

Bei der berechtigungsbasierten Zugriffskontrolle wird Autorität als Token oder Referenz dargestellt, die ein Objekt identifiziert und die für dieses Objekt verfügbaren Rechte enthält.

seL4 beschreibt eine Fähigkeit als nicht fälschbares Token, das den Zugriff auf eine Entität oder ein Objekt gewährt. Der Besitz ist Bestandteil des Autorisierungsmechanismus. seL4 stellt Autorität durch Fähigkeiten dar, die auf bestimmte Kernel-Objekte verweisen, und liefert damit ein konkretes Beispiel für an Ressourcen gebundene Autorität im seL4-Fähigkeitsmodell.

Bei einem KI-Agenten für den Heimserver kann ein Backup-Tool daher Autorität für ein einzelnes Repository erhalten, statt impliziten Zugriff auf das gesamte Dateisystem. Allein die Kenntnis eines Pfads gewährt keine Berechtigung.

Besitz ersetzt implizite Autorität durch explizite Delegation

Herkömmliche Umgebungen stellen häufig implizite Autorität über Prozessanmeldedaten oder weitreichende API-Token bereit.

Fähigkeitssysteme machen Autorität in den Referenzen explizit, die eine Komponente tatsächlich besitzt.

seL4 capDL beschreibt, welche Teile eines Systems über Fähigkeiten für welche anderen Teile verfügen. Diese Verteilungen definieren Grenzen der Zugriffskontrolle. Wasmtime beschreibt eine fähigkeitsorientierte Isolation für WASI-Ressourcen und veranschaulicht, wie expliziter Besitz in Wasmtimes fähigkeitsbasierter Sicherheit weitreichenden impliziten Zugriff ersetzen kann.

Ein Unteragent zur Organisation von Fotos kann daher Lesezugriff auf einen Importordner und Schreibzugriff auf einen Zwischenablageordner erhalten, ohne Löschberechtigungen für das Archiv zu bekommen.

Rechte können enger gefasst sein als die Ressource

Eine Fähigkeit kann Rechte enthalten, die festlegen, welche Vorgänge für das referenzierte Objekt verfügbar sind.

Zwei Agenten können Fähigkeiten für dasselbe Objekt besitzen, aber über unterschiedliche Autorität verfügen.

seL4 erklärt, dass eine Fähigkeit eine Objektreferenz zusammen mit Zugriffsrechten kapselt, die zulässige Vorgänge steuern. Die Bytecode Alliance hat WASI als auf fähigkeitsbasierter Sicherheit beruhend beschrieben und damit die Vorstellung unterstützt, dass gewährte Rechte enger gefasst sein können als die Host-Ressource selbst, wie in WASIs fähigkeitsbasierter Sicherheit.

Ein Überwachungs-Workflow könnte über die Berechtigung verfügen, den Status zu lesen, während ein Wartungs-Workflow den Dienst neu starten darf. Der Dienst ist derselbe; die nutzbaren Vorgänge sind es nicht.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Durch Delegation kann ein Untertask eine kleinere Fähigkeit erhalten

Fähigkeitssysteme eignen sich für die Aufteilung von Agenten, weil Autorität zusammen mit der Aufgabe weitergegeben werden kann. Ein übergeordneter Agent kann nur das delegieren, was ein Helfer benötigt, statt ein Master-Passwort weiterzugeben.

Cap'n Proto modelliert RPC-Referenzen als Referenzen, die zugleich die Autorität zum Aufrufen eines Objekts übertragen. Mit der Referenz wird eine bestimmte Fähigkeit weitergegeben. Cap’n Proto RPC behandelt Objektreferenzen als Fähigkeiten, die an andere Komponenten weitergegeben werden können, und bietet damit in Cap’n Protos Objektfähigkeiten ein nützliches Modell für delegierte Autorität.

Ein Helfer, der ein einzelnes Protokollverzeichnis prüfen soll, kann ausschließlich eine Lesefähigkeit für dieses Verzeichnis erhalten. In seiner Eingabeaufforderung können zwar andere Ressourcen erwähnt werden, doch die Autorität lässt sich nicht durch eine Anfrage erweitern.

Fähigkeitsmechanismen und der Tool-Umfang sind unterschiedliche Ebenen

Der Tool-Umfang ist eine Richtlinienentscheidung darüber, wie eng die Handlung eines Agenten begrenzt sein sollte.

Die berechtigungsbasierte Zugriffskontrolle ist ein Laufzeitmechanismus zur Darstellung und Durchsetzung dieser Autorität.

Die Analyse des Tool-Umfangs für KI-Agenten auf Heimservern von ZimaSpace erklärt, warum der Umfang von Aktionen, Ressourcen, Argumenten und Zugangsdaten mit zunehmender Autonomie enger gefasst werden sollte. Die aktuelle Arbeit an IETF-Entwürfen zu abschwächbaren Agenten-Token untersucht delegierte Autorität, die für nachgelagerte Agenten eingeschränkt werden kann, und veranschaulicht damit die Delegationsgrenze im Entwurf zu abschwächbaren Agenten-Token.

Die Durchsetzung von Fähigkeiten bleibt auch dann wichtig, wenn die Agentenlogik versagt. Die Analyse wiederholter Tool-Aufrufschleifen von ZimaSpace zeigt, warum Verhaltensfehler und Autoritätsgrenzen getrennt betrachtet werden müssen.

Widerruf und ältere APIs bleiben Implementierungsgrenzen

Praktische Systeme benötigen weiterhin Möglichkeiten, verlorene Autorität zu widerrufen, temporären Zugriff ablaufen zu lassen und Dienste einzubinden, die nur Benutzer, Rollen oder Bearer-Token verstehen.

seL4 stellt Operationen zur Ableitung und Löschung von Fähigkeiten bereit, doch das Widerrufsverhalten hängt von der umgebenden Architektur ab. Das Projekt cap-std stellt externe Ressourcen als Fähigkeitswerte statt als implizite globale Werte bereit und zeigt zugleich, dass ältere APIs und der Widerruf in fähigkeitsbasierten APIs von cap-std separate technische Herausforderungen bleiben.

Ein Fähigkeits-Wrapper um eine NAS-API ist nur so stark wie das dahinterliegende Gateway. Wenn jede Anfrage letztlich ein uneingeschränktes Administratortoken verwendet, kann die scheinbare Granularität unterhalb dieser Grenze verschwinden.