Accesso condizionale per gli agenti

L'accesso condizionale è un motore di criteri intelligente che consente alle organizzazioni di controllare il modo in cui gli utenti e gli agenti accedono alle risorse aziendali. Riunisce segnali in tempo reale, ad esempio il contesto dell'utente e dell'agente, il dispositivo, la posizione e le informazioni sul rischio di sessione per determinare quando consentire, bloccare o limitare l'accesso o richiedere più passaggi di verifica.

L'accesso condizionale per gli agenti richiede Microsoft Entra ID P1 o P2 e una licenza Microsoft Agent 365 per ogni utente. L'applicazione delle licenze per Agent 365 entrerà presto in vigore. I controlli di rete per gli agenti richiedono Accesso a Internet Microsoft Entra. Per altre informazioni, vedere Che è Microsoft Entra Agent ID.

Informazioni sull'accesso condizionale per gli agenti:

• Panoramica generale dell'accesso condizionale: Che cos'è l'accesso condizionale?
• Guida alla gestione delle identità degli agenti nell'organizzazione: gestire le identità degli agenti nell'organizzazione.
• Come selezionare come destinazione le identità degli agenti in Accesso condizionale
• Configurare i criteri per l'accesso autonomo agli agenti

Come l'accesso condizionale valuta le richieste di accesso degli agenti

Per accedere a una risorsa aziendale, ad esempio SharePoint file, server MCP o servizi OPEN API, un utente o un agente richiede innanzitutto un token di accesso da Microsoft Entra ID.

Quando si applica un criterio di accesso condizionale, Microsoft Entra ID valuta i requisiti dei criteri configurati prima di rilasciare il token. Se i requisiti sono soddisfatti, viene rilasciato un token di accesso. Il token viene quindi presentato alla risorsa di destinazione, che convalida il token e usa le relative attestazioni per prendere decisioni di autorizzazione.

Il diagramma seguente illustra questo processo.

Modalità di utilizzo di soggetti e destinatari

Microsoft Entra ID rilascia un token di accesso a un soggetto per un gruppo di destinatari specifico (risorsa). Ogni token di accesso ha esattamente un soggetto e un gruppo di destinatari.

Oggetto: identità che riceve il token.

• Negli scenari di accesso delegato, il token rappresenta l'utente, identificando anche l'applicazione o l'agente chiamante.
• Negli scenari di sola applicazione, l'applicazione o l'agente autonomo è l'oggetto.
• Negli scenari relativi all'account utente dell'agente, l'account utente dell'agente è il soggetto.

Destinatari: la risorsa di destinazione a cui è destinato il token.

• La risorsa deve essere registrata in Microsoft Entra ID.
• Se un soggetto deve accedere a più risorse (ad esempio, più server MCP o API), in genere richiede un token di accesso separato per ogni risorsa, ognuno con i propri destinatari e autorizzazioni.

I criteri di accesso condizionale vengono valutati in base all'oggetto che richiede l'accesso e al gruppo di destinatari a cui si accede.

Come vengono prese le decisioni relative all'accesso condizionale

I criteri di accesso condizionale funzionano come istruzioni if-then:

• Se vengono soddisfatte le condizioni definite in un criterio, vengono applicati i controlli di accesso configurati.
• Se i controlli necessari vengono soddisfatti, viene concesso l'accesso.
• Se i controlli richiesti non sono soddisfatti, l'accesso viene negato.

Ad esempio, un'organizzazione può richiedere l'autenticazione a più fattori prima che un utente possa autorizzare un agente ad accedere alla posta elettronica. Analogamente, un'organizzazione può configurare un criterio per bloccare l'accesso dagli agenti identificati come ad alto rischio.

Quando viene valutato l'accesso condizionale

L'accesso condizionale viene valutato ogni volta che Microsoft Entra ID emette o aggiorna un token di accesso. Alcune risorse supportano anche la valutazione dell'accesso continuo, che può attivare l'imposizione quasi in tempo reale per eventi specifici.

Modelli di accesso dell'agente

Gli agenti possono accedere alle risorse protette da Microsoft Entra usando uno dei modelli seguenti:

Agenti che agiscono per conto di un utente

