Gli agenti AI stanno infrangendo la vecchia mappa delle identità

I team di sicurezza aziendale hanno trascorso anni a costruire programmi di identità basati su un presupposto semplice: ogni principale è o una persona o una macchina. Gli agenti AI rompono questo modello. Possono agire per conto di un utente, chiamare servizi, passare lavoro ad altri agenti e modificare il proprio accesso effettivo durante l'esecuzione in base a prompt, strumenti e passaggi delegati. Questo li rende meno simili a un normale account utente e più simili a un problema di autorizzazione in movimento.

Dati rapidi

• Gli agenti AI non si inseriscono facilmente nella consueta suddivisione tra identità umane e identità macchina.
• Alcuni framework di identità cloud li trattano come identità di workload, insieme ad applicazioni, service principal e managed identity.
• Il report 2024 sulla sicurezza delle applicazioni di Cloudflare afferma che il 31,2% del traffico applicativo elaborato era traffico bot.
• La governance degli agenti diventa più difficile quando l'accesso può cambiare durante un'attività, non solo al login.
• Credenziali a breve durata, inventario, ownership e revoca in tempo reale sono i controlli difensivi fondamentali.

Perché il vecchio modello si piega

Un account umano di solito ha un manager, un percorso di onboarding e un processo di offboarding. Un account di servizio tradizionale ha uno scopo, un proprietario e, si spera, un ruolo ristretto. Gli agenti AI si collocano in modo scomodo tra queste due categorie. Un approccio consiste nel concedere autorizzazioni per conto dell'utente che ha avviato l'agente. Può funzionare per un'attività breve, ma diventa rischioso quando il flusso di lavoro si estende su più sistemi o genera agenti figli.

Il modello più difendibile è trattare l'agente come una propria identità di workload: a breve durata, strettamente limitata e revocabile in modo esplicito. Anche così, resta la sfida del runtime. Se un livello di orchestrazione emette nuovi token, espande la delega o consente all'agente di concatenarsi ad altri servizi, l'ambito di accesso effettivo può ampliarsi mentre l'attività è ancora in corso. Ecco perché le revisioni statiche non bastano da sole.

Dove si trova il rischio reale

La vulnerabilità più grande è spesso la governance, non l'autenticazione. La visibilità dice ai difensori che cosa esiste. La governance determina se quell'accesso debba continuare, essere limitato o essere rimosso. In ambienti con molte identità non umane, i principali orfani e i permessi obsoleti possono diventare percorsi d'attacco silenziosi. Il problema si amplifica quando la durata del token è più lunga della sessione interattiva che lo ha creato.

Ecco anche perché il controllo della sessione conta quanto la robustezza del login. Le linee guida NIST separano l'autenticazione resistente al phishing dalla gestione della sessione, e qui la distinzione è importante. Una MFA forte aiuta alla porta d'ingresso, ma un agente che riutilizza token bearer o eredita l'accesso delegato può restare pericoloso molto tempo dopo che l'utente smette di guardare lo schermo.

Al momento della stesura, le informazioni pubbliche non stabiliscono in modo completo quali implementazioni abbiano i controlli più forti o quanto ampiamente i modelli di identità degli agenti siano stati implementati tra le piattaforme. Le evidenze disponibili supportano un'analisi del rischio, non un'affermazione universale di compromissione o di fallimento.

Cosa devono fare ora i difensori

Inventariare ogni identità non umana, assegnare proprietari e impostare una scadenza dove possibile. Applicare il principio del privilegio minimo fin dall'inizio, invece di ereditare il vecchio accumulo di autorizzazioni. Usare MFA resistente al phishing per gli operatori umani, quindi ridurre la dipendenza dai token bearer riutilizzabili accorciandone la durata e vincolando le sessioni in modo più stretto. Dove la piattaforma lo supporta, applicare policy condizionali e revisioni degli accessi direttamente alle identità di workload. Soprattutto, registrare le catene di delega e le chiamate agli strumenti in modo che l'accesso possa essere ridotto quando cambia il contesto dell'attività.

Conclusione

Gli agenti AI non sono solo un altro workload. Sono un banco di prova per capire se la governance delle identità può tenere il passo con software che agisce, delega e si adatta in tempo reale. La lezione è semplice: se un'identità può cambiare il proprio raggio d'azione a metà attività, allora la sicurezza deve monitorare l'attività, non solo il login.

TECHCROOK

Chiave di sicurezza hardware: Un modo semplice per aggiungere una MFA resistente al phishing per le persone che avviano, approvano o monitorano gli agenti AI. Aiuta a vincolare l'accesso a un dispositivo fisico invece di affidarsi solo a password o codici riutilizzabili.

Scheda Techcrook: Chiave di sicurezza hardware

WIKICROOK

• Identità di workload: Un'identità non umana usata da software, servizi o agenti per accedere alle risorse cloud.
• Accesso condizionale: Un livello di policy che decide se un'identità può autenticarsi in base a condizioni come rischio o contesto.
• Token bearer: Una credenziale che concede accesso a chiunque la possieda, quindi furto o riutilizzo possono estendere il rischio.
• Ciclo joiner-mover-leaver: Il comune processo di identità umana per onboarding, cambio di ruolo e offboarding.
• MFA resistente al phishing: Autenticazione progettata per resistere al phishing vincolando più strettamente il fattore alla sessione o al dispositivo.