Se governi gli agenti come governi le app, sbagli bersaglio. In Microsoft Entra un agente può presentarsi con tre soggetti diversi, e l’accesso condizionale valuta il soggetto che chiede il token — non «l’agente» in astratto.

Tre soggetti, non uno

Nel flusso on-behalf-of l’agente scende a valle con l’identità dell’utente: il soggetto è l’utente, quindi la policy si scrive su utenti e gruppi, non sull’identità agente. Nel flusso client credentials l’agente autonomo usa la propria agent identity, e lì la policy va scritta su quella. Il terzo caso è l’agent’s user account, un account utente vero con casella e licenze, associato 1:1 all’identità agente: non la sostituisce, si aggiunge.

Da qui discendono i limiti che è facile scoprire in produzione:

  • una policy che punta alle identità agente non si applica all’agent’s user account, e viceversa;
  • una policy su All users non include gli agent’s user account;
  • non puoi includerli o escluderli per appartenenza a gruppo;
  • non si applica quando un blueprint chiede un token per creare identità, né sull’endpoint interno di token exchange, né se i security defaults sono attivi;
  • e non si applica se l’agente usa una API key: fuori dalla pipeline di token di Entra, l’accesso condizionale non esiste.

Licenze: Entra ID P1 o P2 più una licenza Microsoft Agent 365 per utente; i controlli di rete per agenti richiedono Microsoft Entra Internet Access.

Scrivere le policy senza inseguire ogni agente

Ogni identità agente deriva da un agent identity blueprint. Puntare la policy al blueprint copre tutte le identità che ne discendono, comprese quelle future — ma non gli agent’s user account. Oltre il blueprint ci sono i custom security attributes: etichetti le identità e la policy segue l’attributo, non l’oggetto.

Esiste la condizione agent risk (alto, medio, basso), alimentata da ID Protection, che in anteprima richiede Entra ID P2. Confermare un agente come compromesso porta il rischio a High: se hai una policy che blocca su High Agent Risk, il blocco scatta da solo.

I tre blocchi tipici, da provare prima in report-only, si costruiscono in Conditional Access > Policies includendo All agent identities, All agents acting as users, oppure All users verso All agent resources — l’ultimo impedisce alle persone di far agire gli agenti per loro conto, lasciando vivi i flussi autonomi e agent-to-agent. Attenzione: bloccare tutto in un colpo fa fallire esperienze Microsoft che presuppongono le identità agente e spinge i team su service principal classici, cioè identità meno tracciabili.

Gestire l’accesso: chi possiede l’agente e chi può chiamarlo

L’inventario vive in Entra ID > Agents > Agent identities e Agent blueprints. Vedere non richiede ruoli; gestire sì: Agent ID Administrator o Cloud Application Administrator per le identità, Agent ID Developer per creare blueprint.

Chi può invocare un agente si decide con gli app role e con appRoleAssignmentRequired sul blueprint. Il default è la trappola: se è false, qualunque principal autenticato raggiunge l’agente. Portala a true sui blueprint sensibili e assegna i ruoli esplicitamente, a utenti o ad altre identità agente. Se poi un agente non accede a un’app, quasi sempre manca un appRoleAssignment.

Le inheritable permissions sul blueprint fanno ereditare scope delegati alle identità figlie senza prompt di consenso: parti dagli enumerated scopes (massimo 10 resource app, 40 scope ciascuna) e allarga dopo. Ogni agente dovrebbe avere uno sponsor umano; se lo sponsor lascia l’azienda, la sponsorship passa automaticamente al suo manager. Per monitorare: Sign-in logs, filtri Agent type e Is Agent. Nei log di audit la creazione di un’identità agente compare come Create service principal, quella di un agent’s user account come Create user.

Raggio d’azione: che cosa si può dire davvero

«Blast radius» significa una cosa sola: se questo agente viene compromesso, fin dove arriva. Permessi ereditati, strumenti invocabili, dati raggiungibili e — specificità agentica — la propagazione verso altri agenti, perché un orchestratore compromesso può usarne altri.

Qui serve onestà: Microsoft non pubblica una pagina citabile su un’analisi di blast radius in Defender XDR, quindi non aspettarti un nome di menu da memorizzare. Documentata è invece la posture risk degli agenti (in anteprima): ogni agente riceve un livello complessivo — High, Medium, Low, No known risk, Not evaluated — combinando indicatori di rischio come Privileged Business-system Access, Indirect Prompt Injection Exposure, High-usage Agent o Active Threat. Sono i fattori con cui si ragiona sul raggio d’azione. Un indicatore però non è per forza rimediabile: può descrivere lo scopo previsto dell’agente. E le raccomandazioni nascono separatamente dal livello di rischio: vanno lette insieme.

Il registro degli agenti nel centro di amministrazione Microsoft 365

Il piano di controllo lato Microsoft 365 è Agents > All Agents > Registry: quattro tipi (Microsoft, partner esterni, pubblicati dall’organizzazione, condivisi dal creatore) e tre contatori che valgono la visita — Total agents, Agents without owners e Unmanaged agents, creati fuori da Agent 365. Filtri per Status, Publisher type, Channel, Platform e Data source; export, upload di un pacchetto ZIP, pinning (massimo tre agenti).

Due avvertenze. La colonna Risks aggrega segnali da Entra, Defender e Purview ma mostra solo le severità alte: zero non significa nessun rischio, e c’è fino a un’ora di ritardo rispetto ai portali di sicurezza. E il link Review obbedisce ai ruoli veri: AI Administrator non apre Defender né Purview, Security Reader apre Defender ed Entra ma non Purview, e per gli avvisi Purview serve un ruolo Insider Risk Management.