Il modello di accesso più comune è il flusso OBO (On-behalf-of). In questo flusso, un utente accede a un'applicazione agente e l'agente accede alle risorse downstream usando l'identità dell'utente e le autorizzazioni delegate. Ad esempio, quando un agente legge i messaggi di posta elettronica, accede alla cassetta postale per conto dell'utente. Per ulteriori informazioni su come funziona il flusso OBO per gli agenti, vedere Flussi OAuth per gli agenti: On-behalf-of.

In questo flusso, l'agente non può riutilizzare il token originale dell'utente perché è stato rilasciato per un gruppo di destinatari diverso. L'agente usa invece il flusso OBO per scambiare token con Microsoft Entra ID, ottenendo un nuovo token limitato alla risorsa di destinazione. Questo scambio di token viene valutato anche dall'accesso condizionale, consentendo agli amministratori di applicare controlli granulari su quali agenti di risorse possono accedere per conto dell'utente.

Poiché l'utente è l'oggetto di questo flusso, i criteri di accesso condizionale sono destinati a utenti e gruppi, non alle identità dell'agente. Per la configurazione dettagliata dei criteri, vedere Accesso condizionale per gli agenti che operano per conto di un utente.

Agenti che fungono da applicazione

Gli agenti possono accedere alle risorse senza un utente connesso. In questo caso, l'agente accede alla risorsa con la propria identità. Questo flusso è noto anche come flusso di credenziali client o accesso solo alle app. Tutti i tipi di agenti possono usare questo flusso. Per altre informazioni su come gli agenti eseguono l'autenticazione con la propria identità, vedere Flussi OAuth dell'agente: app autonome.

Questo flusso si applica negli scenari comuni seguenti:

• Gli agenti autonomi che operano in modo indipendente vengono eseguiti in background, rispondono agli eventi o vengono eseguiti in base a una pianificazione.
  • Ad esempio, un agente che genera un report giornaliero e invia il risultato a un gruppo di dipendenti.
  • In questo scenario non è presente alcun utente e l'agente opera autonomamente.
• Gli agenti interattivi che usano la propria identità non accedono sempre alle risorse per conto di un utente; a volte usano la propria identità.
  • Ad esempio, se un agente chiama un servizio SMS di back-end a cui gli utenti non hanno accesso, il flusso OBO non è applicabile e l'agente esegue l'autenticazione direttamente in quanto tale.
• Gli agenti pubblicati sul Web per uso pubblico non autenticano l'utente o non supportano la delega del contesto dell'utente alle risorse aziendali.

In questi scenari, l'agente richiede un token di accesso usando la propria identità agente e le credenziali gestite tramite il progetto di identità dell'agente. Il token viene rilasciato all'identità dell'agente (non all'utente). Pertanto, i criteri di accesso condizionale hanno come ambito l'identità dell'agente anziché l'utente. Per la configurazione dettagliata dei criteri, vedere Accesso condizionale per agenti autonomi.

Agenti che agiscono come utente

A volte non è sufficiente che un agente esegua attività per conto di un utente o funzioni con la propria identità. In alcuni scenari, un agente ha il proprio account utente dell'agente. Ad esempio, i lavoratori digitali che funzionano come membri del team con le proprie cassette postali, l'accesso alla chat e possono partecipare a flussi di lavoro collaborativi come membro del team.

In questo modello, un amministratore crea un account utente nella directory e lo collega all'identità dell'agente. Da qui, è come qualsiasi altro account utente. Le licenze possono essere assegnate per accedere alle risorse Microsoft 365, ad esempio una cassetta postale e un calendario. L'account può essere aggiunto a unità amministrative e gruppi di sicurezza proprio come un account utente umano.

Gli agenti che usano questo flusso sono talvolta chiamati "digital worker" o "teammate di intelligenza artificiale". Sono anche considerati agenti autonomi perché non implicano un'interfaccia utente per l'interazione umana. In questo modello, il token di accesso viene rilasciato all'account utente dell'agente (oggetto del token) e i criteri vengono valutati rispetto all'account utente dell'agente, non all'identità dell'agente. Per la configurazione dettagliata dei criteri, vedere Accesso condizionale per agenti autonomi. Per altre informazioni sul flusso OAuth dell'utente dell'agente, vedere Flusso OAuth dell'utente dell'agente.

Gli agenti in esecuzione in endpoint gestiti come Windows 365 Cloud PC per agenti possono anche essere soggetti a criteri di conformità dei dispositivi e a controlli di rete basati sulla conformità. Usare la condizione Ambienti di esecuzione agente (anteprima) per definire l'ambito di questi criteri solo per le sessioni basate su endpoint. Per altre informazioni, vedere Richiedere un dispositivo conforme per gli account utente degli agenti.

Criteri di accesso condizionale e modelli di identità degli agenti

Oltre ai modelli di accesso agli agenti specifici, è anche possibile selezionare progetti di identità agente per applicare criteri di accesso condizionale a una classe di agenti. Ogni identità dell'agente deriva da un progetto di identità agente, che ne definisce la configurazione e il modello di governance. L'applicazione di un criterio a livello di progetto copre automaticamente tutte le identità dell'agente derivate, incluse quelle nuove aggiunte in futuro. La destinazione del progetto di identità dell'agente non riguarda gli account utente degli agenti.

Il diagramma seguente mostra che solo le identità dell'agente associate al progetto "A" vengono concesse l'accesso; tutti gli altri agenti vengono esclusi e bloccati.

Si supponga, ad esempio, di avere più agenti, ognuno con uno scopo specifico. Alcuni operano in modo indipendente, mentre altri collaborano con altri agenti (A2A) per completare le attività. Se vengono tutti creati nello stesso progetto, un singolo criterio applicato a tale progetto applica controlli di accesso coerenti nell'intera raccolta.

Accesso condizionale basato su attributi

Con l'aumentare del numero di identità degli agenti, gestirle singolarmente in ogni policy diventa insostenibile. Gli attributi di sicurezza personalizzati consentono di classificare le identità e le risorse dell'agente con etichette specifiche dell'azienda, quindi assegnare tali attributi ai criteri di accesso condizionale. I criteri si applicano automaticamente a ogni agente con attributi corrispondenti, inclusi quelli aggiunti in futuro.

Per una procedura dettagliata completa sulla creazione di attributi di sicurezza personalizzati e sull'uso in un criterio di accesso condizionale, vedere Accesso condizionale per gli agenti autonomi.

Limiti e limitazioni dell'accesso condizionale

I criteri di accesso condizionale non si applicano quando:

• Un progetto di identità agente acquisisce un token per Microsoft Graph per creare un'identità agente o l'account utente dell'agente.
  • I progetti di Agent hanno funzionalità limitate. Non possono agire in modo indipendente per accedere alle risorse e sono coinvolti solo nella creazione di identità agente e account utente degli agenti.
  • Le attività dell'agente vengono sempre eseguite dall'identità dell'agente.
• Un progetto di identità agente o un'identità agente esegue uno scambio di token intermedio nell'endpoint AAD Token Exchange Endpoint: Public (ID risorsa: fb60f99c-7a34-4190-8149-302f77469936).
  • I token con ambito AAD Token Exchange Endpoint: Public non possono chiamare Microsoft Graph.
  • I flussi dell'agente sono protetti perché l'accesso condizionale protegge l'acquisizione di token dall'identità dell'agente o dall'account utente dell'agente.
• Le impostazioni predefinite per la sicurezza sono abilitate.
• L'accesso condizionale protegge solo le risorse protette da Microsoft Entra ID. Ad esempio, se un agente accede alle risorse usando una chiave API, ignora completamente la pipeline di autenticazione e rilascio di token Microsoft Entra ID e i criteri di accesso condizionale non verranno applicati.

Le configurazioni seguenti non sono attualmente supportate:

• I criteri destinati a tutti gli utenti non includono gli account utente dell'agente.
• Definizione dell'ambito di un criterio di accesso condizionale per includere o escludere l'account utente dell'agente in base all'appartenenza al gruppo
• I criteri di accesso condizionale destinati alle identità dell'agente non si applicano all'account utente dell'agente.
• Un criterio di accesso condizionale rivolto alle identità agente che usa il blueprint di identità agente si applica solo all'identità agente, non all'account utente dell'agente.

Passaggi successivi

• Come selezionare come destinazione le identità agente in Accesso condizionale
• Configurare i criteri per l'accesso dell'agente autonomo