Argo's New Dreams

Dal blueprint agli access package: cosa cambia davvero nella gestione dei permessi — note di prova sul campo, agosto 2026.

TL;DR: Ho pubblicato un agente Microsoft Foundry nel mio tenant e l’ho governato con gli stessi strumenti che uso per persone e app: ruoli RBAC, ruoli di directory, Conditional Access e, soprattutto, gli access package di Entra ID Governance. La sorpresa vera: un’Agent Identity può ricevere accesso a scadenza, con business justification e approvazione tracciate — invertendo l’onere da “ricordarsi di rimuovere” a “decidere di rinnovare”.

Ho passato un pomeriggio a fare una cosa che sulla carta sembrava scontata e che nella pratica non lo è affatto: pubblicare un agente da Microsoft Foundry e provare a trattarlo, dal punto di vista dei permessi, esattamente come tratto un utente o una service principal. Non l’ho fatto per curiosità accademica: ho un tenant di test dove verifico ogni novità Microsoft prima di consigliarla a un cliente, ed è lì che ho scoperto che gli access package di Entra ID Governance — lo strumento che uso da anni per gestire le richieste di accesso delle persone — funzionano anche per gli agenti AI. È il dettaglio che ha cambiato il mio modo di pensare alla governance degli agenti.

Cos’è il Microsoft Entra Agent ID e perché conta ora

Microsoft Entra Agent ID è il framework di identità che Microsoft ha esteso agli agenti AI dentro Agent 365: ogni agente pubblicato riceve un’identità Entra dedicata, tecnicamente una service principal con servicePrincipalType impostato su ServiceIdentity (Microsoft Learn, 2026a). Non è più “codice che gira da qualche parte”: è un oggetto nel registro di Entra, con lo stesso trattamento — in teoria — di un utente o di un’app.

L’idea nasce da un problema di scala che chi lavora in IT conosce bene: gli agenti si moltiplicano più in fretta delle utenze che siamo abituati a governare. Un report di Palo Alto Networks del 2026 stima che le organizzazioni gestiscono in media 109 identità macchina per ogni identità umana, con una crescita attesa degli agenti AI dell’85% nei prossimi 12 mesi e delle identità macchina nel complesso del 77%, contro il 56% delle identità umane (Pogorelec, 2026). Amministrare questo volume con gli strumenti pensati per le persone — un’assegnazione manuale, una revoca “quando qualcuno se ne ricorda” — semplicemente non regge.

Ho voluto verificare quanto la promessa di Entra Agent ID reggesse nella pratica, pubblicando l’agente Foundry nel mio tenant e provando a governarlo con Conditional Access, ruoli RBAC e ruoli di directory — gli stessi strumenti che uso ogni giorno per persone e app.

Cosa succede davvero quando pubblico un agente da Microsoft Foundry?

Pubblicando l’agente, Entra crea in automatico due oggetti collegati: un Agent Identity Blueprint e un’Agent Identity vera e propria generata a partire da quel blueprint. Il blueprint è il “modello” che definisce credenziali, permessi OAuth di base e identifier URI condivisi da tutti gli agenti che ne derivano (Microsoft Learn, 2026b).

Il dettaglio che cambia la scala del ragionamento è che le policy applicate a livello di blueprint — una Conditional Access, per esempio — si propagano automaticamente a tutte le identità create da quel blueprint, non solo a quella che ho pubblicato io. Non governo più il singolo agente, ma la “famiglia” di agenti che condividono lo stesso blueprint: disabilitare o revocare permessi a livello di blueprint significa farlo per un’intera classe di agenti in un’unica operazione (Microsoft Learn, 2026c). Da quel momento l’agente compare nel registro delle identità: gli ho assegnato un ruolo RBAC di Azure su uno storage account e un ruolo di directory in Entra, esattamente come farei con qualsiasi altra identità.

Gli access package di Entra ID Governance funzionano anche per gli agenti AI?

Sì: un’Agent Identity può essere inserita in un access package di Entra ID Governance esattamente come un utente o una service principal, e questo cambia la natura stessa del permesso (Microsoft Learn, 2026d).

Un’assegnazione diretta di ruolo è una scelta amministrativa immediata: apro l’identità, seleziono il ruolo, l’assegnazione è fatta in due clic ed è permanente finché qualcuno non la rimuove manualmente. Con un access package, la stessa risorsa passa invece attraverso un processo:

• l’agente non può richiedere nulla da solo per conto proprio in un contesto di supervisione umana, quindi la richiesta l’ho fatta io in qualità di sponsor dell’agente;
• Entra segnala esplicitamente che si sta richiedendo l’accesso per conto dell’agente, chiedendo di rispondere alle domande del modulo a nome suo;
• è richiesta una business justification: perché questo agente ha bisogno di questo accesso;
• la richiesta passa a un approvatore (nel mio caso ero io stesso), e l’approvazione viene registrata con tanto di motivazione;
• l’assegnazione ottenuta ha una scadenza — nella mia prova, 30 giorni — trascorsa la quale serve una nuova approvazione per mantenerla.

Ogni agente identity, del resto, richiede uno sponsor umano responsabile del suo ciclo di vita e delle decisioni di accesso; se lo sponsor lascia l’organizzazione, la responsabilità passa automaticamente al suo manager, così da garantire continuità di supervisione (Microsoft Learn, 2026e). È lo stesso principio dei tre canali di richiesta previsti da Microsoft: l’agente può richiedere programmaticamente l’accesso da solo, lo sponsor può richiederlo per suo conto, oppure un amministratore può assegnarlo direttamente (Microsoft Learn, 2026d).

Il punto chiave: con l’assegnazione diretta l’accesso resta finché qualcuno non se ne ricorda e lo rimuove — ed è, per esperienza, difficile da intercettare in tempo. Con l’access package succede il contrario: l’accesso scompare da solo, a meno che qualcuno decida attivamente che l’agente ne ha ancora bisogno.

Qual è la differenza pratica tra assegnazione diretta e access package per un agente?

Sul piano operativo cambiano attivazione, motivazione, durata e tracciabilità — non solo la burocrazia intorno alla richiesta, ma il comportamento di default nel tempo. La tabella riassume il confronto diretto che ho verificato nel mio tenant.

Aspetto	Assegnazione diretta	Access Package
Come si attiva	Assegnazione diretta del ruolo (2 click)	Richiesta formale tramite access package
Chi può richiederla	L’amministratore, per l’identità	Lo sponsor, per conto dell’agente (l’agente non può auto-richiedersi nulla)
Serve una motivazione?	No	Sì: business justification obbligatoria
Passa da un’approvazione?	No	Sì, con motivazione registrata
Durata	Permanente, finché qualcuno non la rimuove	A tempo (es. 30 giorni), poi richiede un nuovo consenso
Comportamento di default	L’accesso resta anche se non serve più	L’accesso scompare da solo se nessuno lo rinnova
Tracciabilità	Minima: si vede solo che il ruolo è assegnato	Alta: richiesta, motivazione, approvatore e scadenza sono tutti registrati

Perché l’”agent sprawl” è un rischio di sicurezza crescente nel 2026?

Perché gli agenti si creano più in fretta di quanto si riescano a governare uno per uno, e sopravvivono spesso a chi li ha costruiti: un progetto pilota finisce, la persona cambia ruolo, ma l’identità dell’agente — e i permessi che porta con sé — restano nel tenant.

È lo stesso problema delle utenze orfane e delle service principal dimenticate, amplificato dal ritmo con cui gli agenti vengono creati e pubblicati. Forrester ha inserito per il 2026 le minacce legate agli agenti AI e l’”AI identity sprawl” tra le nuove categorie di rischio dominanti per i CISO, segnalando che gli agenti personali operano come “operatori ombra” dentro le aziende, senza i controlli MFA o i log di sessione su cui si basano i sistemi SIEM tradizionali (Schulze, 2026, riportando l’analisi di Jitin Shabadu). Sul fronte della complessità dei permessi, Jake Williams, faculty IANS, la mette così: “[Model Context Protocol] will be the AI-related security issue of 2026. Granular OAuth consents disrupt the user experience and constrained delegation still allows for token misuse. We’re already seeing developers try to overcome these limitations with AuthN/AuthZ patterns that look like they belong in ‘Hello World’ examples, not enterprise applications” [VERIFY: data pubblicazione dell’articolo IANS – fonte: IANS Research, discrepanza tra data indicata nell’URL (19/04/2026) e data nel corpo del testo (24/02/2026)].

Microsoft stessa raccomanda, tra le best practice per Entra Agent ID, di includere gli agenti nelle access review periodiche, facendo attestare agli sponsor ogni 6-12 mesi che ciascun agente sia ancora necessario, e di sviluppare un processo trimestrale per individuare agenti con sponsor mancanti o nessuna attività recente (Microsoft Learn, 2026f). Per gli agenti, per questo, il comportamento di default che preferisco resta quello dell’access package: accesso a scadenza, con giustificazione e approvazione tracciate, che si spegne da solo se nessuno lo rinnova.

