Vad är en behörighetstoken, och hur begränsar den en AI-agent i hemmet?
En capability-token ger behörighet baserad på innehav till en specifik resurs och åtgärd och begränsar en agent genom att undanhålla alla funktioner som den inte har tilldelats.
En hushållsagent kan behöva läsa en kalender, tända eller släcka belysningen i ett rum eller ladda upp en vald säkerhetskopia utan att få permanenta administratörsuppgifter. En capability-token kan binda samman resurs, åtgärd, utgångstid, budget och kontext i ett verifierbart tillstånd. Verktygsgatewayen kontrollerar tillståndet vid varje anrop, så enbart text i prompten kan inte utöka agentens behörighet.
Token kombinerar en objektreferens med behörighet
En capability namnger eller slår upp ett skyddat objekt och förmedlar tillåtna åtgärder till den som legitimt innehar den. Till skillnad från en bred API-nyckel följd av en intern ACL-kontroll är själva tillståndet avsiktligt begränsat och omöjligt att förfalska.
Forskning om objektcapabilities beskriver objektcapabilitymodellen som ett sätt att koda åtkomsträttigheter i individuella objekt för att begränsa interaktioner. Fildeskriptorer är ett välkänt lokalt exempel: de ger åtkomst till ett redan öppnat objekt utan att ge godtycklig behörighet att namnge objekt i filsystemet.
En capability kan samexistera med identitet och policy. Identiteten besvarar frågan om vem som är involverad; capabilityn besvarar vilken konkret behörighet som delegerades för den här åtgärden. Denna skillnad förblir synlig under senare tester i hushållet.
Begränsning minskar delegeringen utan att utöka den
En överordnad tjänst kan härleda en underordnad token som är begränsad till en mindre sökväg, en skrivskyddad metod, en kortare giltighetstid, en lägre budget eller en viss begärandekontext. Den underordnade token kan delegera mindre behörighet, men kan inte ta bort begränsningar eller skapa mer omfattande rättigheter.
Macaroons introducerar begränsad auktorisering som stöder kontextuella begränsningar och decentraliserad delegering. Verifieringen kontrollerar signaturkedjan och varje begränsning innan resursservern godkänner en begäran. Mellanresultatet måste förbli granskningsbart innan automatiseringen fortsätter.
Detta är användbart för agenter eftersom en planerare kan ta emot en sessionscapability och skicka en uppgiftsanpassad avledning till en verktygsunderprocess. Underprocessen behöver aldrig rotuppgiften i sin prompt eller miljö. Den gränsen bör mätas separat under realistiska driftsförhållanden.
Innehav, delegering och återkallelse förblir säkerhetsgränser
Den som stjäl en bearer-capability kan använda den tills den löper ut eller återkallas. Tokens behöver skyddad överföring och lagring, målgrupps- eller kanalbindning när det är lämpligt, korta giltighetstider och granskningsidentifierare. Den praktiska konsekvensen blir synlig när flera källor konkurrerar om ett begränsat kontextutrymme.
En säkerhetsanalys av capabilities förklarar skillnaden mellan capability-behörighet och identitetscentrerade kontroller. Modellen minskar den omgivande behörigheten, men bedömer inte om en agents begärda åtgärd återspeglar användarens verkliga avsikt. Detta beroende bör förbli tydligt i det slutliga gränssnittet.
Felgränsen är en alltför omfattande, återanvändbar eller läckt token. Capability-kontroller kan inte förhindra skadlig användning som ryms inom tillståndet, så åtgärder med betydande konsekvenser behöver fortfarande målvalidering, godkännande, hastighetsbegränsningar och synlig återkallelse. Resultatet måste därför kontrolleras mot de ursprungliga beläggen.
Inventera behörighet per token, verktyg och begäran
För varje verktygsanrop ska utfärdare, subjekt eller innehavare, målgrupp, resurs, åtgärd, sökvägsomfattning, budget, utgångstid, delegeringskedja, begränsningar, återkallelsehandtag, krav på godkännande och gransknings-ID registreras. Denna skillnad förblir synlig under senare tester i hushållet.
Jämför tillståndet med capability-baserad säkerhet. Testa sökvägsmanipulation, ändrat enhets-ID, metodsubstitution, återanvändning, utgången token, stulen underordnad token, offlineverifierare, återkallad överordnad token och en tillåten men konsekvensrik begäran. Mellanresultatet måste förbli granskningsbart innan automatiseringen fortsätter.
Godkänn endast när varje verktyg får minsta möjliga tillstånd och inte kan utöka det. Betrakta en lyckad capability-kontroll som auktorisering, inte som ett bevis på användarens avsikt, semantisk säkerhet eller korrekt verktygsutdata. Den gränsen bör mätas separat under realistiska driftsförhållanden.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Kan en lokal LLM återuppta genereringen efter att dess process startats om?
En mekanismförst-förklaring av hur LLM-generering återupptas, avvägningarna kring delade resurser, tre vanliga frågor om frågeförgrening samt ett praktiskt verifieringsprotokoll.
Kan en hemserver köra embeddings och videotranskodning på samma integrerade GPU?
En mekanismfokuserad förklaring av delade iGPU-inbäddningar och omkodning, avvägningar kring delade resurser, tre vanliga frågor om frågefanout och en praktisk verifiering.
Hur påverkar åtkomsttokenets livslängd säkerheten och besvären i hushållet?
En mekanism-först-förklaring av åtkomsttokeners livslängd, avvägningarna kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
