Identità dell'Agente 365

L'Agent 365 utilizza Microsoft Entra Agent ID per rappresentare ogni agente con un'identità di agente distinta. L'identità di un agente è un principale di servizio Microsoft Entra con servicePrincipalType impostato a ServiceIdentity e @odata.type impostato a #microsoft.graph.agentIdentity. Gli amministratori gestiscono le identità degli agenti con gli stessi controlli tenant usati altrove in Microsoft Entra, inclusi Accesso Condizionato, concessioni di permessi e consensi, e operazioni di ciclo di vita.

Oggetti identità

Tre oggetti compongono il modello. Non tutti gli agenti usano tutte e tre.

oggetto Descrizione
Progetto di identità dell'agente Un template in Microsoft Entra ID che definisce un tipo di agente. Contiene le credenziali, i permessi dichiarati e ereditabili, l'editore verificato e qualsiasi ruolo dell'app. Un solo progetto può creare molte identità di agenti. Per informazioni approfondite su come le applicazioni vengono registrate in Microsoft Entra, vedi Registra un'applicazione presso la Microsoft Identity Platform.
L'identità dell'agente L'account che un singolo agente gestisce come. Ha un proprio ID oggetto, nome visualizzato, sponsor e assegnazioni di permesso.
Account utente dell'agente Un secondo account opzionale, creato solo quando l'agente ha bisogno di un account utente Microsoft Entra. Può contenere licenze e risorse Microsoft 365 come una cassetta postale. Disponibile solo per gli inquilini che partecipano al programma di anteprima Frontier. L'identità di un agente ha un account utente zero o un solo agente, e l'account utente di ogni agente appartiene esattamente a un'identità di agente.

Rapporto blueprint-agente-agente

All'interno di un inquilino, una registrazione standard della domanda di solito ha un rapporto uno a uno con il suo committente di servizio. Il modello dell'agente è uno a molti: un modello può essere associato a molte identità di agente all'interno di un inquilino.

Ogni identità di agente eredita proprietà del protocollo dal blueprint e può detenere i propri permessi a valle. Poiché gli agenti dello stesso tipo condividono un blueprint, un amministratore può applicare una policy di Accesso Condizionato, revocare una concessione di permesso o disabilitare ogni agente di quel tipo in un'unica operazione.

Le identità degli agenti sono a singolo tenant e possono essere assegnate solo token nel tenant in cui sono state create. I progetti possono essere multitenant. È così che un agente pubblicato viene aggiunto a un cliente tenant, che poi crea le proprie identità tenant-agent locale dal blueprint.

Credentials

Un agente si autentica usando la propria identità di agente, ma l'identità stessa non memorizza le credenziali. Configuri le credenziali sul blueprint, che le usa per acquisire token per le identità degli agenti create da quel blueprint.

Tipi di credenziali supportati nel blueprint:

  • Credenziali di identità federate
  • Certificati e chiavi crittografiche
  • Segreti client

Per gli agenti che girano su Azure, puoi federare il blueprint a un'identità gestita da Azure così non viene memorizzato alcun segreto sul blueprint.

Le credenziali dei blueprint sono condivise da ogni identità di agente creata da quel blueprint. Tratta ogni blueprint come un confine di credenziali e raggruppa solo le identità che possono condividere in sicurezza credenziali e permessi di base ereditati.

Le identità degli agenti non si autenticano con password, SMS, chiave di accesso o app di autenticazione, quindi l'autenticazione multifattore non si applica a loro. Governale invece con politiche di Accesso Condizionale.

Account utente dell'agente

Alcuni agenti devono accedere a sistemi che richiedono un account utente Microsoft Entra. In questi casi, puoi dare all'agente un secondo account e segnarlo nella directory come agente AI.

Utilizzando un account utente e le licenze appropriate, un agente può avere una cassetta postale e uno spazio di archiviazione OneDrive, apparire nei metadati della directory e dell'organizzazione, ed essere contattato tramite Teams, Outlook, commenti Word e email.

Aggiungi un account utente solo quando l'agente ne ha bisogno. Gli agenti che emettono solo strumenti di telemetria e chiamata di solito non ne hanno bisogno.

Importante

Gli agenti con un proprio account utente sono disponibili solo per gli inquilini che partecipano al programma di anteprima Frontier.

Permessi e flusso di esecuzione

Un agente può eseguire tre modalità di esecuzione. La modalità determina per chi agisce l'agente, quale soggetto token appare nella chiamata a valle e quali permessi e consenso sono necessari:

