Hur begränsar behörighetskontroll baserad på kapacitet agenters verktygsbehörigheter?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How Does Capability-Based Access Control Limit Agent Tool Permissions? - Zima Store Online

Kapabilitetsbaserad åtkomstkontroll begränsar en agent genom att göra behörighet till en uttrycklig, resursbunden kapabilitet i stället för en omgivande behörighet som ärvs av varje verktygsanrop.

På en hemserver kan det innebära att en agent får inspektera ett säkerhetskopieringsmål, en annan starta om en viss tjänst och en tredje läsa en fotomapp utan att dela en huvudautentiseringsuppgift.

En kapabilitet knyter behörighet till en specifik resurs

Kapabilitetsbaserad åtkomstkontroll representerar behörighet som en token eller referens som identifierar ett objekt och innehåller de rättigheter som är tillgängliga för objektet.

seL4 beskriver en kapabilitet som en oförfalskningsbar token som ger behörighet att komma åt en entitet eller ett objekt. Innehav är en del av auktoriseringsmekanismen. seL4 representerar behörighet genom kapabiliteter som hänvisar till specifika kärnobjekt, vilket ger ett konkret exempel på resursbunden behörighet i seL4:s kapabilitetsmodell.

För en hem-AI-agent kan ett säkerhetskopieringsverktyg få behörighet till ett enda arkiv i stället för omgivande åtkomst till hela filsystemet. Att bara känna till en sökväg ger ingen behörighet.

Innehav ersätter omgivande behörighet med uttrycklig delegering

Traditionella miljöer exponerar ofta omgivande behörighet genom processautentiseringsuppgifter eller breda API-token.

Kapabilitetssystem gör behörigheten uttrycklig i de referenser som en komponent faktiskt innehar.

seL4 capDL beskriver vilka delar av ett system som innehar kapabiliteter till vilka andra delar. Dessa fördelningar definierar åtkomstkontrollens gränser. Wasmtime beskriver kapabilitetsorienterad isolering för WASI-resurser och visar hur uttryckligt innehav kan ersätta bred omgivande åtkomst i Wasetimes kapabilitetssäkerhetsmodell.

En underagent som organiserar foton kan därför få läsåtkomst till en importmapp och skrivåtkomst till staging utan att få behörighet att radera från arkivet.

Rättigheterna kan vara snävare än resursen

En kapabilitet kan innehålla rättigheter som begränsar vilka åtgärder som är tillgängliga för det refererade objektet.

Två agenter kan inneha kapabiliteter till samma objekt men med olika behörighet.

seL4 förklarar att en kapabilitet kapslar in en objektreferens tillsammans med åtkomsträttigheter som styr tillåtna åtgärder. Bytecode Alliance har beskrivit WASI utifrån kapabilitetsbaserad säkerhet, vilket stöder idén att beviljade rättigheter kan vara snävare än själva värdresursen i WASI:s kapabilitetsbaserade säkerhet.

Ett övervakningsflöde kan ha behörighet att läsa status medan ett underhållsflöde har behörighet att starta om. Tjänsten är densamma, men de användbara åtgärderna är det inte.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Delegering kan överlämna en mindre kapabilitet till en underuppgift

Kapabilitetssystem passar agentuppdelning eftersom behörighet kan överlämnas tillsammans med arbetsuppgiften. En överordnad agent kan delegera endast det som en hjälpare behöver, i stället för att vidarebefordra en huvudautentiseringsuppgift.

Cap'n Proto modellerar RPC-referenser som referenser som också förmedlar behörighet att anropa ett objekt. När referensen överlämnas, överlämnas en specifik förmåga. Cap’n Proto RPC behandlar objektreferenser som kapabiliteter som kan överlämnas till andra komponenter, vilket är en användbar modell för delegerad behörighet i Cap’n Proto-objektkapabiliteter.

En hjälpare som ombeds inspektera en enda loggkatalog kan få en läskapabilitet enbart för den katalogen. Prompten kan nämna andra resurser, men behörigheten kan inte utökas genom en begäran.

Kapabilitetsmekanismer och verktygsomfattning är olika lager

Verktygsomfattning är ett policyval som avgör hur snäv en agentåtgärd bör vara.

Kapabilitetsbaserad åtkomstkontroll är en körningsmekanism för att representera och upprätthålla den behörigheten.

ZimaSpaces analys av verktygsomfattning för hem-AI-agenter förklarar varför omfattningen för åtgärder, resurser, argument och autentiseringsuppgifter bör begränsas i takt med att autonomin ökar. Pågående IETF-arbete med utkast om agenttoken med försvagad behörighet undersöker delegerad behörighet som kan begränsas för efterföljande agenter och illustrerar delegeringsgränsen i utkastet om agenttoken med försvagad behörighet.

Kapabilitetskontroll är fortfarande viktig när agentlogiken fallerar. ZimaSpaces analys av upprepade verktygsanrop i loopar visar varför beteendefel och behörighetsbegränsningar måste hanteras separat.

Återkallande och äldre API:er förblir implementeringsgränser

Praktiska system behöver fortfarande sätt att återkalla förlorad behörighet, låta tillfällig åtkomst upphöra och koppla samman tjänster som endast förstår användare, roller eller bärartoken.

seL4 exponerar operationer för härledning och radering av kapabiliteter, men hur återkallande fungerar beror på den omgivande arkitekturen. Projektet cap-std exponerar externa resurser som kapabilitetsvärden i stället för omgivande globala värden och visar samtidigt att äldre API:er och återkallande är separata tekniska frågor i cap-std:s kapabilitetsbaserade API:er.

Ett kapabilitetsomslag runt ett NAS-API är bara så starkt som gatewayen bakom det. Om varje begäran i slutänden använder en obegränsad administratörstoken kan den skenbara detaljnivån försvinna bakom den gränsen.