Dove si osserva davvero l’attività di un agente

In Microsoft 365 admin center, sotto Agents > All agents, ogni agente ha un pannello di dettaglio con più schede, due delle quali riguardano l’osservazione. La scheda Security è quella che, testualmente, “helps you monitor agent activity, protect sensitive data, and evaluate compliance gaps based on Microsoft Purview protections”: raccoglie cioè i tre sotto-obiettivi di questa unità. La scheda Activity dà invece i numeri di un singolo agente sul tenant: Active users, Sessions, Exceptions (le sessioni chiuse con errore) e Agent run-time, con finestra predefinita di 30 giorni. Entrambe le schede, e la colonna Risks nell’Agent Registry, richiedono una licenza Microsoft E7 oppure Agent 365: senza, semplicemente non compaiono.

Il dato grezzo arriva dall’observability di Microsoft Agent 365, che raccoglie i dati di runtime degli agenti: esecuzioni, uso dei tool, chiamate al modello, tempi, stato ed errori. Due dettagli da fissare. Il primo: gli agenti costruiti su Microsoft Foundry, Microsoft Copilot Studio e Agent Builder inviano questi dati automaticamente quando l’organizzazione ha un trial o una licenza Agent 365, mentre per gli agenti custom o di terze parti è lo sviluppatore che deve integrare esplicitamente l’observability. Il secondo: Agent 365 conserva gli observability data per 30 giorni, poi li elimina automaticamente.

L’unità di lettura più fine è la sessione, cioè un’istanza completa di attività innescata da un trigger, come una mail, una chat o una @mention. Di ogni sessione si leggono i campi Trigger, Action or tool call, Thought process, Title, AI-generated summary, Status (Running, Completed, Failed), Channel link e Start. In Microsoft Defender l’amministratore Microsoft 365 monitora tutti gli agenti Agent 365; nella vista All agents di Microsoft 365 Copilot e nella scheda Activity in Teams vede solo chi interagisce con l’agente o è agent manager in Microsoft Entra. Dal lato Purview, la voce Monitor agent activity della scheda Security rimanda all’Activity explorer.

Le protezioni di Purview non si estendono da sole all’agente

Tieni separati i tre oggetti che qui si confondono: Agent 365 è la suite di gestione e governance, Microsoft Entra Agent ID è l’identità dell’agente in directory, l’agent registry è il catalogo-inventario degli agenti dentro l’admin center. Le policy di Purview si applicano all’agent instance, cioè all’oggetto identitario, non alla voce di catalogo.

Quando crei un’agent instance per Agent 365, tre cose scattano da sole: audit, rilevamento dei dati sensibili tramite data classification e inclusione nelle Assessments for AI regulations di Compliance Manager. Per tutto il resto vale la frase che l’esame può usare come discriminante: “For other capabilities, include the agent instance in policies as you would a user”. Non è automatico: l’istanza va messa nello scope come metteresti una persona.

Nel concreto, per Data loss prevention l’agent instance va specificata esplicitamente nella policy DLP, oppure inclusa tramite un security group che la contiene; e siccome l’agente non è consapevole dell’azione di blocco, l’owner deve monitorare attivamente quella policy e capirne l’impatto sui passi successivi del flusso. Per le sensitivity label ci sono due trappole: perché un’istanza acceda a un file, quel file deve esserle condiviso esplicitamente, e se l’etichetta applica crittografia deve concedere all’istanza i diritti d’uso VIEW ed EXTRACT — una label configurata con Add all users and groups in your organization non è sufficiente. Inoltre i contenuti nuovi prodotti da Agent 365 non ereditano l’etichetta dagli elementi di origine, quindi non risultano automaticamente etichettati né crittografati. Stessa logica di inclusione esplicita per Insider Risk Management, con il template Risky AI usage, mentre eDiscovery, Communication compliance e Data lifecycle management trattano l’istanza come un utente. Una capacità invece non è supportata: Encryption without sensitivity labels.

La vetrina è DSPM > AI observability nel portale Microsoft Purview: mostra gli agenti con attività negli ultimi 30 giorni, ordinati per livello di rischio determinato da Insider Risk Management, con le attività rischiose — oversharing, exfiltration, unethical behavior — e le raccomandazioni di remediation. Osserva e suggerisce: a bloccare o a trattenere sono DLP e retention, non DSPM.

Valutare i gap di conformità

La terza voce della scheda Security, Evaluate compliance gaps, è condizionata: se per l’agente selezionato è disponibile un AI baseline assessment, puoi valutarne i gap di conformità, e il percorso porta a Microsoft Purview Compliance Manager. Compliance Manager lavora con assessments, cioè raggruppamenti di controls presi da una normativa o uno standard, con improvement actions corredate di guida passo passo e con un compliance score basato sul rischio. Distingue inoltre Microsoft managed controls, Your controls e Shared controls.

Il punto da non sbagliare: Compliance Manager valuta e assegna punteggi, non applica nulla. Chiude il gap la policy che vai a creare — un’etichetta, una DLP, una retention — non l’assessment che te lo ha mostrato.

Che cosa ti chiede l’esame

AB-650 è in beta e la soglia di superamento è 700. Su questo punto lo scenario tipico è: un agente ha letto un documento riservato, perché la policy non ha reagito? La risposta quasi sempre è che l’agent instance non era nello scope della policy, perché fuori da audit, data classification e assessment normativi nulla si estende automaticamente. Le altre due discriminanti: le schede Activity e Security in admin center raccontano uso e postura del singolo agente, Activity explorer e AI observability in Purview raccontano le attività sui dati; e l’osservabilità di Agent 365 conserva i dati 30 giorni, un orizzonte diverso da quello di una retention policy di Purview.