Sono ufficialmente 60 i tipi di agenti AI locali che la piattaforma Microsoft riesce a individuare, 35 in più rispetto a prima. Fra quelli che rispondono all’appello ci sono Claude Code, OpenAI Codex e GitHub Copilot. Inoltre, l’azienda di Redmond ha introdotto i permessi dinamici, per cui un agente parte senza alcuna autorizzazione e riceve solo quella necessaria al compito che deve svolgere. Non ultimo, la piattaforma affianca ora ai controlli un rischio calcolato in continuo e un team di Guardian Agents capaci di intervenire alla velocità delle macchine. Le novità riguardano Microsoft 365 E7 e Project Perception e ruotano attorno all’idea che ogni agente è un rischio interno e va trattato di conseguenza.

Gli agenti scrivono codice, analizzano i ricavi, ricercano prodotti, approvano note spese e agiscono sui sistemi che fanno funzionare l’azienda. Per essere utili hanno bisogno di accedere a dati, applicazioni, strumenti e altri agenti, ed è proprio quell’accesso a renderli un insider risk. Gli agenti sono attori abili, con accesso a sistemi importanti, e come tali possono sbagliare, essere manipolati o compromessi, senza che siano malevoli per natura. Il contesto in continua evoluzione può fare sì che un agente sicuro all’inizio di un compito possa diventare rischioso prima di averlo concluso. A differenza degli insider umani, inoltre, un agente può operare senza pause, a velocità e su scala da macchina.

L’architettura di fiducia a cui Microsoft si ispira è quella descritta di recente dal CEO Satya Nadella, che separa la fornitura di intelligenza dall’autorità su di essa. Il concetto è semplice: un modello non può essere la propria autorità di sicurezza, e i controlli che stabiliscono a che cosa può accedere, quali azioni può compiere e se debba continuare a operare devono stare fuori dal modello, dove questo non possa aggirarli né manometterli. Da qui la nuova base della security firmata Microsoft, che consiste nel circondare l’intelligenza non deterministica con controlli deterministici, evidenze indipendenti e confini di contenimento. Si parte dal presupposto che l’agente possa fallire o essere compromesso, lo si osserva di continuo e se ne adatta l’autorità al variare del rischio.

Quattro responsabilità continue

Il modello di Microsoft prevede quattro responsabilità. La prima è sapere quali agenti esistono, chi li possiede, perché sono stati creati e che cosa stanno facendo. La seconda è contenere ciò a cui ciascun agente può accedere e ciò che può fare prima che agisca. La terza è proteggere tutto ciò che si trova lungo il suo percorso. La quarta è adattare la protezione al variare di comportamento, contesto e rischio. Ciascun agente deve operare dentro tutte e quattro.

I sistemi nati per proteggere le persone e le applicazioni tradizionali restano indispensabili, ma da soli non bastano per tutelare l’azienda da tutti i rischi degli agenti autonomi. Un agente è un insieme di quattro componenti: il modello, il software che ne coordina il lavoro, l’insieme degli strumenti e delle risorse a cui può ricorrere e l’ambiente in cui viene eseguito. La protezione deve coprire identità, permessi, dati, dispositivi, rete, cloud e ambiente di esecuzione. I team di sicurezza stabiliscono obiettivi di business, regole, limiti di approvazione e responsabilità, mentre il sistema di sicurezza osserva, valuta e interviene.

Microsoft porta l’esempio di un agente che approva le note spese. Deve poter leggere le richieste, verificare la policy e approvare i rimborsi di routine, e identità, runtime, percorsi di accesso e autorità limitata al compito devono essere espliciti fin dall’inizio.

Individuare ogni agente e dargli un’identità

Partendo dal noto presupposto che non si può proteggere ciò che non si vede, Microsoft Security usa integrazioni native, connettori e sensori lungo tutto lo stack di sicurezza per censire il patrimonio di agenti. Le organizzazioni possono portare gli agenti individuati, a prescindere da come siano stati scoperti, in un registro unificato per capirne proprietà, attività e rischio.

Individuare un agente indica che esiste, mentre l’identità offre ai sistemi di sicurezza e governance un ancoraggio stabile per controllarlo. Ogni agente deve avere un’identità di prima classe, distinta da quella della persona che lo usa o lo sponsorizza. Microsoft estende Entra Agent ID con tipi di identità per ulteriori modelli di agente, inclusi quelli locali e quelli sconosciuti scoperti dai sensori di sicurezza; un agente può quindi diventare bersaglio di policy anche se all’origine non era integrato con Microsoft Security. L’identità consente di attribuire azioni, proprietà, ciclo di vita, rischio, permessi, autorizzazioni e policy, così l’azienda distingue ciò che ha fatto una persona da ciò che un agente ha fatto per suo conto.

Contenere ciò che l’agente può fare prima che agisca

Il primo livello è l’ambiente di esecuzione. Il modello e il software che ne coordina il lavoro devono girare in un ambiente controllato, invece di ereditare un accesso con tutti i privilegi al dispositivo. Le sandbox come Microsoft Execution Container offrono un accesso governato dalle policy alle risorse necessarie al compito e creano un confine di applicazione in cui controlli e osservabilità operano fuori dalla portata dell’agente. Se l’agente o il software che lo coordina vengono compromessi, non devono poter disattivare i controlli che li sorvegliano.

