Il punto cieco della governance AI: gli agenti che Entra non vede
Negli ultimi mesi ogni organizzazione con un tenant Microsoft 365 è passata da “come possiamo sfruttare l’AI” a “come possiamo controllarla”. Microsoft ha risposto irrobustendo l’integrazione degli agenti con Entra Agent ID e Copilot Studio, e anche fornitori terzi come Anthropic si stanno muovendo nella stessa direzione con connettori applicativi per M365. Il problema è che molti agenti AI sono già entrati nel tenant prima che questi meccanismi esistessero, e alcuni percorsi permettono tuttora a un’AI “non autorizzata” di operare senza lasciare traccia evidente.
Il rischio più concreto non sono gli agenti registrati e visibili in Entra, ma quelli che operano nascosti dietro identità utente legittime e dispositivi considerati attendibili. Prima di investire in controlli specifici per l’AI, vale la pena sistemare l’igiene dell’identità e la visibilità sugli endpoint. Vediamo tre scenari concreti in cui un agente AI può sfuggire al controllo, come rilevarli e come prevenirli.
Scenario 1 — Il consenso utente come porta d’accesso più semplice
Microsoft ha investito molto nell’irrobustire il flusso di consenso, imponendo il consenso amministrativo per i permessi più pericolosi. Di default esiste una deny list che copre principalmente gli scope di lettura-scrittura più sensibili, ma gli utenti possono ancora acconsentire autonomamente a scope in sola lettura come User.Read, openid, profile ed email.
Lo scope consentibile dall’utente più pericoloso per un agente AI è offline_access: consegna all’agente un refresh token, ovvero accesso persistente in background, anche quando l’utente non è più connesso.
Il punto a favore dei difensori è che questo percorso registra comunque un service principal individuabile e un record di consenso: c’è quindi una traccia da controllare.
Come rilevarlo
- Rivedi periodicamente l’application consent history del tenant
- Analizza gli end-user consent log per individuare consensi anomali o non richiesti dall’IT
Come prevenirlo
La mitigazione è semplice quanto efficace: disabilita completamente il consenso utente e instrada ogni richiesta di permesso attraverso l’admin consent workflow. In Entra questo si configura da Enterprise Applications > Consent and permissions > User consent settings, impostando “Do not allow user consent”.
Scenario 2 — Token senza alcuna impronta in Entra
Il secondo percorso è ancora più insidioso: un flusso guidato dall’utente che produce direttamente un token, senza passare da un vero consenso applicativo. In pratica, l’utente fornisce all’agente username e password (o un flusso equivalente), e l’agente si maschera dietro un’applicazione Microsoft first-party già fidata. In questo caso non viene creato alcun service principal né alcun record di consenso: Entra registra semplicemente un normale login utente.
Esistono diverse varianti di questo pattern, ognuna con la propria contromisura:
- OAuth 2.0 Resource Owner Password Credentials (ROPC): un flusso legacy a singolo fattore. La difesa è imporre MFA sempre, su tutto, senza eccezioni.
- Device Code Flow: si blocca con una semplice policy di Conditional Access dedicata.
- Family of Client IDs (FOCI): un token emesso per un’applicazione della “famiglia” è riutilizzabile su tutte le altre applicazioni della stessa famiglia, e non esiste un interruttore per disabilitare questo comportamento. Il Conditional Access per singola app viene quindi aggirato banalmente: la mitigazione si sposta sul rilevamento, revocando i token in caso di sospetto abuso e affidandosi alla Continuous Access Evaluation, pur sapendo che la sua copertura non è universale.
Scenario 3 — Dispositivi attendibili: dove i controlli identity smettono di aiutare
Lo scenario più complesso è quello di una postazione dedicata all’AI: il classico Mac Mini nuovo di zecca comparso in una nota spese. Il dipendente lo unisce al tenant tramite hybrid join o come dispositivo conforme, e una volta effettuato il join ottiene un Primary Refresh Token (PRT) legato al TPM. L’agente gira come quell’utente e richiede silenziosamente token al Web Account Manager (WAM) broker, ottenendo una connessione persistente e sempre attiva.
Questo è il caso più difficile da chiudere: l’agente supera ogni verifica di Conditional Access perché, di fatto, è l’utente, su un dispositivo fidato. Il Token Protection lega i token al dispositivo, ma non riesce a distinguere “l’utente” da “un processo agente che gira come l’utente” sulla stessa macchina.
Prevenzione e rilevamento
La prevenzione parte dal non permettere agli utenti di unire autonomamente i propri dispositivi al tenant, supportata da policy di Conditional Access rigorose sulla compliance. Il rilevamento deve invece spostarsi sull’endpoint:
- Advanced hunting in Microsoft Defender for Endpoint su
DeviceProcessEvents(flag per browser headless, processi figli inattesi) - Analisi di
DeviceNetworkEvents(un processo locale che contatta una API AI esterna) - Blocco delle app non autorizzate tramite Defender for Cloud Apps
Le fondamenta contano più dei controlli AI-specifici
Il messaggio centrale è che l’igiene dell’identità, per quanto “vecchia” come disciplina, chiude già la maggior parte di questi scenari:
- Impostare il consenso utente su Do not allow user consent
- Abilitare l’admin consent workflow
- Imporre MFA ovunque, sempre, tramite Conditional Access
- Bloccare il device-code flow con una policy dedicata
- Limitare la possibilità per gli utenti di unire dispositivi a Entra
- Imporre la compliance dei dispositivi via Conditional Access
La configurazione di base, però, non copre tutto: ciò che non può essere mitigato deve essere rilevato, il che significa spostare parte dell’attenzione dal piano identità a quello del dispositivo. E il Purview Data Security Posture Management (DSPM) for AI? È uno strumento genuinamente utile, ma va inquadrato correttamente: offre visibilità, non enforcement. DLP e Insider Risk vanno comunque configurati manualmente, il monitoraggio delle AI di terze parti si appoggia agli stessi endpoint ed estensioni browser già citati, le funzionalità più ricche richiedono licenze premium, e la protezione basata su etichette è cieca sui dati non etichettati. Va trattato come una rete di sicurezza aggiuntiva, non come la prima linea di difesa.
Conclusione
Se la strategia di sicurezza di un’organizzazione si basa sull’identificare gli agenti registrati in Entra, ha già perso di vista la categoria di rischio più insidiosa: quella degli agenti che operano mascherati da utenti normali. La lezione pratica per chi amministra un tenant Microsoft 365 è partire dalle basi già note — consenso, MFA, Conditional Access, compliance dei dispositivi — prima di rincorrere soluzioni AI-specifiche, e progettare i controlli assumendo che alcuni agenti stiano già operando sotto mentite spoglie di un utente reale.
Fonte: Petri IT Knowledgebase – The Agents Entra Can’t See: Detecting and Preventing Rogue AI