In che modo il controllo degli accessi basato sulle capacità limita le autorizzazioni degli strumenti degli agenti?
Il controllo degli accessi basato sulle capability limita un agente rendendo l’autorità una capability esplicita e vincolata a una risorsa, invece di un’autorizzazione ambientale ereditata da ogni chiamata a uno strumento.
Su un home server, ciò può consentire a un agente di ispezionare una destinazione di backup, a un altro di riavviare un singolo servizio e a un terzo di leggere una cartella di foto senza condividere una credenziale principale.
Una capability vincola l’autorità a una risorsa specifica
Il controllo degli accessi basato sulle capability rappresenta l’autorità come un token o un riferimento che identifica un oggetto e contiene i diritti disponibili su quell’oggetto.
seL4 descrive una capability come un token non falsificabile che concede il permesso di accedere a un’entità o a un oggetto. Il possesso è parte del meccanismo di autorizzazione. seL4 rappresenta l’autorità tramite capability che fanno riferimento a specifici oggetti del kernel, offrendo un esempio concreto di autorità vincolata a una risorsa nel modello delle capability di seL4.
Per un agente AI domestico, uno strumento di backup può ricevere l’autorità per un solo repository, anziché l’accesso ambientale all’intero filesystem. Conoscere soltanto un percorso non concede alcun permesso.
Il possesso sostituisce l’autorità ambientale con una delega esplicita
Gli ambienti tradizionali espongono spesso un’autorità ambientale tramite le credenziali dei processi o token API con privilegi ampi.
I sistemi basati sulle capability rendono esplicita l’autorità nei riferimenti effettivamente posseduti da un componente.
capDL di seL4 descrive quali parti di un sistema possiedono capability verso quali altre parti. Tali distribuzioni definiscono i confini del controllo degli accessi. Wasmtime descrive l’isolamento orientato alle capability per le risorse WASI, mostrando come il possesso esplicito possa sostituire l’ampio accesso ambientale nel modello di sicurezza basato sulle capability di Wasmtime.
Un sottoagente per l’organizzazione delle foto può quindi ricevere l’accesso in lettura a una cartella di importazione e l’accesso in scrittura all’area di staging, senza ottenere l’autorizzazione a eliminare elementi dall’archivio.
I diritti possono essere più limitati della risorsa
Una capability può contenere diritti che limitano le operazioni disponibili sull’oggetto referenziato.
Due agenti possono possedere capability per lo stesso oggetto con livelli di autorità diversi.
seL4 spiega che una capability incapsula un riferimento a un oggetto e i diritti di accesso che controllano le operazioni consentite. La Bytecode Alliance ha descritto WASI basandosi sulla sicurezza basata sulle capability, sostenendo l’idea che i diritti concessi possano essere più limitati della risorsa host stessa nella sicurezza WASI basata sulle capability.
Un flusso di monitoraggio può avere l’autorità di leggere lo stato, mentre un flusso di manutenzione può avere l’autorità di riavviare il servizio. Il servizio è lo stesso; le operazioni disponibili non lo sono.
La delega può fornire una capability più limitata a un sottocompito
I sistemi basati sulle capability si adattano alla suddivisione degli agenti perché l’autorità può essere trasferita insieme al lavoro. Un agente principale può delegare solo ciò di cui ha bisogno un assistente, invece di inoltrare una credenziale principale.
Cap'n Proto modella i riferimenti RPC come riferimenti che trasmettono anche l’autorità necessaria per chiamare un oggetto. Passare il riferimento significa passare una capacità specifica. Cap’n Proto RPC tratta i riferimenti agli oggetti come capability che possono essere trasferite ad altri componenti, offrendo un modello utile per l’autorità delegata nelle object capability di Cap’n Proto.
A un assistente incaricato di ispezionare una sola directory dei log può essere assegnata una capability di lettura esclusivamente per quella directory. Il suo prompt può menzionare altre risorse, ma l’autorità non può ampliarsi su richiesta.
I meccanismi delle capability e l’ambito degli strumenti sono livelli diversi
L’ambito di uno strumento è una scelta di policy relativa a quanto debba essere limitata un’azione dell’agente.
Il controllo degli accessi basato sulle capability è un meccanismo di runtime per rappresentare e applicare tale autorità.
L’analisi di ZimaSpace sull’ambito degli strumenti per gli agenti AI domestici spiega perché l’ambito delle azioni, delle risorse, degli argomenti e delle credenziali dovrebbe restringersi con l’aumentare dell’autonomia. Gli attuali lavori sulle bozze IETF relativi ai token degli agenti con attenuazione esplorano un’autorità delegata che può essere ulteriormente limitata per gli agenti a valle, illustrando il confine della delega nella bozza sui token degli agenti con attenuazione.
L’applicazione delle capability rimane importante anche quando la logica dell’agente fallisce. L’analisi di ZimaSpace sui cicli ripetuti di chiamate agli strumenti mostra perché i malfunzionamenti comportamentali e i limiti dell’autorità debbano essere trattati separatamente.
La revoca e le API legacy restano confini di implementazione
I sistemi pratici hanno ancora bisogno di modalità per revocare un’autorità compromessa, far scadere gli accessi temporanei e collegare servizi che comprendono soltanto utenti, ruoli o bearer token.
seL4 espone operazioni di derivazione ed eliminazione delle capability, ma il comportamento della revoca dipende dall’architettura circostante. Il progetto cap-std espone le risorse esterne come valori di capability invece che come globali ambientali, mostrando al contempo che le API legacy e la revoca restano problematiche ingegneristiche distinte nelle API cap-std basate sulle capability.
Un wrapper basato sulle capability attorno a un’API NAS è solido solo quanto il gateway che lo supporta. Se ogni richiesta utilizza in ultima istanza un token di amministratore senza restrizioni, la granularità apparente può scomparire oltre quel confine.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Stato di runtime vs stato persistente in Home Assistant: cosa deve sopravvivere al riavvio?
Home Assistant non conserva ogni valore in tempo reale; la configurazione, i registri, gli stati selezionati ripristinati, la cronologia e i dati di distribuzione...
Come autentica Home Assistant le sessioni locali e remote?
Le sessioni Home Assistant locali e remote utilizzano lo stesso modello di identità lato server; l'accesso remoto modifica il percorso e il confine TLS,...
Perché le query della cronologia di Home Assistant possono rallentare man mano che crescono i dati del Recorder?
La crescita del registratore può aumentare il costo delle query della cronologia quando l’intervallo richiesto coinvolge più righe, aumentano i cache miss o le...
