Concetti relativi all'identità dell'agente in Microsoft Foundry

Un'identità agente è un tipo di identità specializzato in Microsoft Entra ID, progettato appositamente per gli agenti di intelligenza artificiale. Fornisce un framework standardizzato per la governance, l'autenticazione e l'autorizzazione degli agenti di intelligenza artificiale in servizi Microsoft. Questo framework consente agli agenti di accedere in modo sicuro alle risorse, interagire con gli utenti e comunicare con altri sistemi.

Microsoft Foundry effettua automaticamente il provisioning e gestisce automaticamente le identità degli agenti nel ciclo di vita dell'agente. Questa integrazione semplifica la gestione delle autorizzazioni mantenendo la sicurezza e la controllabilità man mano che gli agenti passano dallo sviluppo all'ambiente di produzione.

Questo articolo illustra in che modo le identità dell'agente sono correlate agli oggetti Microsoft Entra ID, come Foundry le usa quando un agente chiama gli strumenti e come applicare l'accesso con privilegi minimi con Azure controllo degli accessi in base al ruolo. Lo stesso modello di identità si applica agli agenti prompt basati su testo e agli agenti prompt basati su voce. Negli scenari basati sulla voce, Foundry gestisce il runtime vocale in tempo reale e la connessione WebSocket, mentre l'identità dell'agente viene comunque utilizzata per autenticare l'accesso agli strumenti e alle risorse downstream.

Prerequisiti

Per i ruoli e gli ambiti RBAC specifici di Foundry, vedere controllo degli accessi basato sul ruolo di Azure in Foundry.

Identità e progetti dell'agente

Fondry utilizza le identità degli agenti di Microsoft Entra ID per soddisfare due esigenze correlate.

  • Gestione e governance: offrire agli amministratori un modo coerente per l'inventario degli agenti, applicare criteri e attività di controllo.
  • Autenticazione dello strumento: consentire a un agente di eseguire l'autenticazione ai sistemi downstream (ad esempio, Archiviazione di Azure) senza incorporare segreti nei prompt, codice o stringhe di connessione.

Progetto di identità dell'agente

Un modello di identità agente modella l'agente ed è l'oggetto padre per le identità dell'agente associate. Fornisce il modello di governance per tali identità.

Il blueprint può fungere anche da punto di accesso per l'autenticazione dell'agente. Usando lo schema di autorizzazione dell'endpoint di anteprima AgentBlueprint, i client ottengono i token per l'audience del blueprint dell'agente per chiamare l'agente. Questo accesso in ingresso è separato dall'accesso dell'identità dell'agente alle risorse downstream. Vedere Accesso all'endpoint del blueprint Agent e Configurare l'accesso al blueprint Agent.

Foundry usa il blueprint per autenticare le operazioni del ciclo di vita delle identità e ottenere i token di accesso per le identità associate in fase di esecuzione. Non è necessario configurare un segreto client o un certificato per questo flusso.

Foundry effettua il provisioning di una credenziale di identità federata sul blueprint dell'identità dell'agente per l'autenticazione gestita dal servizio. Il servizio Agent lo usa durante lo scambio di token di runtime. Per il modello di credenziali sottostante, vedere Credenziali blueprint dell'identità dell'agente.

Per l'oggetto Microsoft Entra sottostante e le relative proprietà, vedere Blueprint dell'identità dell'agente.

Identità agente

Un'identità agente è un service principal speciale in Microsoft Entra ID, creato in un blueprint dell'agente. Rappresenta un'istanza dell'agente quando accede alle risorse downstream. Il progetto padre è autorizzato a impersonare tale identità. Per l'oggetto di base, vedere Identità agente.

Vantaggi della sicurezza

Le identità degli agenti consentono di risolvere specifici problemi di sicurezza che gli agenti di intelligenza artificiale presentano:

  • Distinguere le operazioni eseguite dagli agenti di intelligenza artificiale dalle operazioni eseguite dalla forza lavoro, dal cliente o dalle identità del carico di lavoro.
  • Consentire agli agenti di intelligenza artificiale di ottenere l'accesso appropriato nei sistemi.
  • Impedire agli agenti di intelligenza artificiale di ottenere l'accesso a ruoli e sistemi di sicurezza critici.
  • Ridimensionare la gestione delle identità in un numero elevato di agenti di intelligenza artificiale che possono essere creati e eliminati rapidamente.

Come Foundry effettua il provisioning delle identità

Foundry crea e gestisce le identità dell'agente di Microsoft Entra durante il ciclo di vita dell'agente. Nel modello a oggetti corrente dell'agente, la creazione di un agente effettua il provisioning di un blueprint dell'agente univoco e dell'identità per la sua istanza predefinita.