Il secondo livello è lo spazio di azione. Un agente non deve essere libero di chiamare qualunque strumento, API, server MCP, risorsa o altro agente riesca a trovare; i controlli locali, di rete e sui dati devono mediare questi percorsi, osservare le chiamate e applicare le policy aziendali. Controllare solo la destinazione non basta. La sicurezza deve capire anche il contenuto che entra ed esce dall’agente, con la sua sensibilità, la sua provenienza e l’eventualità che dati non attendibili ne stiano influenzando il comportamento.

Il terzo livello sono i permessi, e il punto di partenza sono gli zero standing permissions. Dopo decenni di Zero Trust e least privilege applicati alle persone, per gli agenti questi princìpi diventano ancora più importanti. Un agente non deve ereditare in automatico tutto l’accesso permanente del suo utente, deve cominciare senza alcuna autorità e ricevere solo ciò che serve al compito approvato, per il tempo necessario.

Per rendere possibile tutto ciò Microsoft introduce Dynamic Permissions. La policy a livello di organizzazione fissa il confine esterno, compreso il divieto per un agente di ottenere un’autorità che il suo utente non possiede. I permessi possono poi essere ridotti o rimossi quando il compito cambia o si conclude, e per le azioni a maggiore impatto può essere richiesta un’approvazione umana verificata.

Un rischio che cambia insieme all’agente

Il least privilege riduce l’esposizione senza eliminare il rischio. L’agente delle note spese può iniziare con gli accessi giusti e imbattersi poi in una prompt injection in un documento esterno. La sua configurazione non è cambiata, il suo comportamento e il suo rischio sì. Per una persona, un ritardo tra rilevamento e risposta può essere gestibile, mentre per un agente che opera a velocità di macchina può fare la differenza tra contenimento e impatto. Il sistema di sicurezza deve capire che cosa è cambiato e agire prima che una persona riesca a indagare manualmente ogni segnale. Per questo Microsoft introduce Dynamic Agent Risk e Dynamic Conditional Access per gli agenti.

Dynamic Agent Risk combina segnali di identità, dati, endpoint, cloud, rete, runtime e attività dell’agente stesso, valuta quanto l’agente sia configurato in modo sicuro, quali risorse possa raggiungere, quale impatto potrebbe avere un incidente e se le sue azioni si stiano allontanando dall’intento dell’utente o dell’organizzazione. Il risultato è un quadro del rischio aggiornato di continuo, e della corrispondenza tra l’autorità attuale dell’agente e quel rischio. La domanda diventa che cosa l’agente possa leggere, modificare, invocare o approvare in quel momento, oltre a se debba continuare a funzionare.

Dynamic Conditional Access estende Entra Conditional Access agli agenti, in modo che una variazione di rischio inneschi azioni coordinate su più punti di applicazione. La risposta è graduata: la policy può ridurre i permessi, mantenere le letture bloccando le scritture, restringere dati e risorse raggiungibili, limitare i percorsi di rete, accorciare o revocare gli accessi a tempo oppure richiedere un’approvazione umana dimostrabile prima di un’azione rilevante. Ai livelli di rischio più alti può isolare il runtime o fermare del tutto l’esecuzione.

Nel caso dell’agente delle note spese, l’incontro con contenuti non attendibili e il tentativo di un’azione estranea fanno salire il suo Dynamic Agent Risk. La policy gli toglie la possibilità di approvare o scrivere lasciandogli l’accesso in lettura, blocca le risorse sensibili e richiede un’approvazione umana crittograficamente dimostrabile per il passaggio ad alto impatto. Il dipendente resta produttivo e l’agente viene vincolato, senza trattare ogni variazione di rischio come un evento da kill switch.

Guardian Agents e contenimento del modello

Con migliaia o centinaia di migliaia di agenti in azienda, il triage manuale di ogni alert e il coordinamento manuale di ogni risposta non reggono. Per Microsoft la sicurezza degli agenti deve diventare a sua volta agentica, restando dentro i confini stabiliti dalle persone. Arrivano per questo nuovi Playbook e un team di Guardian Agents in Project Perception. I Playbook stabiliscono il risultato di sicurezza desiderato e coordinano le azioni di protezione, mentre i Guardian Agents svolgono il lavoro adattandosi ai cambiamenti nell’attività degli agenti, nel rischio, nel contesto di sicurezza e nella policy aziendale. Possono aiutare i team a capire perché il rischio è cambiato, a indagare le evidenze rilevanti, a raccomandare o applicare il contenimento e a usare ciò che imparano per rafforzare le policy. Il giudizio non viene delegato, perché le persone mantengono il controllo su obiettivi, regole di delega e decisioni rilevanti.

Il passo successivo, secondo Microsoft, è ottenere prove più profonde sul modello stesso. Nel saggio Models as Insider Risks in the Super Intelligence Era Nadella scrive che la trasparenza della chain-of-thought e la verifica di un modello da parte di un altro possono essere utili ma non bastano, perché un modello opaco che ne osserva un altro può lasciare scatole nere annidate. Microsoft costruisce la propria strategia su questo approccio, stabilendo che sistemi indipendenti devono osservare ogni livello, modello compreso, e stabilire e far rispettare ciò che il sistema può fare.