L’agente è un principal, non una funzionalità
In Microsoft Foundry un agente non prende in prestito l’identità di chi lo ha scritto: ne riceve una propria. Un agent identity è un service principal specializzato in Microsoft Entra ID, creato a partire da un agent identity blueprint, l’oggetto che governa un’intera classe di agenti e su cui si applicano Conditional Access, revoche e audit di massa. Alla creazione del primo agente in un progetto, il Microsoft Foundry Agents service provisiona automaticamente un blueprint e un’identità predefiniti.
Il dettaglio che decide gli scenari d’esame è la differenza fra identità condivisa e identità distinta. Gli agenti non pubblicati di un progetto condividono la stessa agent identity; la pubblicazione di un agente ne crea invece una dedicata, legata alla agent application resource. Il nuovo agentIdentityId è un principal diverso, e le assegnazioni di ruolo fatte sull’identità condivisa non si trasferiscono: vanno rifatte. Come architetto lo leggi al contrario: l’identità condivisa di progetto ha un raggio d’azione più ampio, quindi quando un agente richiede controlli più stretti o una pista di audit separata, la risposta di progetto è pubblicarlo per staccarlo dal pool comune, non aggiungere permessi al pool.
Il blueprint si autentica a Entra ID con client secret, certificato oppure federated credential appoggiata a una managed identity — quest’ultima raccomandata in produzione perché elimina il segreto memorizzato. Attenzione a non confondere i due livelli: la managed identity autentica il blueprint, non accede alla risorsa a valle. Il principal che deve comparire nelle assegnazioni RBAC sullo storage account, sul Cosmos DB o sul Key Vault è l’agent identity. Un secondo errore ricorrente è l’audience: se il valore non corrisponde all’identificatore della risorsa di destinazione (per esempio https://storage.azure.com), la chiamata fallisce anche con i ruoli corretti.
Attended o unattended: la domanda che decide i permessi
Prima di assegnare un solo ruolo, stabilisci se l’agente opera con una persona davanti. Nel flusso attended (delegated access, on-behalf-of) l’utente si autentica all’applicazione e il token viene scambiato con uno che porta insieme l’agent identity e i permessi delegati dell’utente: l’agente può toccare solo ciò a cui quell’utente è già autorizzato. Nel flusso unattended (application-only, client credentials) non c’è nessun utente, e l’accesso è governato interamente dalle assegnazioni RBAC o dai permessi applicativi Microsoft Graph dell’agente.
Da qui discende la regola che l’unità sintetizza: i permessi di un agente autonomo non possono essere quelli del suo autore. In Microsoft Copilot Studio la stessa scelta si materializza nel campo Authentication di ogni tool, fra End user credentials e Maker-provided credentials; i tool girano sempre nel runtime dell’agente in contesto utente e non funzionano se l’autenticazione non è abilitata. Le credenziali del maker sono legittime per risorse condivise, ma se un agente autonomo notturno riconcilia partite contabili e il maker è un amministratore dell’ambiente, quell’agente ha ereditato un privilegio che nessuno ha mai deliberato. Il vincolo architetturale corretto è un principal dedicato con il minimo indispensabile — sola lettura se all’agente basta leggere.
Sul lato piattaforma esistono controlli che tolgono la scelta al maker. Il controllo Authentication for agents nel Power Platform admin center (in preview) impone a livello di ambiente o di gruppo di ambienti una fra No authentication (Publicly available), Require Microsoft authentication, Require Entra authentication e Allow all supported authentication methods. Nell’estensibilità di Microsoft 365 Copilot la superficie è ancora diversa: gli schemi supportati per plugin MCP e API plugin sono Microsoft Entra single sign-on, dynamic client registration (solo MCP), OAuth 2.0 authorization code, API key (solo API plugin) e no authentication, con le credenziali custodite in una authentication configuration.
Isolamento di rete: una scelta che non si ripete
Senza configurazione, un Foundry resource nasce pubblico su entrambi i lati. Il modello di egress è la decisione primaria e determina le opzioni di ingresso: public egress, BYO virtual network o managed virtual network. Con BYO virtual network servono una subnet dedicata e delegata a Microsoft.App/environments, spazio di indirizzamento RFC 1918, private endpoint e Private DNS zone per l’account e per ogni data resource, e la stessa region fra virtual network e Foundry resource. La subnet minima è /27, con /24 consigliato in produzione quando usi hosted agents, perché ogni hosted agent consuma un indirizzo IP mentre i prompt agents attingono a un pool statico.
Il vincolo che trasforma questa in una decisione da architetto e non da operatore: la network injection fa parte del flusso di creazione della risorsa, non si aggiunge a un account esistente e non si cambia dopo. Per spostarsi su un’altra configurazione servono nuovi progetti. Verifica inoltre che i tool previsti supportino l’isolamento di rete, perché alcuni non lo supportano o raggiungono comunque la destinazione via internet pubblico.
Che cosa verifica l’esame
Le domande su questo obiettivo mettono quasi sempre in tensione comodità e privilegio minimo, e la risposta giusta è quella che separa le identità. Tieni distinti quattro piani che il testo delle domande mescola apposta: security (chi è il principal e che cosa può fare), governance (inventario, ownership, policy), responsible AI (danno del contenuto prodotto) e compliance. Non confondere il flusso attended con quello unattended, né la managed identity del blueprint con l’agent identity che riceve i ruoli. Ricorda infine che i ruoli Foundry sono stati rinominati in Foundry User, Foundry Owner, Foundry Account Owner e Foundry Project Manager: gli ID delle definizioni non cambiano, ma nella documentazione e nel portale possono ancora comparire i nomi precedenti.