I piani dell’agente divergono dai permessi quando il pianificatore ragiona a partire da descrizioni o successi passati, mentre l’autorizzazione dipende da identità, obiettivo, stato e criteri attuali.
Un agente domestico può vedere uno strumento per “gestire i file” e pianificare lo spostamento di un backup, mentre il suo token delegato consente solo letture in una condivisione. Il piano può essere logicamente corretto e tuttavia ineseguibile. L’allineamento richiede capacità leggibili dalle macchine, controlli preliminari consapevoli dell’identità, motivazioni esplicite dei rifiuti e una nuova pianificazione quando i permessi o lo stato delle risorse cambiano tra la pianificazione e l’esecuzione.
Le descrizioni degli strumenti di solito nascondono le condizioni di autorizzazione
Un nome e uno schema JSON spiegano come chiamare uno strumento, non quali utenti, percorsi, destinatari, orari o importi siano consentiti. Il modello colma questa lacuna con supposizioni apprese dagli esempi o dalle sessioni precedenti, producendo passaggi al di fuori dell’autorità attiva.
La ricerca sulla rappresentazione delle capacità individua nella rappresentazione delle capacità e nel rilevamento dipendente dal contesto problemi fondamentali per i sistemi ad agenti. Gli annunci leggibili dalle macchine aiutano la pianificazione, ma la capacità dichiarata deve comunque essere sottoposta ad autorizzazione durante l’esecuzione. Questa distinzione resta evidente anche nelle successive prove domestiche.
Esporre descrittori delle capacità a livello di azione con ambiti, vincoli, classi di rischio e approvazioni necessarie. Quando necessario, mantenere i dettagli sensibili delle policy fuori dal prompt, fornendo però al pianificatore vincoli astratti sufficienti a evitare rami impossibili. Il risultato intermedio deve restare ispezionabile prima che l’automazione proceda.
L’identità delegata può essere più limitata dell’account umano
Un agente agisce spesso per conto di un utente tramite un token a breve durata o un’identità di servizio. La sua autorità può escludere azioni amministrative, cartelle private, metodi distruttivi o destinatari esterni, anche quando l’essere umano potrebbe eseguirle manualmente.
Un’analisi dei modelli di autorizzazione per gli agenti sostiene che gli agenti necessitano di modelli progettati per flussi di lavoro delegati non deterministici, anziché ereditare integralmente gli accessi dell’essere umano. Questo spiega perché “l’utente può farlo” non sia un presupposto valido per il pianificatore.
La pianificazione dovrebbe associare ogni passaggio all’attore effettivo e alla capacità richiesta. Se è necessario un altro membro della famiglia, un’approvazione o una credenziale con privilegi elevati, rappresentare esplicitamente tale dipendenza invece di scoprirla solo dopo diversi passaggi successivi.
I permessi e gli obiettivi possono cambiare dopo la pianificazione
I file vengono spostati, le condivisioni si disconnettono, i token scadono, i dispositivi vanno offline, le finestre di approvazione si chiudono e le policy cambiano. Un piano convalidato al momento della creazione può fallire pochi secondi dopo, quindi il livello di esecuzione deve autorizzare ogni effetto collaterale in base allo stato attuale, immediatamente prima che si verifichi.
Un approccio pratico alle autorizzazioni a livello di azione raccomanda di applicare tali autorizzazioni nel percorso della richiesta e di registrare sia le chiamate consentite sia quelle rifiutate. La telemetria dei rifiuti diventa un feedback strutturato per la nuova pianificazione, anziché un errore opaco dello strumento. Questo confine dovrebbe essere misurato separatamente in condizioni operative realistiche.
Il punto di fallimento consiste nel ripetere la pianificazione rispetto a capacità impossibili. Dopo un rifiuto, aggiornare l’istantanea delle capacità, classificare l’eventuale esistenza di un’alternativa sicura e fermarsi dopo un numero limitato di tentativi. Non indebolire mai la policy né sostituire uno strumento con uno più ampio soltanto per completare l’obiettivo.
Eseguire un test di fattibilità del piano consapevole dei permessi
Definire attività i cui permessi necessari siano completamente disponibili, parzialmente disponibili, scaduti, specifici per l’obiettivo, soggetti ad approvazione o impossibili. Generare piani dallo stesso obiettivo, quindi eseguire un controllo preliminare di ogni passaggio proposto rispetto all’utente effettivo, al token dell’agente, all’obiettivo e alla policy corrente.
Mettere i fallimenti in relazione con la sicurezza delle capacità, in cui i livelli di policy degli strumenti separano il possesso di un’autorizzazione circoscritta da un’autorità ambientale ampia. Registrare i passaggi impossibili rilevati prima dell’esecuzione, i rifiuti durante l’esecuzione, le nuove pianificazioni, le richieste di approvazione, gli strumenti alternativi e le rinunce finali.
Il test è superato quando il pianificatore evita le azioni note come impossibili, l’esecuzione rileva le condizioni cambiate e i rifiuti producono una nuova pianificazione sicura e limitata. Un piano che riesce solo aumentando i privilegi fino a una credenziale più ampia rappresenta un fallimento della policy, non l’adattabilità dell’agente.
Hub Tecnologico e AI
Altro da leggere

Quali componenti consentono la ricerca ibrida tra i file NAS?
Scopri come gli identificatori esatti e il significato semantico portano a un unico risultato di ricerca NAS classificato, senza aggirare le autorizzazioni né nascondere...

Quali funzionalità consentono una selezione affidabile delle versioni dei documenti nel RAG?
Scopri come RAG seleziona la revisione pertinente invece della copia obsoleta più simile e come testare gli aggiornamenti espliciti, impliciti e sovrapposti.

Quali componenti consentono l’approvazione umana nelle automazioni IA multi-fase?
Scopri come un’automazione si mette in pausa senza occupare un worker, presenta una modifica esaminabile e riprende esattamente dal ramo approvato dopo ritardi o...