Un'identità dell'agente appena creata inizia senza autorizzazioni per le risorse. Foundry non assegna automaticamente ruoli RBAC o altre autorizzazioni downstream ad esso. Tu o il tuo amministratore concedete l'accesso necessario tramite il modello di autorizzazione del servizio di destinazione. Vedere Assegnare le autorizzazioni all'identità dell'agente.

L'identità del progetto condiviso rimane disponibile per gli agenti legacy. Per le differenze tra agenti legacy, applicazioni agente e modello corrente, vedere Eseguire la migrazione dalle applicazioni agente al nuovo endpoint agente e all'esperienza di pubblicazione.

Come gli agenti usano la propria identità in fase di esecuzione

Quando uno strumento usa l'autenticazione tramite identità dell'agente, l'agente usa la relativa identità per accedere alla risorsa downstream.

Autenticazione tramite strumento gestito dal servizio

Quando l'agente chiama uno strumento, Foundry richiede un token di accesso per il servizio downstream e usa tale token per autenticare la chiamata allo strumento.

Questo metodo di autenticazione si applica agli agenti basati su prompt basati su testo e basati su voce. Gli agenti basati su voce usano la stessa identità agente per autenticare le chiamate degli strumenti mentre Foundry gestisce la sessione vocale in tempo reale e la connessione Voice Live.

Scambio di token di runtime

Per le chiamate dello strumento gestito dal servizio che usano l'autenticazione dell'identità dell'agente, uno scambio di token OAuth 2.0 in più fasi viene eseguito automaticamente tra il servizio Agent, Microsoft Entra ID e la risorsa downstream. Il servizio Agent gestisce lo scambio.

