Wat is een capability-token en hoe beperkt het een AI-agent voor thuisgebruik?
Een capability-token verleent op bezit gebaseerde autoriteit voor een specifieke resource en bewerking en beperkt een agent door elke capability die niet aan de agent is gegeven, achter te houden.
Een huishoudelijke agent moet mogelijk รฉรฉn agenda lezen, de verlichting in รฉรฉn kamer schakelen of een gekozen back-up uploaden zonder permanente beheerdersreferenties te ontvangen. Een capability-token kan resource, actie, vervaldatum, budget en context samenvoegen tot een verifieerbare machtiging. De toolgateway controleert die machtiging bij elke aanroep, zodat alleen prompttekst de autoriteit van de agent niet kan uitbreiden.
Het token combineert een objectreferentie met autoriteit
Een capability benoemt of resolveert een beschermd object en verleent toegestane bewerkingen aan degene die er rechtmatig over beschikt. In tegenstelling tot een brede API-sleutel gevolgd door een interne ACL-lookup, is de machtiging zelf bewust beperkt en niet te vervalsen.
Onderzoek naar object-capabilities beschrijft het object-capabilitymodel als een model dat toegangsrechten in afzonderlijke objecten vastlegt om interacties te beperken. Bestandsdescriptors zijn een bekend lokaal voorbeeld: ze autoriseren toegang tot een al geopend object zonder willekeurige naamgevingsbevoegdheid voor het bestandssysteem te verlenen.
Een capability kan samengaan met identiteit en beleid. Identiteit beantwoordt de vraag wie erbij betrokken is; de capability beantwoordt de vraag welke concrete autoriteit voor deze bewerking is gedelegeerd. Dit onderscheid blijft zichtbaar tijdens latere tests in het huishouden.
Attenuatie beperkt delegatie zonder deze uit te breiden
Een bovenliggende service kan een child-token afleiden dat beperkt is tot een kleiner pad, een alleen-lezenmethode, een kortere vervaldatum, een lager budget of een specifieke requestcontext. Het child-token kan minder autoriteit delegeren, maar kan geen beperkingen verwijderen of ruimere rechten aanmaken.
Macaroons introduceren afgezwakte autorisatie die contextuele beperkingen en gedecentraliseerde delegatie ondersteunt. Bij verificatie worden de handtekeningketen en elke beperking gecontroleerd voordat de resourceserver een verzoek accepteert. Het tussenresultaat moet controleerbaar blijven voordat automatisering ermee verdergaat.
Dit is nuttig voor agents, omdat een planner een sessiecapability kan ontvangen en een taakspecifieke afgeleide kan doorgeven aan รฉรฉn toolsubproces. Het subprocess heeft de hoofdinloggegevens nooit nodig in zijn prompt of omgeving. Die grens moet afzonderlijk worden gemeten onder realistische gebruiksomstandigheden.
Bezit, delegatie en intrekking blijven beveiligingsgrenzen
Iedereen die een bearer-capability steelt, kan deze gebruiken totdat de vervaldatum is bereikt of het token is ingetrokken. Tokens hebben beveiligd transport en opslag nodig, evenals waar passend audience- of kanaalbinding, korte levensduur en audit-ID's. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen strijden om beperkte context.
Een analyse van capabilitybeveiliging legt het onderscheid uit tussen capabilityautoriteit en identiteitsgerichte controles. Het model vermindert ambient authority, maar beoordeelt niet of de gevraagde actie van een agent overeenkomt met de werkelijke intentie van de gebruiker. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.
De foutgrens ligt bij een te ruim, herbruikbaar of gelekt token. Capabilitycontroles kunnen schadelijk gebruik binnen de machtiging niet voorkomen. Daarom hebben ingrijpende acties nog steeds doelvalidatie, goedkeuring, snelheidslimieten en zichtbare intrekking nodig. Het resultaat moet daarom worden gecontroleerd aan de hand van het oorspronkelijke bewijs.
Inventariseer autoriteit per token, tool en verzoek
Leg voor elke toolaanroep de uitgever, het subject of de houder, de audience, de resource, de bewerking, het padbereik, het budget, de vervaldatum, de delegatieketen, beperkingen, de intrekkingsreferentie, de goedkeuringsvereiste en de audit-ID vast. Dit onderscheid blijft zichtbaar tijdens latere tests in het huishouden.
Vergelijk de machtiging met capabilitygebaseerde beveiliging. Test path traversal, een gewijzigd apparaat-ID, methodesubstitutie, hergebruik, een verlopen token, een gestolen child-token, een offline verifier, een ingetrokken parent-token en een toegestane maar ingrijpende aanvraag. Het tussenresultaat moet controleerbaar blijven voordat automatisering ermee verdergaat.
Ga alleen verder wanneer elke tool de minimaal benodigde machtiging ontvangt en deze niet kan uitbreiden. Beschouw het slagen van een capability als autorisatie, niet als bewijs van gebruikersintentie, semantische veiligheid of correcte tooluitvoer. Die grens moet afzonderlijk worden gemeten onder realistische gebruiksomstandigheden.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Kan een lokale LLM de generatie hervatten nadat het proces opnieuw is gestart?
Een mechanismegerichte uitleg van het hervatten van LLM-generatie, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een homeserver embeddings genereren en video transcoderen op dezelfde geรฏntegreerde GPU?
Een uitleg waarin het mechanisme centraal staat van gedeelde iGPU-embeddings en transcodering, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een...
Welke invloed heeft de levensduur van toegangstokens op de beveiliging en het gedoe in het huishouden?
Een mechanismegerichte uitleg van de levensduur van toegangstokens, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
