L’autorizzazione negli agenti AI oggi controlla chi agisce, non perché. È il punto di partenza di un post di Databricks a firma Nishith Sinha e Matei Zaharia, che mostra come una prompt injection possa spingere un agente a compiere un’azione autorizzata ma fuori dal suo compito, e come vincolare la sessione a un intento dichiarato chiuda quella falla.
L’attacco sfrutta due lacune. La prima è la prompt injection: un agente legge documenti, pagine web, ticket ed email, e non distingue in modo affidabile il contenuto da processare dalle istruzioni da eseguire. La seconda è che l’autorizzazione basata sull’identità è cieca allo scopo: il role-based access control decide se un’identità può compiere un’azione, non se quell’azione serve al task corrente. Messe insieme, permettono un attacco pulito: nascondere un’istruzione nei dati che l’agente legge e fargli compiere un’azione per cui è autorizzato ma che nessuno gli ha chiesto.
L’esempio è concreto: un agente di data quality con tre tool — query_table, update_dashboard e grant_table_access. L’identità permette tutti e tre, ma lo scopo della sessione è stretto: eseguire il controllo di qualità e pubblicare un riassunto. Una nota piantata in un campo dati (una finta SYSTEM NOTE che chiede di concedere accesso a un auditor esterno) si legge come una richiesta legittima e bypassa le difese del modello. Senza intent policy, l’agente concede l’accesso all’esterno e lo registra come normale attività di audit.
L’autorizzazione basata sull’intento aggiunge un secondo cancello: l’identità decide cosa l’agente può fare, l’intento restringe a ciò che può fare per questo task. In Omnigent è una contextual policy valutata prima di ogni tool call, con tre verdetti — permesso, consenso richiesto, negato — cioè i costrutti ALLOW, ASK e DENY. Con la policy attiva, la lettura è permessa, la scrittura sulla dashboard richiede approvazione umana e la concessione d’accesso è negata perché fuori dallo scopo, anche se l’identità potrebbe eseguirla. Solo l’azione iniettata viene bloccata; la richiesta reale dell’utente si completa.
Il dettaglio che rende il meccanismo credibile è la resistenza alla manomissione: l’agente redige l’intento ma è un umano ad approvarlo, e l’agente non ha alcuna leva per rimuovere, modificare o disabilitare una policy. Anche aggiungerne una richiede approvazione, e in caso di combinazione un singolo diniego vince. È un promemoria utile: negli agenti che girano con credenziali valide, la governance non può fermarsi a chi può, deve arrivare a per quale scopo.
In sintesi
- L’autorizzazione per identità è cieca allo scopo: una injection può dirottare azioni comunque autorizzate.
- Vincolare la sessione a un intento dichiarato blocca l’azione fuori task, lasciando passare la richiesta reale.
- L’intento è redatto dall’agente ma approvato da un umano, e l’agente non può allentarlo.
Fonte: Permission isn’t purpose: Intent-based authorization in Omnigent — https://www.databricks.com/blog/permission-isnt-purpose-intent-based-authorization-omnigent
Hai qualcosa da aggiungere? Unisciti alla discussione.