Microsoft ha introdotto un framework di sicurezza che tratta gli agenti IA come una forma di rischio interno. Secondo l'azienda, le organizzazioni devono controllare identità, permessi e comportamento in fase di esecuzione in modo indipendente dai modelli stessi.
Le indicazioni di Microsoft Security pubblicate il 19 ottobre 2026 non sono la segnalazione di un incidente o di una vulnerabilità. Affrontano il rischio operativo che nasce quando gli agenti ricevono accesso a dati, strumenti e infrastrutture aziendali e possono poi agire a velocità di macchina.
Microsoft non descrive gli agenti come intrinsecamente ostili. La sua preoccupazione è che l'output di un modello possa variare, che il contesto di un'attività possa cambiare e che contenuti esterni possano manipolare un agente altrimenti legittimo. Un sistema che inizia correttamente un'attività può quindi discostarsi in seguito a causa di un errore, di una compromissione o di una prompt injection.
L'azienda chiama questo fenomeno «insider agentico»: un software che agisce con un'autorità delegata dall'organizzazione, senza però avere un comportamento completamente deterministico.
I controlli devono restare fuori dal modello
Il principio centrale di Microsoft è «circondare l'intelligenza non deterministica con controlli deterministici, prove indipendenti e confini di contenimento».
In questo modello, un agente non dovrebbe stabilire da solo i limiti della propria autorità. I meccanismi di identità, accesso e applicazione devono operare al di fuori del modello, fuori dalla sua capacità di aggirarli o modificarli.
Satya Nadella, presidente e amministratore delegato di Microsoft, ha riassunto l'approccio sostenendo che l'architettura agentica più affidabile è progettata per «fidarsi il meno possibile del modello». La distinzione pratica è tra fidarsi che un modello si comporti correttamente e costruire un sistema che limiti il danno quando questo non accade.
Microsoft organizza il framework attorno a quattro responsabilità continue:
- Conoscere: mantenere un inventario degli agenti, dei loro proprietari, dello scopo previsto e dell'attività osservata.
- Contenere: limitare dati, sistemi e azioni prima che un agente inizi a operare.
- Proteggere: mettere in sicurezza ogni componente sul percorso dell'agente, inclusi strumenti, ambienti di esecuzione e risorse aziendali.
- Adattare: rivedere le protezioni quando cambiano il comportamento, il contesto o il rischio valutato.
Non sono presentate come fasi di implementazione sequenziali. Microsoft descrive piuttosto un ciclo di feedback in cui nuove evidenze modificano il rischio, il rischio modifica la policy e la policy cambia ciò che un agente può fare.
Quando il rischio aumenta, il framework può mantenere l'accesso in lettura bloccando le scritture, ridurre le risorse disponibili all'agente, richiedere un'approvazione umana verificata per le azioni rilevanti oppure isolare e fermare l'agente.
Ogni agente ha un'identità separata
Una conseguenza immediata per i team di sicurezza è che un agente non dovrebbe operare semplicemente come estensione dell'account di un dipendente.
Microsoft afferma che ogni agente necessita di una propria identità di prima classe, distinta da quella della persona che lo sponsorizza. Questo permette ai sistemi di audit e di accesso di distinguere le azioni dirette di un dipendente dalle operazioni eseguite da un agente per conto di quel dipendente.
L'azienda dice di aggiungere il supporto alla scoperta per 35 tipi aggiuntivi di agenti locali, portando il totale a 60. Tra gli esempi figurano Claude Code, OpenAI Codex e GitHub Copilot. La scoperta è pensata per coprire agenti sviluppati da Microsoft, piattaforme e SDK di partner, nonché agenti introdotti localmente.
Microsoft afferma inoltre di estendere Microsoft Entra Agent ID con tipi di identità per altri schemi di agenti, inclusi gli agenti locali e quelli precedentemente sconosciuti rilevati dai sensori di sicurezza. Secondo l'azienda, Project Perception e Microsoft Agent 365 condividono segnali e usano un registro unificato.
Per gli amministratori, il modello proposto trasforma la scoperta degli agenti in un problema di gestione degli asset: un'organizzazione non può applicare controlli di accesso efficaci se non sa quali agenti esistono, chi ne è responsabile e cosa stanno facendo.
Sandboxing e accesso agli strumenti mediato
Microsoft raccomanda di eseguire i modelli e i relativi harness in ambienti controllati, invece di permettere loro di ereditare tutti i privilegi di un dispositivo.
Come esempio di sandbox progettata per applicare un accesso alle risorse controllato da policy, l'azienda cita Microsoft Execution Container (MXC). Il confine di applicazione dovrebbe trovarsi al di fuori dell'agente, anziché dipendere dalle istruzioni contenute nel modello.
Il framework respinge anche la scoperta illimitata degli strumenti. Un agente non dovrebbe poter invocare automaticamente ogni API, ogni server MCP, ogni risorsa di rete, ogni strumento locale o ogni altro agente che incontra. Queste connessioni dovrebbero essere mediate da controlli su rete, dispositivo e dati.
Anche l'ispezione dei contenuti fa parte del progetto. I sistemi di sicurezza dovrebbero valutare la sensibilità e l'origine delle informazioni che entrano o escono da un agente, inclusa la possibilità che materiale non attendibile stia influenzando le sue decisioni.
Microsoft illustra il rischio con un agente per l'approvazione delle note spese. Un agente del genere può avere legittimamente bisogno di leggere le richieste di rimborso, confrontarle con la policy e autorizzare i rimborsi di routine. Non gli servono tutti i permessi detenuti dal suo sponsor. Se un documento esterno contiene una prompt injection, la configurazione dell'agente potrebbe restare invariata, pur essendo cambiato il suo comportamento e, di conseguenza, il suo rischio.
Permessi che scadono con l'attività
Microsoft presenta Dynamic Permissions come un modo per non concedere a un agente alcun accesso permanente per impostazione predefinita. L'agente riceverebbe solo l'autorità necessaria per un'attività approvata e solo per la durata di quell'attività.
Una policy a livello di organizzazione definirebbe il limite massimo. In particolare, un agente non potrebbe ottenere poteri non disponibili all'utente che lo sponsorizza. I permessi potrebbero essere limitati a un'attività, scadere dopo un periodo stabilito o essere ridotti man mano che l'attività avanza. Le operazioni con impatto più elevato potrebbero richiedere un'approvazione umana verificata.
Il dipendente manterrebbe il proprio accesso, mentre l'agente avrebbe un'identità separata e permessi propri, legati all'attività. Questa separazione mira a rendere l'attribuzione delle azioni e la revoca dei permessi più precise rispetto a un agente che riutilizza le credenziali e i privilegi di una persona.
Microsoft descrive inoltre Dynamic Agent Risk come un punteggio aggiornato in modo continuo, costruito a partire da segnali di identità, endpoint, dati, cloud, rete, runtime e attività degli agenti. La valutazione considera la configurazione di sicurezza dell'agente, le risorse a cui può accedere, l'impatto probabile di un fallimento e i segnali che indicano uno scostamento delle sue azioni dall'intento dell'utente o dell'organizzazione.
Un diagramma allegato all'annuncio mostra Microsoft Sentinel, Entra, Intune, Purview, Global Secure Access e Defender che forniscono segnali per l'analisi del contesto e il calcolo del rischio in tempo reale. Microsoft collega questa valutazione a Dynamic Conditional Access, secondo cui una policy può cambiare ciò che un agente può leggere, modificare, invocare o approvare in un determinato momento.
Si tratta delle descrizioni che Microsoft fa delle proprie capacità e dell'architettura prevista, non di prove tratte da una distribuzione dimostrata in modo indipendente.
Anche l'automazione monitorerà gli agenti
Microsoft sostiene che la revisione manuale non potrà scalare quando le organizzazioni distribuiranno «migliaia o centinaia di migliaia» di agenti. La risposta proposta comprende i Guardian Agents, sistemi IA usati per supervisionare altri agenti restando però soggetti a limiti definiti dagli esseri umani.
Un rapporto di Security Affairs pubblicato il 20 ottobre 2026 afferma che i Guardian Agents possono seguire playbook creati dagli operatori, indagare sulle variazioni del rischio, raccomandare o applicare risposte e usare i risultati per affinare la policy. Gli esseri umani continuerebbero a definire gli obiettivi e ad approvare le decisioni più rilevanti.
Questo approccio lascia aperta una sfida progettuale centrale: l'applicazione dei controlli non può dipendere esclusivamente da un altro modello, il cui comportamento potrebbe a sua volta variare. La risposta dichiarata di Microsoft è mantenere i controlli decisivi fuori dai modelli, dove gli agenti non possono alterarli.
Per le organizzazioni che adottano ora gli agenti, il framework si traduce in priorità concrete: individuare gli agenti locali e quelli distribuiti centralmente, assegnare a ciascuno un'identità separata, eliminare i privilegi ereditati dagli utenti, limitare il runtime e i percorsi degli strumenti, ispezionare gli input non attendibili e richiedere approvazione umana o isolamento quando il mutare del rischio rende un'azione non sicura.
