L'agente AI che lavora per te probabilmente ha più accesso di te

L'IA non sta facendo il lavoro del rappresentante. È uno strumento che il rappresentante usa. Ma lo strumento finisce per avere più accesso al sistema rispetto alla persona per cui lavora. Quella differenza, un umano con accesso limitato che utilizza una non-human identity con accesso più ampio, sta diventando la forma normale di implementazione dell'IA aziendale, e quasi nessuno la esamina come esaminerebbe i permessi di una persona.

Rapporto sulla Sicurezza dei Dati e dell'Identità 2026 di Netwrix, basato su un sondaggio condotto su 2.317 leader della sicurezza e IT, mette numeri dietro questo schema. Il 72% delle organizzazioni afferma che il rischio di esposizione dei dati legati all'identità è aumentato. Il 58% afferma che ora più identità hanno accesso ai dati aziendali rispetto a prima. Il 41% sta già eseguendo AI agentica in produzione, con quegli agenti che agiscono per conto degli umani contro dati sensibili. Le identità non umane non sono un problema futuro. Sono già il principale stakeholder in molti ambienti.

La parte che non appare in una revisione degli accessi

La maggior parte dei programmi di governance dell'identità sono stati costruiti attorno a un ritmo di ingresso, spostamento e uscita. Qualcuno inizia, il suo accesso cresce o cambia, e alla fine se ne va e viene revocato.Service accounts, le chiavi API, i certificati e i token di automazione non seguono questo schema. Vengono creati durante una distribuzione, ereditati dal modello che è stato più veloce da avviare e poi lasciati soli perché nessuno si occupa del follow-up.

Il rapporto lo conferma. Solo il 19% delle organizzazioni afferma di governare completamente le identità non umane. Il 76% non può revocare immediatamente l'accesso permanente quando non è più necessario. Il 64% ha almeno qualche accesso sovraprovvisto a dati critici. Mettendo tutto insieme si ottiene una popolazione di credenziali più grande della forza lavoro umana, più difficile da tracciare e raramente revisionata.

Esiste una versione specifica di questo problema che vale la pena evidenziare: l'autenticazione basata su certificati sta diventando il principale meccanismo di fiducia per agenti AI e automazione, ma la maggior parte delle organizzazioni ha poca visibilità sull'infrastruttura dei certificati sottostante. Modelli configurati in modo errato, diritti di iscrizione eccessivamente permissivi e relazioni di fiducia ereditate in Active Directory Certificate Services possono consentire a un attaccante di impersonare un'identità privilegiata senza mai toccare una password.

Perché questo è un problema di gestione del cambiamento, non solo di identità

Ecco la parte che viene trascurata. I permessi di un account di servizio, la catena di fiducia di un certificato, l'ambito di una chiave API, nulla di tutto ciò risiede solo in una piattaforma di identità. Risiede in file di configurazione, chiavi di registro, archivi di certificati e attività pianificate sui sistemi effettivi in cui l'account opera. Quando cambia un obbligo normativo, che si tratti di un nuovo requisito PCI DSS, di un controllo NIST aggiornato o di una revisione NERC CIP, la revisione degli accessi e la fase di revoca dovrebbero avvenire insieme. In pratica, si presta attenzione al lato identità e il lato configurazione si sposta silenziosamente in background.

Quella deriva è esattamente dove si nasconde la modifica non autorizzata. Una chiave di registro che concede a un account di servizio diritti di iscrizione più ampi di quelli necessari. Un file di configurazione che punta ancora a un'integrazione dismessa. Un modello di certificato modificato sei mesi fa che nessuno ha segnalato per la revisione. Nessuno di questi appare in un foglio di calcolo di certificazione degli accessi. Appaiono quando qualcuno guarda cosa è effettivamente cambiato nel sistema.

Monitorare i sistemi invece che solo l'elenco

È qui che il monitoraggio dell'integrità dei file e la gestione della configurazione di sicurezza trovano il loro posto nella conversazione. Netwrix Change Tracker non gestisce le identità, ma osserva i sistemi su cui risiedono quelle identità e le loro credenziali. Stabilisce una baseline dei file di configurazione, delle chiavi di registro e delle impostazioni di sistema, quindi segnala qualsiasi modifica che si discosti da quella baseline in tempo reale. Quando esiste una regola di Cambio Pianificato, sia che sia collegata a una finestra di patch o a una richiesta approvata di ServiceNow, le modifiche corrispondenti vengono filtrate automaticamente. Ciò che rimane è l'attività non pianificata: la modifica del registro che nessuno ha approvato, la modifica della configurazione senza una richiesta di modifica corrispondente, la deriva che altrimenti rimarrebbe inosservata fino a quando un audit o un incidente non costringe qualcuno a indagare.

Quel modello a circuito chiuso, che confronta le modifiche osservate con quelle approvate tramite integrazioni ITSM come ServiceNow, BMC Remedy e Cherwell, offre ai team di sicurezza e conformità qualcosa che la sola revisione degli accessi non può fornire: un registro a livello di sistema di ciò che è realmente accaduto, quando è accaduto e se era previsto. Combinato con oltre 250 report di conformità predefiniti allineati a framework come PCI DSS, NIST, HIPAA e DISA STIG, quel registro trasforma il "pensiamo che i nostri controlli funzionino" in prove che un revisore può effettivamente verificare.

Il rappresentante riceve ancora la colpa

Se quell'integrazione di Salesforce viene compromessa, o se l'assistente estrae silenziosamente dati al di fuori del suo ambito previsto, il rapporto sull'incidente non nominerà il fornitore di IA. Nominerà l'account che si è autenticato e la persona il cui nome è associato a esso. La governance di Identity può impostare la politica su ciò che quell'account dovrebbe poter toccare. Non può dirti, da sola, cosa è effettivamente cambiato nel sistema lo scorso martedì. Questa è una domanda diversa, e qualcuno deve ancora sorvegliare la risposta.