Modalità di esecuzione Descrizione
S2S (da servizio a servizio) L'agente funziona senza un contesto utente e agisce come una propria identità agente. Usa questa modalità per attività programmate, monitoraggio e elaborazione in background. Utilizza i permessi dell'applicazione e l'identità dell'agente è il soggetto del token. Per il pattern OAuth sottostante, vedi OAuth 2.0 client credentials grant.
OBO (a nome di) L'agente riceve il contesto di un utente umano connesso e agisce per quell'utente. Usa questa modalità quando l'accesso dipende dall'identità o dai permessi dell'utente. Utilizza permessi delegati; L'utente è il soggetto del token e l'identità dell'agente è l'attore. Per i dettagli sull'implementazione, vedi OAuth 2.0 On-Behalf-Of flow.
Agentic-User L'agente utilizza un proprio account utente Microsoft Entra e agisce come tale account. Questa modalità richiede il programma di anteprima Frontier ed è utilizzata quando l'agente ha bisogno di risorse utente o esperienze Microsoft 365 basate sull'utente, come una casella di posta, la presenza di Teams o interazioni tra Word e Outlook. L'account utente dell'agente è l'utente in carica, mentre l'identità dell'agente rimane l'identità registrata dell'Agente 365.

Ad esempio, l'elaborazione in background notturna di solito utilizza S2S; un'azione specifica per l'utente in chat utilizza OBO; e la lettura della casella della posta di un agente utilizza Agentic-User. Il modello di permessi e la modalità runtime sono correlati, ma non sono termini intercambiabili: scegli prima la modalità, poi confermi l'applicazione o i permessi delegati e il consenso richiesti dalla risorsa a valle.

Prima di implementare una modalità, verifica che la tua configurazione completa supporti l'operazione:

  1. Identifica chi deve agire l'agente per l'operazione: la sua identità di agente, un utente connesso o un proprio account utente.
  2. Conferma che la modalità selezionata supporti quel contesto dell'account e il tipo di permesso richiesto dall'API o risorsa di destinazione.
  3. Concedere gli ambiti e il consenso richiesti, poi soddisfare eventuali prerequisiti aggiuntivi, come licenze o una risorsa utente provisionata.

Se qualche requisito non è supportato dalla modalità selezionata, scegli una modalità o un'operazione diversa. Per i scope Microsoft Graph, consulta il riferimento ai permessi Microsoft Graph.

Una volta che sai quali permessi servono all'agente, decidi dove assegnarli. Dichiarare i permessi di base condivisa sul blueprint in modo che ogni identità di agente creata da esso li erediti, e assegnare i permessi direttamente a un'identità di agente quando l'accesso è specifico per quell'agente. Il controllo di accesso basato sui ruoli (RBAC) di Azure è un'eccezione: i blueprint non possono contenere ruoli Azure RBAC, quindi assegna quei ruoli direttamente a ciascun agente identico. Le identità degli agenti possono anche ricoprire ruoli integrati in Microsoft Entra.

Importante

Dichiarare i permessi su un progetto non li concede. Un amministratore deve acconsentire, sia sul principale del blueprint sia sulle identità individuali degli agenti.

Ogni documento di identità e schema di identità dell'agente richiede almeno uno sponsor: il rappresentante aziendale responsabile dello scopo e del ciclo di vita dell'agente. Gli sponsor potrebbero essere chiamati a decidere se un agente debba essere trattenuto o disabilitato, e le squadre di sicurezza potrebbero utilizzare lo sponsor per contattare una persona responsabile durante un incidente.

I log di accesso e audit differenziano tra il blueprint, l'identità dell'agente e l'account utente dell'agente. Un revisore può identificare la fonte dell'accreditamento, l'identità d'azione e il soggetto del token. Nelle operazioni S2S, l'identità dell'agente è il soggetto del token. Nelle operazioni OBO, l'utente connesso è il soggetto e l'identità dell'agente è l'attore.

Elementi configurati

Quando porti un agente in Agent 365, registri un blueprint di identità di agente in Microsoft Entra e crei le identità degli agenti da esso. L'abilità make-a365-agent esegue entrambi i passaggi sul percorso standard dell'agente. Sul percorso dei compagni IA, make-ai-teammate li esegue. Vedi Avvio Rapido: collega un agente esistente all'Agente 365.

Decidi i seguenti punti prima di iniziare:

Item Descrizione
Quanti progetti Usa un solo progetto per ogni confine di credenziali. Usa blueprint separati per gli agenti che non possono condividere in sicurezza le credenziali e i permessi di base ereditati.
Quale modello di permessi Permessi di applicazione, permessi delegati, o entrambi.
Se l'agente ha bisogno di un account utente Solo se richiede una casella di posta, la presenza di Teams o un profilo nella directory dell'organizzazione.
Chi sono gli sponsor Ogni blueprint e ogni identità di agente richiedono almeno uno sponsor, che può essere un utente o un gruppo.

Contenuti correlati

  • Last updated on