• Cloud, Guide, Microsoft 365, Sicurezza
• 20 Ottobre 2026

Microsoft Entra Agent ID: chi potrà creare gli agenti nel nostro tenant dal 4 novembre?

In molte aziende l’intelligenza artificiale è entrata attraverso una chat. Qualche documento da riassumere, una risposta da migliorare, una ricerca da velocizzare. Poi sono arrivati i connettori, le chiamate API e gli strumenti capaci di intervenire sui sistemi.

La finestra della conversazione è rimasta quasi identica. Dietro, però, è cambiato parecchio. Un agente che aggiorna un ticket, legge una raccolta documentale o modifica una configurazione deve autenticarsi. Deve ottenere un token. E qualcuno, prima o poi, deve avergli concesso le autorizzazioni necessarie. È su questo terreno che arriva una modifica di Microsoft Entra. La comunicazione MC1506733, pubblicata il 13 ottobre 2026, annuncia che dal 4 novembre 2026 gli utenti senza ruoli amministrativi potranno creare nuovi agent identity blueprint, salvo una restrizione esplicita dell’amministratore. Il completamento della distribuzione è previsto entro la fine di novembre.

La questione merita attenzione perché riguarda la possibilità di creare oggetti dai quali possono nascere identità operative. Prima di intervenire sull’impostazione, però, conviene capire come funziona il modello e che cosa rimane fuori dal controllo di quel singolo interruttore.

Dalla conversazione all’identità

Immaginiamo un agente per l’assistenza interna. Nella prima versione consulta la documentazione e propone una risposta. Successivamente gli permettiamo di aggiornare i ticket. Infine, aggiungiamo uno strumento per intervenire sul sistema interessato.

Per l’utente potrebbe essere sempre lo stesso assistente. Dal punto di vista della sicurezza, abbiamo attraversato tre perimetri differenti. Per ricostruirli dobbiamo sapere quale identità vede la risorsa, quali autorizzazioni possiede e chi risponde del suo utilizzo. È il tema affrontato anche nell’articolo MCP sicuro in Copilot Studio: quale identità sta davvero eseguendo le azioni?.

Entra Agent ID introduce un modello dedicato per rappresentare e amministrare queste identità. Ci permette di distinguerle meglio, ma lascia all’organizzazione una decisione fondamentale: chi può crearle e con quale processo?

Blueprint, principal e identità agente

Il primo oggetto da conoscere è l’agent identity blueprint. Definisce caratteristiche condivise e configurazione di autenticazione per le identità che ne derivano.

Il blueprint principal rappresenta invece la presenza del blueprint all’interno del tenant e ne abilita le operazioni previste.

L’agent identity identifica il singolo agente. Si basa sull’infrastruttura dei service principal, con comportamenti specifici e una relazione con il blueprint padre. Può ricevere autorizzazioni proprie ed essere riconosciuta nei log.

Figure 1 – Relazione tra blueprint e agent identity. Fonte: Microsoft Learn.

L’agent user account è opzionale ed è associato a una specifica agent identity con una relazione uno a uno. Serve per scenari che richiedono funzionalità legate a un’identità utente. La sua creazione tramite Graph non attiva automaticamente una casella di posta o le altre funzionalità Microsoft 365.

In un assessment questi oggetti vanno letti insieme. L’elenco delle identità è un punto di partenza; le relazioni spiegano come vengono amministrate e utilizzate.

Figure 2 – Relazioni amministrative e identità operative. Schema concettuale, non rappresentazione del protocollo di autenticazione

Il blueprint concentra una dipendenza di sicurezza

Nel modello documentato da Microsoft, le credenziali sono configurate sul blueprint e partecipano ai flussi di autenticazione delle identità collegate. Una compromissione di quelle credenziali può coinvolgere tutte le agent identity sottostanti. Questa relazione ha un peso architetturale. Raggruppare molti agenti sotto un solo blueprint può semplificare la gestione, ma concentra anche una dipendenza.

Pensiamo a due progetti: un agente che consulta una base documentale e uno che interviene sull’infrastruttura. Hanno scopi, responsabili e conseguenze operative differenti. Separarli può rendere più chiari i temi di gestione delle credenziali, revisione degli accessi e contenimento durante un incidente.

Il criterio dovrebbe seguire il perimetro operativo. Utilizzare lo stesso blueprint perché “era già pronto” è comprensibile durante una prova; in produzione merita una seconda riflessione.

Figure 3 – – Il blueprint principal rappresenta la presenza del blueprint nel tenant. Fonte: Microsoft Learn

Chi crea il blueprint ne diventa proprietario