Lo scambio procede attraverso quattro fasi:

  1. Autenticazione Blueprint: Il servizio Agent presenta le credenziali OAuth del blueprint a Microsoft Entra ID. Questo passaggio dimostra che il servizio Agent è autorizzato ad agire per conto del blueprint e delle relative identità dell'agente.

  2. Rilascio di token di identità dell'agente: Microsoft Entra ID convalida le credenziali del blueprint e rilascia un token per l'identità dell'agente specifica. Questo token è distinto dai token dell'utente umano o dell'identità gestita: identifica l'agente come attore indipendente nella directory.

  3. Richiesta di token con ambito: Agent Service restituisce il token di identità dell'agente a Microsoft Entra ID e richiede un nuovo token di accesso con ambito limitato al pubblico del servizio a valle. Il gruppo di destinatari è l'identificatore di risorsa OAuth per il servizio di destinazione( ad esempio, https://storage.azure.com per Archiviazione di Azure).

  4. Chiamata allo strumento autenticato: il servizio Agent passa il token di accesso con ambito definito al server MCP o all'endpoint A2A. La risorsa downstream convalida il token e controlla le assegnazioni di ruolo RBAC dell'identità dell'agente prima di concedere o negare l'accesso.

L'audience identifica la risorsa che accetta il token, che non è necessariamente l'URL dell'endpoint dello strumento. L'autenticazione a tale risorsa non garantisce di per sé l'accesso. Per le impostazioni di connessione e la configurazione del gruppo di destinatari, vedere Autenticazione server MCP e autenticazione A2A.

Acquisizione di token nel codice dell'agente ospitato

Per gli agenti ospitati, il servizio token consente al codice di ottenere token per l'identità dell'istanza dell'agente corrente per impostazione predefinita. L'identità gestita del progetto non è disponibile per il codice dell'hosted agent. Per la selezione dell'identità, il comportamento di Azure Identity e il contratto di richiesta del token, vedere Informazioni di riferimento sul servizio token dell'agente ospitato.

Autorizzazioni e limiti di accesso

L'autenticazione identifica l'agente presso il servizio downstream. Il modello di autorizzazione del servizio determina le operazioni che l'identità può eseguire.

Accesso dell'applicazione e accesso delegato

Il modello di accesso determina quale autorità governa una chiamata allo strumento:

  • Accesso della sola applicazione: l'agente agisce con la propria autorità, senza un utente connesso. L'accesso dipende dai ruoli, dalle autorizzazioni dell'applicazione o da altri criteri di autorizzazione assegnati alla relativa identità.
  • Accesso delegato: l'agente agisce per conto dell'utente connesso. Il client necessita dell'autorizzazione per le autorizzazioni delegate richieste e l'utente deve avere accesso alla risorsa.

Per il modello di attore delegato e i requisiti di consenso, vedere Delega utente per gli strumenti e Consenso di Microsoft Entra per l'accesso delegato.

Assegnare autorizzazioni all'identità dell'agente

Il servizio downstream determina come autorizza l'accesso:

Meccanismo di autorizzazione Modalità di concessione dell'accesso
Azure RBAC (controllo degli accessi in base al ruolo) Le assegnazioni di ruolo di Azure concedono all'identità le autorizzazioni a livello di ambito di una risorsa Azure. Vedi Panoramica del controllo degli accessi in base al ruolo di Azure.
Ruoli specifici del servizio del data plane Il servizio concede l'accesso tramite le proprie assegnazioni di ruolo, ad esempio Azure Cosmos DB ruoli del piano dati. Queste non sono assegnazioni di ruolo RBAC di Azure.
Autorizzazioni dell'applicazione o ruoli dell'app Un'API concede all'identità autorizzazioni a livello di applicazione per l'accesso senza un utente connesso, se supportato. Vedere Autorizzazioni e consenso in Microsoft Entra ID.
Criteri/policy di autorizzazione specifici delle risorse Il servizio di destinazione applica i propri criteri di accesso o i controlli delle autorizzazioni all'identità autenticata. Seguire le indicazioni sull'autorizzazione di quel servizio.

Un servizio può richiedere più livelli di autorizzazione. Quando uno strumento usa l'autenticazione dell'identità dell'agente, concedere l'accesso all'identità dell'agente. Alcune connessioni agli strumenti potrebbero invece usare un'autenticazione dell'identità gestita del progetto e, in tal caso, è necessario concedere l'accesso all'identità gestita del progetto.

Applicare privilegi minimi all'identità usata per ogni chiamata allo strumento. Per Azure RBAC, preferire un ambito di risorsa o gruppo di risorse rispetto all'accesso a livello di sottoscrizione quando soddisfa le esigenze dell'agente.

Ad esempio, un agente che accede ai BLOB di Archiviazione di Azure tramite l'autenticazione dell'applicazione richiede un ruolo Azure RBAC appropriato nella risorsa di archiviazione. Un agente che esegue query Azure Cosmos DB può invece richiedere un ruolo del piano dati specifico del servizio. Questi meccanismi di autorizzazione sono separati, anche se entrambi autorizzano l'identità dell'agente.

Per le procedure di assegnazione di Azure RBAC, usare l'ID oggetto dell'identità dell'agente usata per la chiamata allo strumento come assegnatario. Vedere Assegnare ruoli Azure usando il interfaccia della riga di comando di Azure. Per l'autorizzazione del piano dati di Cosmos DB, vedere Configurare il controllo degli accessi in base al ruolo per Azure Cosmos DB.

Per le autorizzazioni coinvolte nella distribuzione dell'agente ospitato, tra cui Registro Azure Container e Application Insights, vedere Riferimento delle autorizzazioni dell'agente ospitato.

Strumenti supportati

Gli strumenti possono usare un'identità agente per l'accesso esclusivamente applicativo o come attore in una chiamata delegata. Il supporto per un tipo di accesso non implica il supporto per l'altro. La tabella seguente riepiloga le integrazioni supportate e i collegamenti alle linee guida per l'autenticazione.

Strumento o integrazione Guida e uso dell'identità dell'agente
Da agente a agente (A2A) Accesso solo tramite applicazione con l'identità dell'agente chiamante o accesso delegato quando la destinazione lo supporta. Vedi autenticazione A2A.
Azure Databricks Genie MCP Accesso per conto dell'utente con AgentOnBehalfOfUser Vedere Destinazioni e ambiti delegati supportati.
Azure DevOps MCP Accesso per conto dell'utente. Vedi Configurare la delega utente di Microsoft Entra.
agente dati di Fabric IQ Accesso on-behalf-of-user, comprese le connessioni agli endpoint privati del workspace.
ontologia Fabric IQ Accesso on-behalf-of-user agli elementi di ontologia.
Fabric IQ modello semantico di Power BI Accesso on-behalf-of-user ai modelli semantici.
Foundry IQ Accesso on-behalf-of-user con autorizzazione di origine gestita dalla piattaforma. Vedi autorizzazione origine di Foundry IQ.
Foundry MCP Accesso per conto dell'utente. Vedere Destinazioni e ambiti delegati supportati.
Microsoft Dataverse Accesso per conto dell'utente. Vedere Destinazioni e ambiti delegati supportati.
Model Context Protocol (MCP) Accesso tramite sola applicazione ai server che accettano token di identità dell'agente o accesso delegato, se supportato. Vedi Configurare l'autenticazione del server MCP.
Sentinel Data Exploration, grafo, Knowledge Objects e memoria Accesso per conto dell'utente. Vedere Destinazioni e ambiti delegati supportati.
Work IQ Calendar, Copilot, Mail, OneDrive, SharePoint, Teams, Utente e Word Accesso per conto dell'utente. Vedere Destinazioni e ambiti delegati supportati.
Work IQ MCP Accesso on-behalf-of-user con AgentOnBehalfOfUser. L'accesso solo all'applicazione e UserEntraToken le autorizzazioni non sono supportati.

L'identità dell'agente che agisce per conto dell'utente è in anteprima e richiede l'accesso all'endpoint del blueprint dell'agente. Per i requisiti degli endpoint, i tipi di autenticazione supportati, gli ambiti delegati e il consenso, vedere Configurare la delega utente per gli strumenti.

Altri strumenti e integrazioni possono usare identità o metodi di autenticazione diversi. Confermare il supporto nella documentazione dello strumento. L'autenticazione dell'identità gestita del progetto e un accesso OAuth separato non stabiliscono autonomamente l'autenticazione dell'identità dell'agente.

L'autenticazione dell'identità dell'agente non modifica i criteri di gestione o conservazione dei dati di un provider di strumenti esterni. Le chiamate a strumenti non Microsoft possono inviare dati all'esterno di servizi Microsoft. Esaminare e registrare l'accesso in base ai criteri dell'organizzazione.

Gestione e governance delle identità

Nel modello a oggetti dell'agente corrente, ogni agente ha un proprio blueprint dell'agente e un'identità di istanza predefinita dalla creazione.

Le identità dell'agente foundry vengono visualizzate nell'inventario a livello di tenant nel Interfaccia di amministrazione di Microsoft Entra, insieme alle identità di Microsoft Copilot Studio e ad altri servizi. Questo elenco consente agli amministratori di gestire gli agenti tra i servizi anziché solo all'interno di un progetto Foundry.

Le identità per agente consentono di definire l'ambito delle autorizzazioni e dell'attività di controllo per i singoli agenti. Gli agenti legacy che condividono un'identità del progetto non hanno la separazione a livello di identità; vedere la guida alla migrazione.

In questa esperienza è possibile abilitare i controlli di sicurezza predefiniti, tra cui:

  • Accesso condizionale: applicare criteri di accesso alle identità dell'agente.
  • Protezione delle identità: monitorare e proteggere le identità degli agenti dalle minacce.
  • Accesso alla rete: controllare l'accesso basato sulla rete per gli agenti.
  • Governance: gestire la scadenza, i proprietari e gli sponsor per le identità degli agenti.

Per altre informazioni sulle funzionalità di Microsoft Entra Agent ID, vedere Microsoft Entra documentazione.

Identità di progetto condivise e applicazioni dell'agente

Foundry effettua comunque il provisioning di un blueprint di agente condiviso e di un'identità dell'agente a livello di progetto. Gli agenti legacy senza un'identità univoca usano questa identità condivisa. Gli agenti appena creati ricevono invece il proprio blueprint e l'identità dell'istanza predefinita.

La migrazione da un'identità del progetto condiviso legacy o da un'applicazione Agent al modello a oggetti Agent corrente modifica l'identità dell'agente. Assegnare le autorizzazioni downstream necessarie alla nuova identità; le assegnazioni di ruolo esistenti non vengono trasferite. Vedi Eseguire la migrazione dalle applicazioni agente al nuovo endpoint agente e all'esperienza di pubblicazione.

Per le identità legacy, l'eliminazione del progetto Foundry rimuove il blueprint dell'agente condiviso e l'identità. L'eliminazione di un'applicazione agente legacy rimuove l'identità distinta dell'applicazione.

Per le distribuzioni legacy, Azure Developer CLI (azd) assegna automaticamente Foundry User all'identità dell'agente di progetto condiviso per la compatibilità. Lo scenario predefinito dell'agente ospitato non richiede questa assegnazione. Le applicazioni agente legacy hanno identità distinte che richiedono assegnazioni di ruolo manuali separate.

Importante

I ruoli di Controllo degli accessi in base al ruolo di Foundry sono stati recentemente rinominati. Foundry User, Foundry Owner, Foundry Account Owner e Foundry Project Manager erano precedentemente denominati Azure AI User, Azure AI Owner, Azure AI Account Owner e Azure AI Project Manager. È possibile che i nomi precedenti vengano visualizzati in alcune posizioni durante l'esecuzione della ridenominazione. Gli ID ruolo e le autorizzazioni di base sono invariati dalla ridenominazione.

L'assegnazione di ruolo Foundry dell'identità condivisa non concede autorizzazioni per Registro Azure Container, Application Insights o risorse personalizzate. Per le autorizzazioni specifiche delle risorse richieste dagli agenti ospitati, vedere Riferimento alle autorizzazioni degli agenti ospitati.

Contenuto correlato

  • Ultimo aggiornamento: