Delega utente per gli strumenti in Microsoft Foundry

La delega utente client consente a un agente di accedere a uno strumento o a una risorsa downstream nel contesto di un utente connesso rappresentato dal client che chiama l'agente. Il servizio downstream può applicare le autorizzazioni, l'accesso ai dati e altri criteri di autorizzazione dell'utente anziché considerare ogni chiamata di strumento come accesso solo all'applicazione.

Questo articolo è incentrato sugli scenari dell'agente con intervento dell'utente, in cui un utente connesso interagisce con un agente e l'agente accede agli strumenti a valle nel contesto dell'utente. Il servizio agente Foundry supporta più opzioni di autenticazione delegate per questi scenari. L'opzione corretta dipende dal modo in cui il chiamante raggiunge l'endpoint dell'agente, dal modo in cui il servizio downstream accetta l'autorizzazione utente e dal fatto che si stia creando una nuova configurazione o mantenendo la compatibilità con una esistente.

I client che si connettono direttamente a una toolbox, anziché tramite un agente Foundry, possono usare un accesso OAuth separato per strumento per la delega utente. L'accesso diretto alla casella degli strumenti non supporta l'accesso tramite progetto dell'agente o l'identità dell'agente che agisce per conto dell'utente.

In fase di esecuzione, la connessione dello strumento determina il modo in cui il servizio Agent ottiene una credenziale che rappresenta l'utente al servizio downstream. Il servizio downstream autorizza quindi la richiesta in base alle autorizzazioni dell'utente e ai propri criteri.

Delega dell'utente rispetto all'accesso dell'applicazione

La delega utente è appropriata quando il servizio downstream deve prendere una decisione di autorizzazione per l'utente connesso. Usare un'identità dell'applicazione o dell'agente quando l'operazione non è specifica dell'utente.

Non usare la delega utente quando ogni utente deve ricevere la stessa autorità a livello di applicazione. Al contrario, non usare un'identità dell'applicazione quando il servizio downstream deve mantenere l'autorizzazione specifica dell'utente. Il supporto di strumenti e canali può restringere le scelte disponibili. Verificare i tipi di autenticazione supportati dallo strumento selezionato prima di creare una connessione.

Opzioni di delega dell'utente

La delega utente può riutilizzare il contesto utente Microsoft Entra dalla richiesta dell'agente in ingresso o stabilire una sessione OAuth separata durante la conversazione.

Foundry IQ usa l'accesso on-behalf-of-user con il comportamento di autorizzazione di origine specifico della destinazione. Per informazioni dettagliate, vedere Autorizzazione della sorgente Foundry IQ.

Accesso per conto dell'utente

Con l'accesso on-behalf-of-user, uno strumento protetto da Microsoft Entra riceve una credenziale che rappresenta l'utente che ha chiamato l'agente. Il servizio Agent esegue lo scambio di token a valle. Il token downstream rappresenta sia l'utente che un attore che partecipa allo scambio.

Le configurazioni degli attori disponibili dipendono dallo strumento. Alcuni strumenti supportano una configurazione in cui l'audience dell'endpoint in ingresso determina l'attore in fase di esecuzione:

• Quando il token in ingresso è destinato a Foundry, Foundry è l'attore.
• Quando il token in ingresso è destinato al blueprint dell'agente, l'identità dell'agente è l'attore.

Altri strumenti supportano o richiedono una configurazione in cui l'identità dell'agente è sempre l'attore. Per questo comportamento, l'endpoint deve usare lo AgentBlueprint schema di autorizzazione e il token in ingresso deve essere destinato al blueprint dell'agente.

Foundry in qualità di attore

Foundry può agire per conto dell'utente per un set limitato di strumenti di proprietà di Microsoft. Non può farlo per server personalizzati o integrazioni di terze parti. La risorsa downstream riceve un token ottenuto tramite un'applicazione anziché un agente. Foundry non richiede un'autorizzazione aggiuntiva per interagire con gli strumenti supportati.

La stessa configurazione dell'attore consente anche all'identità dell'agente di agire per conto dell'utente quando il token in ingresso è destinato al blueprint dell'agente. Foundry agisce solo quando il token in ingresso è destinato a Foundry. Questo comportamento condizionale supporta una transizione dall'accesso Azure RBAC all'accesso al blueprint dell'agente mentre sono configurati entrambi gli schemi di autorizzazione degli endpoint. Per altre informazioni, vedere Autorizzazione dell'endpoint dell'agente.

Identità dell'agente come attore (anteprima)

L'identità dell'agente può agire per conto dell'utente quando la richiesta in ingresso è autorizzata tramite lo schema AgentBlueprint e il relativo token è destinato al blueprint dell'agente. Questo comportamento è in anteprima. Il token downstream rappresenta sia l'utente che l'agente, il che consente alla risorsa di prendere decisioni di autorizzazione sull'agente. I criteri di Accesso Condizionale di Microsoft Entra possono anche disciplinare queste chiamate agli strumenti.

L'identità dell'agente deve essere autorizzata per le autorizzazioni delegate downstream richieste. A seconda dei criteri di risorsa e tenant, questa autorizzazione può richiedere il consenso dell'utente, il consenso dell'amministratore o la preautorizzazione. Questo articolo offre una panoramica concisa del comportamento del consenso. Per il modello di consenso completo, vedere Microsoft Entra consenso per l'accesso delegato.

Questo comportamento si applica attualmente ai client di runtime diretti. I client di sviluppo di Foundry e le integrazioni di Azure servizio Bot continuano a usare l'audience Foundry e non possono usare una configurazione dell'attore basata solo sull'identità dell'agente.

Il servizio agent può selezionare l'identità dell'agente in uno dei modi seguenti:

• Usare l'identità dell'agente per ogni richiesta.
• Selezionare l'attore dal gruppo di destinatari del token in ingresso. Questo comportamento condizionale consente a Foundry di rimanere l'attore per garantire la compatibilità con i client esistenti.

Alcuni strumenti consentono solo all'identità dell'agente di essere l'attore.

Autorizzazione della sorgente Foundry IQ

Le basi di conoscenza di Foundry IQ usano un comportamento di autorizzazione specifico del target. Il servizio Agent imposta x-ms-query-source-authorization dinamicamente con il token di Azure AI Search dell'utente connesso in modo che la Knowledge Base possa applicare le autorizzazioni di origine. Questo comportamento si applica sia che la richiesta in ingresso sia destinata a Foundry sia che sia destinata al blueprint dell'agente.

Quando la richiesta dell'agente è destinata ai destinatari del progetto, il servizio agente tenta di ottenere un token di accesso per https://search.azure.com/user_impersonation per conto dell'utente. Se l'autorizzazione richiesta non è stata concessa, la chiamata allo strumento può restituire un oggetto oauth_consent_request.

Accesso OAuth nella conversazione

L'accesso OAuth nella conversazione richiede all'utente di stabilire una sessione OAuth separata durante la conversazione.

I client della casella degli strumenti diretti possono usare questo accesso OAuth separato per strumento con una connessione OAuth2. Il termine in-conversation descrive l'esperienza dell'agente; l'interfaccia esposta da un client MCP non è necessariamente conversazionale. Questo accesso a valle non sostituisce l'autenticazione del client nell'endpoint della casella degli strumenti.

L'applicazione chiamante deve supportare l'autorizzazione interattiva: visualizzare la richiesta di accesso all'utente e continuare fino al termine dell'operazione. La sola configurazione di OAuth2 non fornisce tale comportamento del client. Verificare che il client supporti questo flusso prima di affidarsi a strumenti che richiedono l'accesso utente.

La configurazione della connessione specifica gli endpoint di autorizzazione, token e aggiornamento, insieme agli ambiti richiesti dal provider. Il servizio Agent archivia e aggiorna le credenziali risultanti. Partiziona lo stato di autorizzazione in base all'utente e alla connessione, quindi le credenziali downstream di ogni utente rimangono isolate. Le applicazioni devono mantenere il contesto del chiamante necessario per questo partizionamento quando interagiscono con l'agente o si connettono direttamente a una toolbox.

Per la configurazione della connessione al toolbox e la gestione OAuth per utente, vedere Come funziona l'autenticazione del toolbox.

Comportamento del consenso

Il consenso autorizza l’uso di autorizzazioni delegate per una risorsa a valle. Non concede all'utente l'accesso ai dati che la risorsa negherebbe altrimenti. La risorsa continua a valutare le autorizzazioni dell'utente e i propri criteri di autorizzazione.

Il consenso dell'amministratore può evitare una richiesta utente interattiva. La preautorizzazione può eseguire la stessa operazione quando la risorsa downstream la supporta. Quando è necessaria l'autorizzazione interattiva, il servizio Agent può restituire un oauth_consent_request elemento di output. L'applicazione chiamante visualizza il collegamento di consenso di proprietà del prodotto e continua l'interazione dopo il consenso. Se i criteri del tenant non consentono il consenso utente, il tentativo non riesce quando l'utente tenta di completarlo. L'applicazione non raccoglie, controlla o inoltra il token di accesso downstream.

Il consenso è specifico della risorsa downstream. Ogni risorsa ha le proprie autorizzazioni e lo stato di consenso. Per altre informazioni, vedere consenso di Microsoft Entra per l'accesso delegato.

Contenuti correlati

• Panoramica dell'identità e dell'accesso per Foundry Agent Service
• Autorizzazione dell'endpoint agente in Microsoft Foundry
• Il consenso di Microsoft Entra per l'accesso delegato in Foundry
• Configurare l'autenticazione per gli strumenti di Model Context Protocol
• Come funziona l'autenticazione di Toolbox in Microsoft Foundry