La documentazione Microsoft specifica che il creatore viene impostato automaticamente come owner del blueprint e del relativo principal. Gli owner possono creare agent identity da quel blueprint senza avere un ruolo Agent ID, purché il client utilizzato disponga delle autorizzazioni delegate necessarie. Questo spiega perché la revisione dei soli ruoli amministrativi sia insufficiente.

Un utente potrebbe non avere Agent ID Developer, ma essere proprietario di un blueprint esistente. Quella relazione deve entrare nell’inventario e nelle verifiche periodiche.

La creazione rimane comunque distinta dalla concessione degli accessi. Creare un blueprint non attribuisce automaticamente permessi sui dati aziendali. Per esempio, la guida indica Privileged Role Administrator come ruolo minimo per concedere permessi applicativi Microsoft Graph.

Il percorso da governare comprende quindi proprietà dell’oggetto, autenticazione, autorizzazioni e utilizzo effettivo. Fermarsi alla sola creazione lascia aperte parecchie domande.

Come arriva il token alla risorsa

Consideriamo il caso di un agente autonomo, che opera senza il contesto di un utente umano.

Il flusso app-only documentato da Microsoft prevede due passaggi. Il blueprint ottiene un token di scambio, indicato come T1; successivamente T1 viene utilizzato come client assertion per ottenere il token destinato alla risorsa, TR. Il parametro fmi_path identifica l’agent identity figlia interessata.

Figure 4 – Flusso autonomo semplificato. Sono omessi acquisizione della credenziale iniziale e dettagli delle richieste HTTP

Microsoft raccomanda di utilizzare gli SDK previsti per implementare questi protocolli. Nei workload Azure, le managed identity possono essere impiegate come credenziali federate del blueprint, riducendo la necessità di distribuire client secret nel codice o nella configurazione. È un miglioramento nella gestione delle credenziali. Rimane da verificare quali workload possano utilizzarle e quali accessi ottenga l’agente. Una credenziale custodita correttamente può comunque autenticare un’identità troppo privilegiata.

Permessi richiesti, concessi ed ereditati

Anche sulle autorizzazioni servono alcune distinzioni. Required resource access dichiara API e permessi richiesti. Il consenso concede le autorizzazioni. Le inheritable permissions regolano la possibilità che i permessi concessi sul blueprint principal vengano ereditati dalle identità collegate. Le configurazioni dichiarative, da sole, non concedono accesso.

Figure 5 – Dichiarazione, concessione ed ereditarietà. Le autorizzazioni assegnate direttamente alle singole identità seguono un percorso separato

Un dettaglio merita particolare attenzione: Microsoft precisa che i permessi ereditati non risultano elencati come autorizzazioni sulle singole agent identity nel portale o tramite Graph. Vengono combinati con quelli assegnati direttamente durante l’emissione del token.

Un elenco apparentemente vuoto sull’identità figlia non dimostra quindi l’assenza di accessi. Occorre risalire al blueprint e verificare il comportamento sulla risorsa.

Configurare la restrizione dal portale

Per riservare la creazione dei blueprint ai soggetti autorizzati, il percorso documentato è:

Microsoft Entra admin center → Entra ID → Users → User settings

Individuiamo Users can create agent blueprints, impostiamo il valore su No e salviamo. La procedura Microsoft richiede almeno il ruolo Cloud Application Administrator.

Figure 6 – Impostazione di creazione degli agent blueprint e valore configurato nel tenant.

La preferenza può essere configurata prima del rollout e diventa efficace quando la funzionalità raggiunge il tenant. È inoltre indipendente da Users can register applications: aver limitato le registrazioni applicative non equivale ad aver limitato i blueprint.

Dopo il salvataggio riapriamo la pagina e controlliamo il valore. Registriamo tenant e data della verifica.

Prima della distribuzione, questa operazione attesta la preferenza configurata. La verifica del comportamento deve essere ripetuta quando la funzionalità sarà disponibile.

Verificare il controllo con due utenti

Per una prova significativa utilizziamo un tenant di test e un client correttamente autorizzato.

Servono due account: un utente ordinario e un utente con Agent ID Developer.

Le sessioni devono rimanere separate. Riutilizzare accidentalmente il contesto amministrativo è un ottimo modo per dimostrare che funziona tutto, tranne il test.

Quando il rollout ha raggiunto il tenant e l’impostazione è su No, confrontiamo questi casi:

La modifica annunciata non rimuove i blueprint esistenti e non cambia chi può creare identità a partire da essi. Non costituisce quindi un blocco generale di tutte le attività agentiche del tenant.

Figure 7 – Esito della creazione con utente ordinario, con data ed errore completo.

Figure 8 – Prova con utente autorizzato e dettaglio del blueprint creato.

