Riformare il Modello di Identità per Gestire gli Agenti AI in Produzione

Con l’avanzare della tecnologia, gli agenti autonomi di intelligenza artificiale stanno diventando sempre più comuni nelle infrastrutture core delle aziende, dove sono impiegati per eseguire codice, applicare policy e gestire funzioni DevOps. Tuttavia, molti progetti si bloccano a causa di modelli di sicurezza inadeguati, progettati per un contesto con due attori principali: umani e macchine. L’introduzione di agenti AI, che operano a velocità macchina e in modo non deterministico, ha messo in evidenza le lacune di questi sistemi.

Un caso emblematico è quello di un agente che ha cancellato l’intero database di produzione e i relativi backup in soli nove secondi, dimostrando come gli strumenti attuali non siano sufficienti a contenere i rischi associati a questi nuovi attori. Gli ingegneri, nella pratica operativa, tendono a concedere privilegi ampi agli agenti, trattandoli come normali microservizi. Tuttavia, questa strategia è fallace, poiché gli agenti possono eseguire migliaia di azioni in pochi secondi, aumentando il rischio di errori significativi.

I tentativi di implementare misure di autenticazione più rigorose e privilegi a breve durata si scontrano con la frammentazione delle identità nei vari strumenti della stack tecnologica, come cluster Kubernetes, piattaforme cloud e database. Questo porta i team a dover integrare manualmente sistemi di Identity and Access Management (IAM), rendendo difficile la scalabilità delle soluzioni.

Creare nuovi silos di identità per gestire un terzo tipo di attore, gli agenti AI, non fa altro che aggravare la situazione, raddoppiando il lavoro e introducendo ulteriore anonimato tra i sistemi. Per affrontare questa sfida, è necessario riformare il modello di identità esistente. La proposta è di eliminare l’anonimato, fornendo a ogni attore — umano, macchina, workload e agente AI — un’identità di prima classe, protetta criptograficamente da una root of trust hardware. È fondamentale abbandonare credenziali statiche come API key e password e applicare principi di zero-trust.

Gli agenti dovrebbero operare con privilegi di breve durata, legati a specifiche azioni autorizzate da un operatore umano. Questo significa che i privilegi dovrebbero essere attaccati all’azione e non all’attore, consentendo agli agenti di svolgere attività sensibili solo all’interno di un ambiente di esecuzione controllato prima di interagire con l’infrastruttura di produzione. Senza privilegi di default, il potenziale impatto di eventuali errori può essere significativamente ridotto.

Per implementare queste misure, è necessaria una policy di identità unica, gestita da un sistema centralizzato che possa fungere da livello di enforcement tra l’agente e il suo endpoint di inferenza. Con un’architettura unificata, l’identità può diventare il control plane per l’adozione sicura degli agenti AI, essenziali per gestire cambiamenti di routine e risolvere deployment in tempo reale, a condizione di garantire un controllo rigoroso del comportamento.