Perché trattare l’AI come “un prodotto” di un reparto è un errore anche a livello di identity governance?

Perché il modello che funziona per gli agenti — un’identità unica che attraversa Azure RBAC, ruoli di directory, Conditional Access e access package senza restare confinata in un singolo sistema — è lo stesso principio che dovrebbe valere per l’AI a livello organizzativo: è una tecnologia trasversale, non un prodotto chiuso in un reparto.

Quando un’azienda tratta l’intelligenza artificiale come un tool acquistato, una licenza assegnata a un reparto o un progetto chiuso dentro un team “AI” isolato dagli altri, costruisce di fatto un reparto blindato. Il problema è che l’AI, per sua natura, attraversa i processi, i dati e le competenze di funzioni diverse (vendite, produzione, HR, IT) esattamente come un agente ben governato attraversa identità, permessi e sistemi diversi senza restare confinato in un solo silo. Chi costruisce reparti stagni intorno all’AI, prima o poi si scontra con questa natura trasversale: i casi d’uso più interessanti nascono all’incrocio tra funzioni diverse, e un governo dell’AI pensato per un solo reparto smette presto di adattarsi al resto dell’organizzazione. Un modello di identità e governance condiviso — come quello che Agent 365 ed Entra Agent ID applicano agli agenti — è in fondo la controprova tecnica di questo principio: anche l’infrastruttura che rende possibile l’AI è pensata per attraversare i confini, non per restare dentro un unico reparto.

Implicazioni pratiche per le PMI italiane

Per una PMI italiana il punto non è solo tecnico, è anche di licenza: usare l’entitlement management di Entra ID Governance sugli agenti richiede o una licenza Microsoft 365 E7 (che include Agent 365 e Microsoft Entra Suite), oppure Microsoft Agent 365 abbinata ad almeno Microsoft Entra ID P1 o Microsoft 365 E3 (Microsoft Learn, 2026g). Non è un dettaglio da ignorare quando si valuta se un pilota di agenti AI può crescere in produzione con una governance seria, o se resterà un esperimento senza controlli.

L’opportunità reale per le PMI è che lo stesso modello di governance già usato per dipendenti e fornitori — sponsor, business justification, scadenza, revisione periodica — si estende agli agenti senza reinventare processi. Il rischio dell’hype è pensare che basti “aver acceso” Agent 365 per essere a posto: senza sponsor assegnati, senza access review programmate e senza un inventario aggiornato degli agenti pubblicati, l’agent sprawl si accumula silenziosamente anche in un tenant piccolo, spesso più in fretta che in una grande azienda dove IT ha già un processo di provisioning strutturato.

La licenza di Microsoft 365 basta a governare gli agenti AI in Entra?

No, la licenza è una condizione necessaria ma non sufficiente. Serve Microsoft 365 E7 (con Agent 365 e Entra Suite) oppure Agent 365 abbinato a Entra ID P1 o Microsoft 365 E3, ma senza sponsor assegnati, access review pianificate e un inventario aggiornato degli agenti, l’accesso concesso resta comunque ingovernato nella pratica quotidiana.

Cosa succede se lo sponsor di un agente lascia l’azienda?

La sponsorship viene trasferita automaticamente al manager dello sponsor uscente, così che l’agente abbia sempre un responsabile umano identificabile per le decisioni sul ciclo di vita e sull’accesso. È un meccanismo pensato apposta per evitare gli agenti “orfani” che restano attivi senza controllo.

Un agente può richiedere da solo l’accesso a una risorsa?

Sì, tecnicamente un’Agent Identity può generare una richiesta programmatica di access package per le proprie esigenze operative. Nella pratica, per mantenere una supervisione umana reale sulle richieste sensibili, io preferisco far passare la richiesta dallo sponsor, che la presenta per conto dell’agente con relativa motivazione.

Gli access package per agenti valgono anche per i ruoli applicativi o SharePoint?

No: le identità agente e le service principal non possono essere aggiunte tramite access package a ruoli applicativi, ruoli SAP o ruoli di siti SharePoint Online. Per questi casi Microsoft richiede di creare un nuovo access package dedicato, non riutilizzare uno esistente che contenga quei ruoli.

Conclusioni