Un generico “accesso negato” non prova che sia intervenuta questa specifica impostazione. Potrebbero mancare consenso al client, permessi o altri prerequisiti. Il confronto serve proprio a distinguere queste condizioni. Quelli descritti sono criteri di prova da applicare nel proprio ambiente, non risultati già osservati su un tenant.

Leggere la policy con PowerShell

Possiamo affiancare alla verifica grafica una lettura della policy tramite Microsoft Graph PowerShell. L’operazione GET documenta Policy.Read.All come permesso minimo.

Dopo aver ottenuto il consenso necessario, colleghiamoci esplicitamente al tenant:

Leggiamo, quindi, la configurazione:

L’endpoint beta è soggetto a modifiche. Questa lettura serve a osservare ciò che il servizio restituisce nel tenant interessato.

Per la nuova impostazione è stata segnalata la proprietà allowedToCreateAgentIdentityBlueprints, che non compare nella pagina ufficiale dello schema consultata durante la preparazione dell’articolo. Se il campo non viene restituito, non dobbiamo interpretarne l’assenza come false. Per la configurazione descritta qui rimane il riferimento alla procedura da portale documentata da Microsoft.

Il test deve arrivare fino all’API

Per verificare gli accessi possiamo utilizzare una nostra API di laboratorio, osservando i claim dopo la corretta validazione del token.

oid può riferirsi all’utente umano, al service principal dell’agente oppure all’account utente dell’agente. Il riferimento al blueprint padre è utile per l’audit; Microsoft sconsiglia di usarlo come scorciatoia per autorizzare tutti gli agenti collegati. I client devono inoltre trattare gli access token come opachi: l’analisi e la validazione spettano alla risorsa destinataria.

Figure 9 – Log dell’API con audience, tenant, soggetto, client e blueprint padre. Escludere token completi e credenziali.

Eseguiamo un’operazione consentita e una vietata. Il backend deve riconoscere l’identità in entrambi i casi e negare la seconda richiesta per mancanza dell’autorizzazione necessaria.

Un’autenticazione riuscita dimostra un passaggio tecnico. Il rifiuto di un’operazione fuori perimetro dimostra che abbiamo verificato anche il confine degli accessi.

Rivedere gli oggetti già presenti

Dal portale possiamo raggiungere Entra ID → Agents → Agent identities e consultare stato, proprietari, sponsor, permessi concessi e sign-in log.

Per ogni progetto ricostruiamo scopo, ambiente di esecuzione, blueprint, identità collegate, credenziali, risorse raggiungibili e data di revisione. Owner e sponsor svolgono funzioni differenti. Il primo presidia la gestione tecnica; il secondo risponde dello scopo e del ciclo di vita. Questa separazione è esplicita nel modello Microsoft.

Nella pratica dobbiamo poter contattare qualcuno che sappia spiegare perché l’agente esiste e se un determinato comportamento è previsto. Inserire un nome nel campo sponsor non garantisce che quella persona conosca il progetto.

Conclusioni

Per un tenant che non dispone ancora di un processo di sviluppo e approvazione degli agenti, limitare la creazione dei blueprint è una scelta iniziale ragionevole. I progetti autorizzati devono poi avere un percorso concreto, con responsabilità definite, accessi proporzionati e verifiche periodiche.

La revisione deve comprendere anche i blueprint esistenti, le identità collegate e le autorizzazioni ereditate. Altrimenti potremmo configurare correttamente il nuovo default e lasciare intatto tutto ciò che era già stato creato.

Gli agenti stanno entrando nell’infrastruttura con identità riconoscibili e capacità operative. Devono quindi entrare anche nelle procedure di sicurezza, dall’attivazione alla dismissione.

Quando qualcuno ci dirà «abbiamo creato soltanto un agente», dovremmo poter ricostruire chi ne risponde, quali risorse raggiunge e come interromperne l’operatività.

Possibilmente prima che serva farlo in emergenza.

Qui troverete qualche link con i riferimenti alla documentazione ufficiale Microsoft utilizzata per la stesura di questo articolo:

• MC1506733 – Review who can create agents in Microsoft Entra
  
• Microsoft Learn – Delegate application and agent management permissions
  
• Microsoft Learn – Create an agent identity blueprint
  
• Microsoft Learn – Agent identity blueprints
  
• Microsoft Learn – Agent identities, service principals, and applications
  
• Microsoft Learn – Autonomous app OAuth flow
  
• Microsoft Learn – Inheritable permissions
  
• Microsoft Learn – Token claims reference for agents
  
• Microsoft Learn – Owners, sponsors, and managers
  

Stay tuned!