Riusare i permessi dell’origine invece di copiarli

Un agente che risponde su documenti aziendali eredita un problema più vecchio dell’AI: chi ha diritto di leggere che cosa. La tentazione, costruendo un indice di grounding data, è ricopiare i permessi dentro l’indice come stringhe e filtrarli a runtime. Azure AI Search chiama questo pattern security filters: un campo stringa contiene l’identità di utente o gruppo, la query passa la stessa stringa come filtro, i documenti che non corrispondono spariscono. È generalmente disponibile e indipendente dalla versione API, quindi resta la scelta obbligata con sistemi di identità custom o non Microsoft — ma è confronto fra stringhe, non autorizzazione.

Le altre tre strade riusano l’origine: POSIX-like ACL / RBAC scopes per Azure Data Lake Storage Gen2 e Azure Blob Storage, le Microsoft Purview sensitivity labels, le SharePoint in Microsoft 365 ACLs. Tutte e tre sono in preview e condividono lo stesso meccanismo a query time: il chiamante allega il proprio token Microsoft Entra nell’header x-ms-query-source-authorization e il servizio confronta le claim con i metadati di permesso sincronizzati sui documenti. La documentazione motiva la preferenza in modo esplicito, dicendo che questo approccio “reduces identity duplication and the operational overhead of maintaining a parallel permission store”.

Il criterio architetturale che ne discende è netto: un permesso duplicato è un permesso che invecchia. Va però progettato il rovescio della medaglia. L’applicazione non è istantanea: un cambio di appartenenza a un gruppo si riflette nei risultati solo dopo che il meccanismo di sincronizzazione previsto dalla fonte — una nuova esecuzione dell’indexer, un aggiornamento via push API, un refresh guidato da Purview — ha riscritto i metadati nell’indice. Se il vincolo del cliente è “la revoca deve avere effetto entro il turno”, quel ritardo è un requisito di design, non una sorpresa operativa.

Sopra questo strato, Foundry IQ espone knowledge base e knowledge source riusabili con retrieval permission-aware ed esecuzione delle query sotto l’identità Entra del chiamante; alcune funzionalità sono ormai GA, altre restano in preview a seconda della versione REST del servizio di ricerca. Sul versante Microsoft 365, gli agents in SharePoint non allargano mai l’accesso: le risposte dipendono dai permessi del singolo utente sulle fonti, mentre i permessi del file .agent decidono soltanto chi può usare o modificare l’agente. Per stringere esistono restricted access control e restricted content discovery, che lascia intatto l’accesso al sito ma toglie il contenuto dalle superfici Copilot e dalla ricerca organizzativa.

Chi può toccare i modelli, i deployment e il tuning

In Microsoft Foundry il controllo d’accesso non riguarda i documenti ma le risorse. I ruoli built-in sono Foundry Agent Consumer (solo interagire con gli endpoint di un agente), Foundry User, Foundry Project Manager, Foundry Account Owner e Foundry Owner. Gli scope sono tre — Foundry resource, Foundry project e il singolo agent — e l’ultimo oggi viene valutato solo per l’accesso agli endpoint: serve ad aprire un agente a un consumatore senza aprire tutti gli altri del progetto. Parte della documentazione vive ancora sotto /azure/ai-foundry/ e usa i nomi precedenti dei ruoli: sono gli stessi ruoli rinominati, non prodotti diversi.

Il punto che l’esame ama è che il fine-tuning attraversa il confine fra data plane e control plane. Addestrare è data plane, distribuire il modello risultante è control plane, e l’unico ruolo built-in che possiede entrambi è Foundry Owner; in alternativa si combinano Foundry User per il data plane e Foundry Account Owner per il control plane. Chi progetta la separazione dei compiti deve scegliere consapevolmente fra un ruolo molto ampio e due assegnazioni distinte. Vincolo tipico da scenario: il dataset di training sta su uno storage account senza accesso pubblico — l’import da Azure Blob Storage richiede public network access abilitato, quindi restano il caricamento locale del file o l’SDK.

Quando è l’agente ad accedere ai dati, l’identità cambia natura. Microsoft Entra Agent ID introduce agent identity e agent identity blueprint, con flusso attended (on-behalf-of dell’utente, che quindi non può superare i permessi dell’utente) o unattended (client credentials, governato dai soli ruoli dell’agente). In Foundry gli agenti non pubblicati condividono l’identità del progetto; pubblicare un agente ne crea una distinta, e la documentazione elenca proprio gli agenti che “need independent audit trails” fra i casi che la richiedono. Le assegnazioni di ruolo non si ereditano: vanno rifatte sulla nuova identità.

Due audit trail che non si sostituiscono a vicenda

Qui sta la distinzione che un revisore sa fare e un progettista distratto no. In Microsoft Copilot Studio le attività amministrative — BotCreate, BotDelete, BotUpdateOperation-BotShare, BotUpdateOperation-BotPublish, BotComponentUpdate, AIPluginOperationCreate, gli eventi sulle environment variable — sono raccolte per impostazione predefinita su tutti i tenant e non si possono disattivare. L’uso dell’agente genera invece l’evento CopilotInteraction. Sono superfici diverse: la solution Audit del portale Microsoft Purview non contiene il testo delle conversazioni, ma solo il transcript thread ID, mentre è DSPM for AI che tenta di recuperare il testo di prompt e risposta insieme ai riferimenti alle risorse consultate. Chi chiede “chi ha cambiato la knowledge source e quando” vuole il primo registro; chi chiede “che cosa ha risposto l’agente a quel cliente” vuole il secondo, e nessuno dei due accetta l’altro come sostituto.

Sul dato applicativo, Dataverse auditing si configura su tre livelli — environment, table, column — con Audit changes to its data sulla tabella e Enable auditing sulla colonna, ha una propria retention e privilegi di lettura separati (View Audit History per il singolo record, View Audit Summary per l’ambiente). Non copre le operazioni di lettura ed export: per quelle serve l’activity logging, con Enable SAS Logging in Purview acceso su ogni ambiente di produzione. Per Microsoft Foundry, la cattura di prompt e risposte va abilitata esplicitamente, dal control plane di Foundry o da Microsoft Defender for Cloud; la retention si applica scegliendo la location Enterprise AI apps; e le Data Security Policies valgono solo per chiamate API con autenticazione Microsoft Entra e contesto utente — altrimenti le interazioni restano visibili in Audit e in activity explorer, ma le policy non si applicano.

Che cosa verifica l’esame

Le domande di questo obiettivo somigliano tutte a un caso: un auditor esterno chiede la prova di chi ha modificato le istruzioni di un agente negli ultimi sei mesi, oppure la revisione di ciò che l’agente ha detto agli utenti. La risposta corretta nomina la superficie giusta e la retention giusta, non “attiviamo Purview”. Tenete separati evaluation (misurare la qualità di un output), monitoring e telemetria (osservare il comportamento in esercizio) e audit trail (dimostrare a posteriori un cambiamento): sono tre registri con tre destinatari diversi. E ricordate la regola di fondo del controllo d’accesso: il progetto migliore non ricostruisce i permessi, li eredita.