L'incidente del Pentagono non è colpa dell'IA: è un problema di controllo degli accessi

Chi ha davvero esposto i dati: l'agente di IA o la persona che gli ha consegnato le chiavi? È facile leggere l'incidente del Pentagono come la storia di una macchina fuori controllo che si infila in una rete riservata. Stando a quanto riportato finora, è stato un essere umano a farcela entrare e a tenerle la porta aperta.

Che cosa è stato riportato

Secondo Wired, un dipendente di Accenture avrebbe collegato un ambiente di produzione sicuro al proprio account Claude personale, in modo che un agente di IA potesse scrivere e distribuire codice. Altre testate, come CDO Magazine, sostengono che questo potrebbe aver esposto credenziali di accesso e informazioni sulla rete. Il resoconto di Wired si basa su fonti anonime e, secondo il riassunto di aiweekly.co, l'agente ha operato sulla rete del Dipartimento della Difesa per circa due mesi prima che qualcuno lo individuasse.

La testata tedesca Golem scrive che a quanto pare dei dati sono usciti dal sistema. Alcuni siti più piccoli si spingono oltre e parlano di informazioni di intelligence esposte, ma noi tratteremmo questi dettagli con cautela finché non emergerà qualcosa di più solido. Resta un'accusa, e la portata esatta dell'esposizione non è stata accertata.

L'agente ha fatto ciò che fanno gli agenti

Prendiamo il dettaglio più grave: l'agente lavorava, a quanto si dice, con accesso amministrativo. Un agente che scrive e distribuisce codice ha bisogno di credenziali per farlo. Ha usato ciò che gli è stato dato. Dare la colpa all'«IA» è come incolpare un fattorino perché è entrato in un edificio dopo che qualcuno gli ha consegnato una chiave universale.

Secondo noi, il fallimento interessante è quello umano, ed è antico. Le ricostruzioni non spiegano perché il dipendente lo abbia fatto, ma lo schema è familiare: qualcuno si affida a uno strumento di cui si fida e lo collega a qualcosa che non avrebbe mai dovuto toccare. Sostituisci l'agente con un account personale di archiviazione cloud o con uno script su un portatile di casa e ottieni una storia simile. Ciò che è cambiato è che lo strumento ora agisce da solo, in fretta e con tutti i permessi che gli vengono concessi.

Per questo è più pericoloso dello shadow IT a cui siamo abituati. Un foglio di calcolo dimenticato resta lì fermo. Un agente con permessi di distribuzione continua a lavorare e, in questo caso, avrebbe continuato per circa due mesi.

Gli agenti hanno bisogno di identità, non di accessi in prestito

La soluzione pratica non è «vietare gli agenti». È trattarli per ciò che sono: un nuovo tipo di attore sulla rete. A nostro avviso significa alcune misure poco appariscenti:

• Un'identità propria. Un agente non dovrebbe mai funzionare con l'account del suo utente umano, e di certo mai come amministratore. Se qualcosa va storto, i log dovrebbero dire «l'agente X ha fatto questo», non «Alice ha fatto questo».
• Ambito ristretto. L'accesso in lettura a un singolo repository è una richiesta ragionevole. L'accesso amministrativo a un ambiente di produzione non è un punto di partenza.
• Revocabile e di breve durata. Credenziali che scadono da sole e si possono disattivare in un solo passaggio trasformano un incidente di due mesi in uno di due ore.
• Visibilità. Il dettaglio che ci colpisce sono i due mesi. Secondo le ricostruzioni, l'agente ha operato in un ambiente sicuro per tutto quel tempo prima di essere individuato. Sembra tanto una lacuna di monitoraggio quanto una lacuna di permessi.

Fai caso al fatto che nulla di tutto questo riguarda il modello. Varrebbe allo stesso modo per qualsiasi strumento autonomo, di qualsiasi fornitore.

Con i collaboratori esterni le regole sono più sottili

L'altra lezione è organizzativa, e qui facciamo ipotesi su come queste falle tendano a nascere, senza descrivere ciò che è accaduto in questo caso. Un collaboratore esterno si trova tra le policy di due aziende, e ciascuna può dare per scontato che sia l'altra a occuparsi del problema. Il datore di lavoro può dire che sui sistemi del cliente valgono le regole del cliente, mentre il cliente può supporre che chiunque abbia un badge sia stato informato. Aggiungi un collaboratore sotto pressione per una scadenza, con un abbonamento personale a un'IA che gli semplifica il lavoro, e la tentazione è evidente.

Ci aspettiamo, ed è una previsione, che l'uso degli agenti venga messo nero su bianco nei contratti con i collaboratori esterni: quali strumenti sono consentiti, su quali sistemi, con quali account e con quale registrazione delle attività. Nessuno dovrebbe dover dedurre che un account personale di IA non c'entra nulla con un sistema di produzione sicuro. Le regole che esistono solo come buon senso non sopravvivono a una scadenza.

Va anche notato che Anthropic, il cui strumento è al centro dei titoli, compare nelle ricostruzioni come il prodotto scelto dal dipendente, non come la parte che ha preso la decisione sull'accesso. La distinzione conta, anche se è ragionevole chiedere al fornitore quali tutele offra per l'uso aziendale e governativo.

Il nostro verdetto

Se guidi un team, non passare questa settimana a discutere se gli agenti siano sicuri. Dedicala a scoprire quali agenti usano già le tue persone, con gli account di chi e con quali permessi. Poi dai a quegli agenti identità proprie, limitate e con scadenza, e metti per iscritto le regole per i collaboratori esterni. L'episodio del Pentagono, se le ricostruzioni reggono, è l'avvertimento a buon mercato. Il prossimo potrebbe non esserlo.