Il least-privilege è una delle idee più antiche e affidabili della sicurezza. Concedi a un’identità esattamente l’accesso di cui ha bisogno, niente di più, e il raggio d’impatto di qualsiasi compromissione resta contenuto. Per gli account umani e per i service account di lunga durata il modello regge ragionevolmente bene: i ruoli vengono rivisti, le concessioni sono delimitate, le certificazioni degli accessi seguono una cadenza trimestrale.
Gli agenti AI rompono questo modello in sordina. A un agente vengono assegnati una credenziale, uno strumento, una connessione a un server MCP, e da quel momento il suo comportamento è dinamico. Decide a runtime quali risorse leggere, quali scrivere, quale strumento invocare di seguito. La concessione che hai messo nero su bianco il primo giorno descrive un tetto massimo, non ciò che l’agente fa. E poiché gli agenti sono produttivi, quel tetto tende a essere generoso: ruoli di database ampi, accesso in scrittura «per sicurezza», un service account condiviso tra una mezza dozzina di workflow. Il risultato è un parco di sistemi in cui l’accesso permesso e quello effettivamente utilizzato si allontanano l’uno dall’altro, in silenzio, ogni giorno.
Ricerche indipendenti del settore fotografano la portata di questo punto cieco: circa l’82% delle organizzazioni dichiara di avere agenti AI in esecuzione di cui non era a conoscenza (CSA/Token Security, n=418). Non puoi applicare il least-privilege su un parco di sistemi che non riesci a vedere.
Definire la deriva del least-privilege
La deriva del least-privilege è il divario crescente tra l’accesso che a un agente è permesso e l’accesso che si osserva che usa. Ha due direzioni di fallimento, e solo una è evidente.
La direzione evidente è il sottoutilizzo: un agente detiene l’accesso in scrittura a una tabella su cui non ha mai scritto. È un privilegio morto, ed è un rischio che ti porti dietro senza alcun beneficio. La direzione pericolosa è il segnale inverso che ne deriva: quando l’insieme osservato contiene qualcosa che l’insieme permesso non ha mai concesso deliberatamente, c’è un’azione in corso che nessuno ha rivisto. Un job di esportazione che all’improvviso scrive su un bucket da cui aveva sempre e solo letto. Un agente che la policy aveva delimitato a uno schema e che si estende a un altro. Non sono casi esotici: sono la trama quotidiana di agenti collegati tra loro con concessioni troppo ampie.
Il motivo per cui questo è difficile, e il motivo per cui è specifico degli agenti e non degli esseri umani, è che il comportamento è generato, non configurato. Un essere umano con troppi accessi nella maggior parte dei casi non li esercita. Un agente con troppi accessi eserciterà qualsiasi cosa lo aiuti a completare il compito che ha davanti, compresi percorsi che nessuno aveva previsto. La revisione statica delle policy non riesce a stare al passo con un comportamento che cambia a ogni esecuzione.
Trasformare la deriva in un segnale rivedibile
La deriva è pericolosa solo finché resta invisibile. Il compito è trasformarla in un segnale che una persona possa rivedere, e questo richiede due cose che lavorino insieme: l’osservazione continua di ciò che gli agenti toccano davvero e un registro stabile di ciò che era loro permesso toccare.
L’osservazione deve essere read-first. Un collettore che osserva dai log, dalle tracce OpenTelemetry e dai segnali del kernel via eBPF si colloca al di fuori del percorso dati dell’agente. Non è un proxy, non blocca le chiamate, e se si guasta lo fa in modo fail-open nel senso sicuro del termine: l’agente continua a funzionare, perdi visibilità anziché disponibilità. Questa asimmetria conta: un controllo di sicurezza in grado di mandare giù la produzione è un controllo che i team disattivano in sordina. In particolare, lo strato eBPF agisce come ground truth a livello di kernel, la parte attorno a cui un agente non può fare deviazioni (la cattura del kernel proviene da un sensore Tetragon che distribuisci tu; Olivares AI legge l’export di Tetragon e non carica programmi eBPF in proprio), ed è per questo che gli indizi a livello di protocollo come le annotazioni degli strumenti MCP (readOnlyHint, destructiveHint) vengono confermati rispetto a esso anziché ritenuti affidabili. La specifica MCP stessa afferma che quelle annotazioni non sono affidabili; sono i segnali del kernel a rendere reale la conferma.
Ciò che l’osservazione produce è una mappa degli accessi: per ciascun agente, quali risorse ha raggiunto e se ha letto (R) o letto/scritto (RW). La mappa memorizza le relazioni di accesso, non i payload, i segreti o i dati personali. La parte interessante è il confronto:
| Agente | Risorsa | Permesso | Osservato | Deriva |
|---|---|---|---|---|
| data-export-job | prod-postgres | R | R | nessuna |
| data-export-job | s3://billing-exports | R | RW | scrittura non rivista |
| report-builder | analytics-db | R | (inutilizzato) | privilegio morto |
La riga che conta è quella centrale. La policy ha concesso la lettura sul bucket di esportazione; il collettore ha osservato una scrittura. Quella singola riga è il rischio principale che la deriva del least-privilege è pensata per far emergere: un privilegio esercitato che nessuno ha rivisto, attribuito a uno specifico agente anziché a un service account condiviso, perché è proprio l’identità per agente a rendere possibili l’attribuzione e l’audit.
Applicare al momento dell’accesso, non limitarsi a registrarlo
Il rilevamento ti dice che la deriva è avvenuta. Per chiudere il cerchio vuoi che la scrittura non rivista sia un percorso negato, non uno registrato. È qui che entra in gioco la policy valutata al momento dell’accesso.
Olivares AI valuta Cedar come un overlay di forbid sopra ruoli che negano per impostazione predefinita, quindi una regola può solo togliere accesso; questa nega qualsiasi richiesta che tocchi una credenziale segreta, qualunque cosa dica il ruolo.
permit(principal, action, resource);
forbid(principal, action, resource)
when { resource.kind == "credential" && resource.sensitivity == "secret" };Scrivere regole Cedar proprie richiede Business; Community applica i ruoli integrati, l’overlay di diniego nativo e il kill switch; i ruoli personalizzati e le concessioni delimitate sono Business.
Ripercorri concretamente il prima e il dopo.
Prima. Un agente di coding, che detiene un ruolo ampio, chiama uno strumento MCP che scrive su s3://billing-exports. Niente lo ferma. L’azione va a buon fine, si fonde nel traffico normale e ricompare giorni dopo, se mai ricompare, come un’anomalia nella mappa degli accessi. Il divario tra permesso e osservato si è ampliato, e l’unico artefatto è una riga di log che nessuno ha letto.
Dopo. La stessa chiamata allo strumento raggiunge il punto di controllo MCP. Il ruolo dell’agente non consente la scrittura, quindi il punto di controllo nega la chiamata prima che venga eseguita (deny-closed) e registra il diniego nel log di audit firmato, che rende rilevabili le manomissioni. La scrittura non rivista non diventa mai una modifica non rivista. Olivares AI blocca un’azione solo nei suoi quattro punti di enforcement: dentro Claude Code, nel proxy del modello, a ogni chiamata di uno strumento MCP e tra gli agenti. Un job che scrive direttamente su S3, al di fuori di quei punti, non viene bloccato: la mappa degli accessi registra la scrittura e la segnala come deriva da rivedere.
Due proprietà mantengono tutto questo onesto. Primo, ogni consultazione privilegiata della mappa degli accessi è essa stessa sottoposta ad audit, chi ha guardato cosa, perché la mappa è sensibile e uno strumento di sicurezza che non riesce a rendere conto dei propri operatori non è degno di fiducia. Secondo, il livello di confidenza è mostrato in modo trasparente: un arco la cui fonte porta un’identità per agente è contrassegnato attributed, mentre uno visto solo dal kernel è contrassegnato approximate, perché i segnali del kernel indicano un processo, un cgroup o un container, non un agente. Non ti viene mai chiesto di agire su una certezza fabbricata.
La conclusione
Il least-privilege non ha fallito per gli agenti AI; a fallire è stata la cadenza di revisione. Le concessioni sono troppo ampie, il comportamento è dinamico, e le certificazioni trimestrali non riescono a seguire una superficie di accesso che cambia a ogni esecuzione. La soluzione non è un proxy più pesante nel percorso critico. È un’osservazione continua e read-first che produce un confronto tra permesso e osservato, più una policy-as-code che applica il confine corretto al momento dell’accesso, così un agente con privilegi eccessivi viene individuato come segnale rivedibile molto prima di diventare un incidente.
Se vuoi vedere come il collettore, la mappa degli accessi e l’applicazione al momento dell’accesso si combinano senza collocarsi nel percorso dati dei tuoi agenti, la pagina architettura ripercorre il design, e il prodotto mostra come appare la vista permesso-osservato su un parco di sistemi reale.