La prova sul campo mi ha convinto di una cosa che a parole sembrava ovvia e nella pratica non lo era: gli strumenti di governance che usiamo per le persone da anni funzionano, con gli stessi meccanismi di sponsorship, motivazione e scadenza, anche per gli agenti AI. Non è un dettaglio da manuale tecnico: è la differenza tra un tenant dove gli agenti si accumulano silenziosamente e uno dove ogni accesso ha una data di scadenza e un responsabile umano. Resto convinto — ed è il filo che lega questo pezzo tecnico a una convinzione più ampia — che l’AI, come gli agenti che la incarnano, funzioni meglio quando attraversa i confini invece di restare chiusa in un reparto.

---

Trasparenza sull’uso dell’intelligenza artificiale
Questo articolo è stato redatto con l’assistenza di un sistema di intelligenza artificiale generativa (Claude Sonnet 5, tramite l’agente Argos Newsroom su Microsoft Copilot Studio) per la ricerca delle fonti, la strutturazione e la prima stesura. Il testo è stato successivamente verificato, corretto e approvato da un autore umano, Luca Borio, che ne detiene la responsabilità editoriale ai sensi dell’art. 50 del Regolamento (UE) 2024/1689. Dati, citazioni e link sono stati controllati sulle fonti originali indicate. Eventuali errori residui sono miei.

Riferimenti (APA)

• Microsoft Learn. (2026a). What is Microsoft Entra Agent ID? Microsoft. https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id — Livello B
• Microsoft Learn. (2026b). Agent 365 identity. Microsoft. https://learn.microsoft.com/en-us/microsoft-agent-365/developer/identity — Livello B
• Microsoft Learn. (2026c). Create an agent identity blueprint. Microsoft. https://learn.microsoft.com/entra/agent-id/create-blueprint — Livello B
• Microsoft Learn. (2026d). Access packages for agent identities in Microsoft Entra e Governing agent identities (preview). Microsoft Entra ID Governance. https://learn.microsoft.com/entra/agent-id/agent-access-packages ; https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview — Livello B
• Microsoft Learn. (2026e). What is Microsoft Entra ID Governance? (sez. Identity governance for agents, preview). https://learn.microsoft.com/entra/id-governance/identity-governance-overview#identity-governance-for-agents-preview — Livello B
• Microsoft Learn. (2026f). Best practices for Microsoft Entra Agent ID. https://learn.microsoft.com/entra/agent-id/best-practices-agent-id — Livello B
• Microsoft Learn. (2026g). Request access package on-behalf-of other identities (sez. License requirements for requesting on behalf of agent identities, preview). https://learn.microsoft.com/entra/id-governance/entitlement-management-request-behalf#prerequisites — Livello B
• Pogorelec, A. (2026, 14 maggio). Machine identities outnumber humans 109 to 1. Help Net Security. https://www.helpnetsecurity.com/2026/05/14/2026-identity-security-landscape-report/ — Livello B (dati da Palo Alto Networks, 2026 Identity Security Landscape Report)
• Schulze, H. (2026, 20 luglio). Forrester Names AI Agent Threats the Top 2026 CISO Risk. Cybersecurity Insiders. https://www.cybersecurity-insiders.com/forrester-2026-ai-agent-threats-ciso-risk/ — Livello B
• IANS Research. (2026). AI Agents Are Creating an Identity Security Crisis in 2026. https://www.iansresearch.com/resources/all-blogs/post/security-blog/2026/04/19/ai-agents-are-creating-an-identity-security-crisis-in-2026 — Livello B [VERIFY: data pubblicazione – fonte: IANS Research]
• Borio, L. (2026, 14 aprile). Governance e sicurezza degli agenti AI: la risposta alla domanda che ogni CIO fa prima o poi. Argos New Dreams. — Livello C
• Borio, L. (2026, 22 agosto). Un tool, un ruolo: chi può creare agenti AI in azienda. Argos New Dreams. — Livello C

Fonti verificate al 01/09/2026. Nota: per questo articolo non ho trovato fonti di livello A (paper peer-reviewed) direttamente pertinenti — l’argomento è documentazione di prodotto e ricerca di settore, non letteratura scientifica; lo dichiaro per trasparenza rispetto al target di 5-7 fonti.

Link interni Argos

• Governance e sicurezza degli agenti AI: la risposta alla domanda che ogni CIO fa prima o poi
• Un tool, un ruolo: chi può creare agenti AI in azienda
• Copilot Studio o Microsoft Foundry: quale usare nel 2026?
• Microsoft 365 Agent Store: come pubblicare agenti AI interni con governance enterprise

#Agent365 #MicrosoftFoundry #MicrosoftEntraAgentID #AccessPackages