Governance e sicurezza rispondono a due domande diverse
La sicurezza risponde a “questa chiamata può passare?” e agisce sul singolo accesso: identità, permessi sul dato, rete, filtri sui contenuti. La governance risponde a una domanda precedente: chi ha il diritto di costruire un agente, dove può costruirlo, con quali connettori e conoscenze, e chi può autorizzarne la pubblicazione. Un agente può essere perfettamente sicuro e comunque ingovernato, perché nessuno ha deciso che dovesse esistere. L’esame tiene i due piani separati e formula le domande in modo che il candidato scelga il meccanismo giusto: se lo scenario dice “impedire che il maker pubblichi”, la risposta sta nella governance, non in un controllo di runtime.
Le tre superfici di costruzione hanno tre piani di governo distinti, e vanno mappate correttamente. Gli agenti low-code di Microsoft Copilot Studio si governano dal Power Platform admin center; gli agenti di Microsoft 365 Copilot e la loro estensibilità si governano dal Microsoft 365 admin center; i modelli, i Foundry Tools e il Microsoft Foundry Agents service si governano con Azure Policy e con il Microsoft Foundry Control Plane. Progettare “una” governance per l’organizzazione significa scrivere requisiti unici e poi assegnarli al piano che li può davvero applicare, perché nessuno dei tre copre gli altri due.
Il perimetro di costruzione: ambienti, ambienti gestiti, gruppi
In Power Platform il contenitore della governance è l’environment. Le capability premium si attivano con i Managed Environments, che includono fra l’altro limit sharing, weekly usage insights, data policies, pipelines, maker welcome content, solution checker, IP firewall e Customer Managed Key. Solo gli ambienti gestiti possono entrare in un environment group, e ogni ambiente appartiene a un gruppo solo: i gruppi non si annidano e non si sovrappongono.
Il punto architetturale sta nelle rules del gruppo. Quando una regola viene pubblicata, l’impostazione corrispondente diventa di sola lettura nei singoli ambienti e un system administrator locale non può più modificarla; solo un tenant administrator interviene, a livello di gruppo. Non esistono eccezioni per singolo ambiente. Rimuovendo un ambiente dal gruppo, questo conserva l’ultima configurazione applicata ma torna sbloccato. Con il default environment routing si può indirizzare la creazione degli ambienti personali dei maker direttamente dentro un gruppo, così che nascano già governati.
Scenario tipico: un gruppo bancario con quaranta business unit chiede che nessun amministratore locale possa allentare le regole sugli agenti in produzione. La risposta non è una data policy, che è configurabile altrove, ma una regola pubblicata a livello di environment group che blocca l’impostazione. Confusione da evitare: questo è l’ALM di Power Platform (solution, environment, pipeline), non il ciclo di vita di un deployment in Foundry.
Policy sui connettori: bloccare, filtrare o consentire per elenco
Le data policies classiche classificano i connettori in Business, Non-business e Blocked, e impediscono che dati passino fra gruppi diversi. Copilot Studio espone come connettori anche capacità che non sono API: bloccando Chat without Microsoft Entra ID authentication in Copilot Studio si impedisce di pubblicare agenti senza autenticazione; Knowledge source with SharePoint and OneDrive in Copilot Studio governa le knowledge source; Skills with Copilot Studio blocca le skill; il connettore Microsoft Copilot Studio governa gli event trigger, quindi gli agenti autonomi; i connettori di canale governano dove l’agente può essere pubblicato. L’applicazione è in tempo reale e il pulsante di pubblicazione diventa indisponibile. Bloccare i connettori Power Platform blocca anche gli strumenti dei server MCP collegati, perché passano dagli stessi connettori: dettagli in learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention.
Le advanced connector policies cambiano la postura: allowlist stretta, tutto bloccato per default, controllo a livello di singola azione e trigger, enforcement anche in fase di authoring. Coprono però solo i connettori certificati; custom connector e HTTP restano alle data policies classiche, insieme all’endpoint filtering quando il requisito è “questo sito SharePoint sì, quell’altro no”. La modalità mixed mode è quella predefinita e applica l’impostazione più restrittiva delle due; ACP-only mode si adotta a migrazione finita. Sui server MCP il blocco è a livello di server, non di singolo tool.
Sul lato Foundry, la leva equivalente è Azure Policy: le definizioni built-in Foundry model deployments should only use approved models e Foundry model deployments should meet eligibility requirements sono generalmente disponibili, valutano al momento del deployment e possono essere assegnate in effetto Audit prima che in Deny. Le policy dedicate al model router sono in public preview, così come il routing degli strumenti MCP attraverso un AI gateway.
Approvazione, catalogo e responsabilità nel tempo
Decidere chi può pubblicare è la parte finale. In Copilot Studio le sharing limits, controllo dei Managed Environments, distinguono i ruoli Editor e Viewer: l’Editor si assegna solo a singoli utenti, mai a gruppi di sicurezza, e opzioni come Only share with individuals (no security groups) o il limite massimo di viewer si applicano soltanto agli agenti che richiedono autenticazione. Nel Microsoft 365 admin center gli agenti passano invece da Agent Registry e dalle agent request, dove un amministratore approva la pubblicazione nell’Agent Store oppure la rifiuta.
L’inventario non è approvazione: il Copilot Studio agent inventory, la cui documentazione è marcata preview, elenca gli agenti pubblicati e in bozza e i loro connettori, ma dice che cosa esiste, non che cosa è lecito. Il ciclo di vita definito per un Center of Excellence, con le fasi Intake, Triage, Build, Deploy, Monitor, Improve e Retire, chiede un proprietario nominato prima della messa in produzione. È lì che governance e rischio si toccano: senza owner e senza cadenza di revisione, l’agente non viene bloccato da nulla, semplicemente deriva.