Quattro oggetti, non uno solo

Microsoft Entra Agent ID è la piattaforma di identità che estende Microsoft Entra agli agenti AI. Introduce quattro oggetti, e l’esame gioca sulla loro distinzione.

L’agent identity blueprint è il template: contiene le credenziali e le usa per ottenere token per conto di tutte le agent identity create da esso. Le policy applicate al blueprint valgono per tutte, e disabilitarlo impedisce a tutte di autenticarsi. L’agent identity blueprint principal registra la presenza di quel blueprint in uno specifico tenant: è l’oggetto a cui punta la claim oid nei token e quello che compare nei log di audit. L’agent identity è l’identità primaria con cui l’agente si autentica e, a differenza di un account utente, non possiede credenziali proprie: usa token emessi dal suo blueprint.

L’agent user, cioè l’agent’s user account, è facoltativo e ha un rapporto uno a uno immutabile con una agent identity. Serve solo quando l’agente deve accedere a risorse che richiedono un oggetto utente: riceve token con claim idtyp=user, può stare in gruppi e administrative unit e ricevere licenze. Non sostituisce l’agent identity, devono esistere entrambe. Non può avere password o passkey, entrare in un role-assignable group o ricevere ruoli di amministratore con privilegi.

Tre nomi si somigliano: Microsoft Entra Agent ID è l’identità, l’agent registry è l’inventario, Microsoft Agent 365 è la suite. La documentazione descrive la separazione di compiti: Agent 365 scopre e inventaria, Entra Agent ID assegna identità, permessi e protezioni.

Il modello amministrativo separa la responsabilità di business da quella tecnica, ed è il punto più esaminabile dell’unità.

Lo sponsor è chi risponde dello scopo dell’agente ed è obbligatorio: alla creazione di una agent identity o di un agent blueprint ne serve almeno uno, mentre i blueprint principal sono esenti. Opera in least-privilege: può abilitare e disabilitare l’identità, modificarne gli sponsor ed eseguire un soft-delete, ma non può toccare le impostazioni applicative.

L’owner è facoltativo ed è il profilo tecnico. Modifica proprietà precluse allo sponsor, come quelle di autenticazione, gestisce credenziali e aggiunge altri owner e sponsor. Soprattutto fa ciò che allo sponsor non è concesso: riabilitare una agent identity disabilitata, ripristinare identità soft-deleted ed eseguire l’hard-delete. Obbligatorio ma non distruttivo lo sponsor, facoltativo ma distruttivo l’owner: se ricordate solo questa riga avete già gran parte della domanda.

I tipi ammessi non coincidono. Come owner si designano utenti, compresi i guest, e service principal; i gruppi non sono ammessi. Come sponsor si designano utenti e alcuni gruppi: dynamic membership group, security o Microsoft 365, e assigned membership group Microsoft 365. Non sono ammessi i role-assignable group né gli assigned membership group di tipo security.

Il manager è il terzo ruolo: un utente responsabile dell’agente nella gerarchia organizzativa, che può richiedere access package per gli agent user che gli fanno capo, ma non può modificare né eliminare l’agente. Nulla di questo coincide con i ruoli di directory: Agent ID Administrator e Agent ID Developer sono RBAC, non relazioni sull’oggetto, e chi li possiede non diventa automaticamente sponsor. Owner e sponsor si gestiscono in Entra ID > Agents > Agent identities o Agent blueprints, voce Owners and sponsors sotto Access.

Access package e Conditional Access sono due leve diverse

La confusione tipica è trattarli come sinonimi. L’entitlement management con gli access package decide quali risorse un agente può ricevere; il Conditional Access decide a quali condizioni può ottenere un token.

Un access package per agenti si crea in ID Governance > Entitlement management > Access packages. Sotto Who can get access si sceglie For users, service principals, and agent identities in your directory e lo scope All agents. Come resource role si includono security group, ruoli di directory e API permission, ma non application role, ruoli SAP o site role di SharePoint Online: un access package che li contiene non è riutilizzabile. Le vie di richiesta sono tre: l’agente via API, lo sponsor per suo conto, o l’assegnazione diretta di un amministratore. Alla scadenza è lo sponsor a ricevere la notifica e a decidere se chiedere un’estensione.

Nel Conditional Access, sotto Assignments > Users, agents (Preview) or workload identities, si sceglie Agents e quindi All agent identities, All agent users (Preview), Select agent identities o Select agent users (Preview). Tre trappole documentate: una policy che punta a tutti gli utenti non comprende gli agent user; una policy sulle agent identity non si applica all’agent user; targetizzare il blueprint copre tutte le agent identity derivate, ma non i loro agent user. Per le sole agent identity l’unica condizione disponibile è Agent risk (Preview) e l’unico controllo è Block access, perché non esiste remediation interattiva.

Continuità della sponsorship e che cosa chiede l’esame

Se lo sponsor lascia l’organizzazione la sponsorship viene trasferita automaticamente al suo manager, così resta sempre una persona responsabile. I Lifecycle Workflows aggiungono tre task dedicati, Send email to manager about sponsorship changes, Send email to co-sponsors about sponsor changes e Transfer agent identity sponsorships to manager, tutti di categoria mover e leaver: selezionabili solo in template di quelle categorie, mai in un template joiner. Owner e sponsor gestiscono poi il ciclo di vita dal My Account portal, dove abilitano e disabilitano l’agente, e richiedono access package dal My Access portal.

AB-650 è in beta e la soglia di superamento è 700. Aspettatevi scenari che chiedono chi può compiere una certa azione: se il testo dice ripristinare o eliminare definitivamente, la risposta è l’owner; se dice disabilitare, cambiare gli sponsor o estendere un access package, la risposta è lo sponsor.