Hoe beperkt toegangsbeheer op basis van mogelijkheden de machtigingen van agenttools?

Op mogelijkheden gebaseerde toegangscontrole beperkt een agent door bevoegdheden expliciet vast te leggen als een aan een resource gebonden mogelijkheid, in plaats van als een impliciete toestemming die van elke toolaanroep wordt geërfd.

Op een thuisserver kan één agent daarmee een back-updoel inspecteren, een andere één service herstarten en een derde een fotomap lezen, zonder dat ze een hoofdreferentie delen.

Een capability koppelt bevoegdheid aan een specifieke resource

Op mogelijkheden gebaseerde toegangscontrole geeft bevoegdheden weer als een token of verwijzing die een object identificeert en de beschikbare rechten voor dat object bevat.

seL4 beschrijft een capability als een onvervalsbaar token dat toestemming geeft om toegang te krijgen tot een entiteit of een object. Het bezit ervan maakt deel uit van het autorisatiemechanisme. seL4 geeft bevoegdheden weer via capabilities die verwijzen naar specifieke kernelobjecten en daarmee een concreet voorbeeld bieden van aan resources gebonden bevoegdheden in het capabilitymodel van seL4.

Voor een AI-agent thuis kan een back-uptool bevoegdheden krijgen voor één repository, in plaats van impliciete toegang tot het volledige bestandssysteem. Alleen het kennen van een pad geeft geen toestemming.

Bezit vervangt impliciete bevoegdheden door expliciete delegatie

Traditionele omgevingen bieden vaak impliciete bevoegdheden via procesreferenties of brede API-tokens.

Capabilitysystemen maken bevoegdheden expliciet in de verwijzingen die een component daadwerkelijk bezit.

seL4 capDL beschrijft welke onderdelen van een systeem capabilities bezitten voor welke andere onderdelen. Die verdeling bepaalt de grenzen van toegangscontrole. Wasmtime beschrijft capabilitygerichte isolatie voor WASI-resources en laat zien hoe expliciet bezit brede impliciete toegang kan vervangen in het capabilitybeveiligingsmodel van Wasmtime.

Een subagent voor het ordenen van foto's kan zo leestoegang krijgen tot een importmap en schrijftoegang tot staging, zonder verwijderbevoegdheid voor het archief te krijgen.

Rechten kunnen beperkter zijn dan de resource

Een capability kan rechten bevatten die beperken welke bewerkingen op het verwezen object beschikbaar zijn.

Twee agents kunnen capabilities voor hetzelfde object bezitten, maar met verschillende bevoegdheden.

seL4 legt uit dat een capability een objectverwijzing plus toegangsrechten bevat die bepalen welke bewerkingen zijn toegestaan. De Bytecode Alliance heeft WASI beschreven rond op capabilities gebaseerde beveiliging. Dat ondersteunt het idee dat verleende rechten beperkter kunnen zijn dan de hostresource zelf in op capabilities gebaseerde beveiliging in WASI.

Een monitoringworkflow kan bijvoorbeeld bevoegdheid hebben om de status te lezen, terwijl een onderhoudsworkflow bevoegdheid heeft om te herstarten. De service is dezelfde; de bruikbare bewerkingen zijn dat niet.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Delegatie kan een kleinere capability aan een subtaak doorgeven

Capabilitysystemen passen goed bij het opsplitsen van agents, omdat bevoegdheden samen met het werk kunnen worden doorgegeven. Een bovenliggende agent kan alleen doorgeven wat één helper nodig heeft, in plaats van een hoofdreferentie door te sturen.

Cap'n Proto modelleert RPC-verwijzingen als verwijzingen die ook de bevoegdheid overbrengen om een object aan te roepen. Het doorgeven van de verwijzing geeft een specifieke mogelijkheid door. Cap’n Proto RPC behandelt objectverwijzingen als capabilities die aan andere componenten kunnen worden doorgegeven. Dat is een bruikbaar model voor gedelegeerde bevoegdheden in objectcapabilities in Cap’n Proto.

Een helper die één logmap moet inspecteren, kan een leescapability krijgen die alleen voor die map geldt. In de prompt kunnen andere resources worden genoemd, maar de bevoegdheid kan niet op verzoek worden uitgebreid.

Capabilitymechanismen en toolbereik zijn verschillende lagen

Toolbereik is een beleidskeuze over hoe beperkt een actie van een agent moet zijn.

Op mogelijkheden gebaseerde toegangscontrole is een runtime-mechanisme om die bevoegdheid weer te geven en af te dwingen.

De analyse van het toolbereik van een AI-agent voor thuis van ZimaSpace legt uit waarom het bereik van acties, resources, argumenten en referenties smaller moet worden naarmate de autonomie toeneemt. Lopend IETF-ontwerpwerk rond het beperken van agenttokens onderzoekt gedelegeerde bevoegdheden die voor downstream-agents kunnen worden ingeperkt. Dat illustreert de delegatiegrens in het ontwerp voor het beperken van agenttokens.

Capabilityhandhaving blijft belangrijk wanneer de logica van de agent faalt. De analyse van herhaalde toolaanroepen van ZimaSpace laat zien waarom gedragsfalen en bevoegdheidsgrenzen afzonderlijk moeten worden behandeld.

Intrekking en verouderde API's blijven implementatiegrenzen

Praktische systemen hebben nog steeds manieren nodig om verloren bevoegdheden in te trekken, tijdelijke toegang te laten verlopen en verbindingen te leggen met services die alleen gebruikers, rollen of bearer tokens begrijpen.

seL4 biedt bewerkingen voor capabilityafleiding en -verwijdering, maar het gedrag bij intrekking hangt af van de omliggende architectuur. Het cap-std-project stelt externe resources beschikbaar als capabilitywaarden in plaats van als impliciete globale waarden en laat tegelijk zien dat verouderde API's en intrekking afzonderlijke technische aandachtspunten blijven in op capabilities gebaseerde API's van cap-std.

Een capabilitywrapper rond een NAS-API is slechts zo sterk als de gateway erachter. Als elk verzoek uiteindelijk een onbeperkte beheertoken gebruikt, kan de schijnbare fijnmazigheid onder die grens verdwijnen.