Che cos'è un token di capacità e come limita un agente IA domestico?
Un token di capacità concede un'autorità basata sul possesso su una risorsa e un'operazione specifiche, limitando un agente negandogli ogni capacità che non gli è stata assegnata.
Un agente domestico potrebbe dover leggere un calendario, accendere o spegnere le luci di una stanza oppure caricare un backup selezionato, senza ricevere credenziali amministrative permanenti. Un token di capacità può associare risorsa, azione, scadenza, budget e contesto in un'autorizzazione verificabile. Il gateway degli strumenti controlla tale autorizzazione a ogni chiamata, quindi il solo testo del prompt non può ampliare l'autorità dell'agente.
Il token combina un riferimento a un oggetto con l'autorità
Una capacità identifica o risolve un oggetto protetto e trasmette le operazioni consentite a chi ne è legittimamente in possesso. A differenza di una chiave API generica seguita da una ricerca ACL interna, l'autorizzazione stessa è volutamente circoscritta e non falsificabile.
La ricerca sulle capacità degli oggetti descrive il modello delle capacità degli oggetti come un sistema che codifica i diritti di accesso in singoli oggetti per limitare le interazioni. I descrittori di file sono un esempio locale familiare: autorizzano l'accesso a un oggetto già aperto senza concedere un'autorità arbitraria sulla denominazione del filesystem.
Una capacità può coesistere con identità e policy. L'identità risponde alla domanda su chi è coinvolto; la capacità indica quale autorità concreta è stata delegata per questa operazione. Questa distinzione resta visibile durante i successivi test domestici.
La restrizione riduce la delega senza ampliarla
Un servizio principale può derivare un token secondario limitato a un percorso più ristretto, a un metodo di sola lettura, a una scadenza più breve, a un budget inferiore o a uno specifico contesto della richiesta. Il token secondario può delegare meno autorità, ma non può rimuovere le limitazioni né creare diritti più ampi.
I Macaroon introducono un'autorizzazione limitata che supporta limitazioni contestuali e delega decentralizzata. La verifica controlla la catena di firme e ogni limitazione prima che il server della risorsa accetti una richiesta. Il risultato intermedio deve rimanere ispezionabile prima che l'automazione proceda.
Questo è utile per gli agenti perché un pianificatore può ricevere una capacità di sessione e passare a un sottoprocesso di uno strumento una derivazione specifica per l'attività. Il sottoprocesso non ha mai bisogno della credenziale principale nel prompt o nell'ambiente. Questo confine dovrebbe essere misurato separatamente in condizioni operative realistiche.
Possesso, delega e revoca restano confini di sicurezza
Chiunque rubi una capacità bearer può utilizzarla fino alla scadenza o alla revoca. I token richiedono trasporto e archiviazione protetti, un vincolo di audience o di canale quando appropriato, durate brevi e identificativi di audit. La conseguenza pratica emerge quando diverse fonti competono per un contesto limitato.
Un'analisi della sicurezza basata sulle capacità spiega la distinzione tra autorità basata sulle capacità e controlli incentrati sull'identità. Il modello riduce l'autorità ambientale, ma non stabilisce se l'azione richiesta da un agente rifletta la reale intenzione dell'utente. Questa dipendenza dovrebbe restare esplicita nell'interfaccia finale.
Il confine di errore è costituito da un token troppo ampio, riutilizzabile o trapelato. I controlli sulle capacità non possono impedire un uso dannoso che rientra nell'autorizzazione, quindi le azioni consequenziali richiedono comunque la validazione della destinazione, l'approvazione, limiti di frequenza e una revoca osservabile. Il risultato deve quindi essere verificato rispetto alle prove originali.
Inventaria l'autorità per token, strumento e richiesta
Per ogni chiamata a uno strumento, registra emittente, soggetto o detentore, audience, risorsa, operazione, ambito del percorso, budget, scadenza, catena di delega, limitazioni, riferimento per la revoca, requisito di approvazione e ID di audit. Questa distinzione resta visibile durante i successivi test domestici.
Confronta l'autorizzazione con la sicurezza basata sulle capacità. Verifica l'attraversamento del percorso, la modifica dell'ID del dispositivo, la sostituzione del metodo, il riutilizzo, il token scaduto, il token secondario rubato, il verificatore offline, il token principale revocato e una richiesta consentita ma ad alto impatto. Il risultato intermedio deve rimanere ispezionabile prima che l'automazione proceda.
Procedi solo quando ogni strumento riceve l'autorizzazione minima e non può ampliarla. Considera il successo della capacità come un'autorizzazione, non come una prova dell'intenzione dell'utente, della sicurezza semantica o della correttezza dell'output dello strumento. Questo confine dovrebbe essere misurato separatamente in condizioni operative realistiche.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Un LLM locale può riprendere la generazione dopo il riavvio del processo?
Una spiegazione della ripresa della generazione degli LLM incentrata sui meccanismi, dei compromessi relativi alle risorse condivise, tre domande frequenti sul fan-out delle query...
Un server domestico può eseguire embedding e transcodifica video sulla stessa GPU integrata?
Una spiegazione basata innanzitutto sui meccanismi degli embedding condivisi della iGPU e della transcodifica, dei compromessi legati alle risorse condivise, tre domande frequenti sul...
In che modo la durata del token di accesso influisce sulla sicurezza e sulle difficoltà per le famiglie?
Una spiegazione della durata dei token di accesso basata prima di tutto sul meccanismo, dei compromessi legati alle risorse condivise, di tre domande frequenti...
