Gli agenti IA possono ereditare i diritti di amministratore locale
Sep 9, 2026
Un agente AI viene eseguito come processo sotto l'account che lo ha avviato e eredita il token di accesso di quell'account. Se l'account ha diritti di amministratore locale, li ha anche l'agente, insieme a ogni processo di supporto e script che genera; un esempio è Claude Desktop che gira sotto un account admin, generando helper PowerShell. Ciò che rende gli agenti diversi da una tipica app privilegiata è che la loro azione successiva spesso deriva da contenuti analizzati in fase di esecuzione, inclusi input non attendibili.
Stesso token, stessi diritti
Windows non ha un livello di permessi separato per "AI process." Un agente, che sia un’estensione del browser, un’app desktop o un servizio in background, inizia come processo figlio di chi lo ha avviato e eredita il token di accesso del genitore. Accedi come utente standard, avvia l’agente e funziona come utente standard. Accedi con un account con local admin rights, e l’agente funziona anche con questi diritti, insieme a tutto ciò che genera per svolgere il suo lavoro: una chiamata PowerShell, un binario di supporto, un runtime locale che installa per poter operare fuori dal sandbox del browser.
I token di processo funzionano in questo modo da decenni. La novità è cosa fanno gli agenti con il token che ereditano. Le applicazioni privilegiate tradizionali eseguono percorsi di codice fissi approvati dai fornitori; gli agenti sono diversi. Leggono e scrivono file locali, eseguono comandi da riga di comando, chiamano le API del sistema operativo per interagire con altre applicazioni e, in un numero crescente di casi, installano un componente locale alla prima esecuzione. Ognuna di queste azioni viene eseguita al livello di privilegio che l'account aveva già.
Su un account con diritti di amministratore locale, quella traccia raggiunge HKEY_LOCAL_MACHINE, il Service Control Manager, le attività pianificate in esecuzione sotto SYSTEM, la memoria del processo LSASS dove risiedono le credenziali, l’installazione dei driver e le ACL che proteggono Program Files e System32. Arrivarci non richiede che l’agente faccia nulla di insolito. L’account ha già la porta aperta. L’agente passa semplicemente come qualsiasi altro processo.
Questo non è lo stesso profilo di rischio di un'app privilegiata normale
I team IT sanno come gestire il rischio derivante da software privilegiato che esegue un set fisso di percorsi di codice scritti dal fornitore. Gli agenti rompono questo modello perché il percorso del codice non è fisso. La mossa successiva di un agente viene spesso decisa in fase di esecuzione, basandosi su un prompt, un documento che sta riassumendo, una pagina web che sta navigando, una conversazione email a cui sta scrivendo una risposta. Se quel contenuto contiene un linguaggio che il modello sottostante interpreta come un’istruzione, e l’agente ha accesso all’uso degli strumenti del sistema operativo, il modello può agire di conseguenza.
Questa è un’iniezione di prompt: testo incorporato in contenuti dall’aspetto ordinario, trattato come un comando invece che come dati. Esegui l’agente con un token utente standard e il raggio d’azione dell’istruzione iniettata rimane limitato a ciò che un utente standard potrebbe già fare. Eseguilo con privilegi di amministratore locale e l’istruzione eredita i privilegi di amministratore; scrivi in chiavi di registro protette, installa attività pianificate, accedi alla rete con credenziali memorizzate nella cache, disabilita l’agente antivirus. Ogni passaggio ora è elevato.
C'è anche un aspetto di visibilità, separato dalla questione dei permessi. Il marketing utilizza un assistente di scrittura. L'ingegneria adotta un assistente di codice. Le vendite installano un riassuntore di riunioni. Ognuno appare su un endpoint diverso, sotto un account diverso, con il proprio ritmo di aggiornamenti e la propria postura di sicurezza del fornitore, solitamente senza alcuna revisione formale da parte dell'IT. Leggere il codice sorgente dell'agente non direbbe molto comunque, poiché ciò che un'istruzione iniettata può fare dipende interamente dall'account sotto cui viene eseguita, non dal codice dell'agente stesso.
Rimuovere i diritti di amministratore locale, anche per AI
Esaminare ogni nuovo strumento di IA per la postura di sicurezza è una gara che l’IT non può vincere contro la rapidità con cui questi strumenti vengono adottati. Tagliare l’eredità alla fonte funziona meglio: togliere i diritti di amministratore locale permanenti dall’account, e non rimane nulla di elevato che un agente o qualsiasi altra cosa in esecuzione sotto quell’account possa ereditare.
Il problema è l’attrito nel flusso di lavoro. Alcuni di questi strumenti devono realmente scrivere in una posizione protetta una volta, durante l’installazione. Rimuovere i diritti di amministratore senza un percorso per un’elevazione limitata in quel passaggio fa aumentare il volume dei ticket di supporto invece di ridurre il rischio.
PolicyPak Least Privilege Manager gestisce questa divisione: il privilegio predefinito dell'account rimane utente standard, e compiti specifici ricevono regole di elevazione. Definisci quale installer, applet o azione può essere eseguita con privilegi elevati, per quali utenti e per quanto tempo. Se un agente necessita di admin per un'installazione di supporto una tantum, limita la regola a quell'installer. Tutto il resto che quell'account fa dopo, incluso l'agente, viene eseguito come utente standard. Un'istruzione iniettata che tenta di scrivere in HKLM o installare un servizio si scontra con la stessa barriera di un utente standard.
Least Privilege Manager copre Windows e macOS. È importante sottolineare questo dato il crescente uso di strumenti AI su flotte Mac, che una policy solo Windows non coprirebbe.
Inizia una prova gratuita per vedere come l'elevazione limitata si applica agli strumenti di AI già in esecuzione sui tuoi endpoint.
Scarica PolicyPakDomande frequenti
Condividi su
Scopri di più
Informazioni sull'autore
Dirk Schrader
VP della Ricerca sulla Sicurezza
Dirk Schrader è un Resident CISO (EMEA) e VP of Security Research presso Netwrix. Con 25 anni di esperienza nella sicurezza informatica e certificazioni come CISSP (ISC²) e CISM (ISACA), lavora per promuovere la cyber resilience come approccio moderno per affrontare le minacce informatiche. Dirk ha lavorato a progetti di cybersecurity in tutto il mondo, iniziando con ruoli tecnici e di supporto all'inizio della sua carriera per poi passare a posizioni di vendita, marketing e gestione prodotti sia in grandi multinazionali che in piccole startup. Ha pubblicato numerosi articoli sull'esigenza di affrontare la gestione dei cambiamenti e delle vulnerabilità per raggiungere la cyber resilience.