Accesso condizionale per gli agenti

L'accesso condizionale per gli agenti è un'estensione del motore dei criteri di accesso condizionale che controlla il modo in cui gli agenti accedono alle risorse protette da Microsoft Entra ID. Riunisce segnali in tempo reale, ad esempio il contesto dell'utente e dell'agente, il dispositivo, la posizione e le informazioni sui rischi per determinare quando consentire, bloccare o limitare l'accesso o richiedere più passaggi di verifica.

Comprendere la modalità di accesso dell'agente aiuta a individuare l'identità corretta. Un agente può agire per conto di un utente connesso, usare la propria identità agente o usare il proprio account utente agente.

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
• Proteggere gli agenti autonomi con accesso condizionale
• Proteggere gli utenti degli agenti con Accesso condizionale di Microsoft Entra

Requisiti e licenze

Microsoft Entra ID l'accesso condizionale per gli agenti richiede uno dei piani di licenza seguenti:

• Microsoft 365 E7, che include Agent 365 e Famiglia di prodotti Microsoft Entra.
• Licenza Microsoft Agent 365 abbinata a almeno Microsoft Entra P1 o Microsoft 365 E3.

Per altre informazioni, vedi Piani e prezzi di Microsoft Agent 365.

Come l'accesso condizionale valuta l'accesso dell'agente

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

Quando si applica un criterio di accesso condizionale, Microsoft Entra ID valuta i requisiti dei criteri prima di eseguire il token. Se i requisiti sono soddisfatti, Microsoft Entra ID rilascia il token. La risorsa di destinazione convalida il token e usa le relative attestazioni per prendere decisioni di autorizzazione.

Ogni token di accesso ha un soggetto e un gruppo di destinatari:

• Oggetto: identità che riceve il token.
  • Nell'accesso delegato, il token rappresenta l'utente, identificando anche l'applicazione o l'agente chiamante.
  • Nell'accesso esclusivamente tramite applicazione, l'identità dell'agente è il soggetto.
  • Nell'accesso agente-utente, l'account utente dell'agente è il soggetto.
• Destinatari: risorsa di destinazione per cui il token deve essere registrato in Entra ID. Se un soggetto accede a più risorse, in genere richiede un token separato per ogni risorsa.

L'accesso condizionale valuta sia l'oggetto che richiede l'accesso e il gruppo di destinatari a cui si accede. Valuta i criteri quando 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.

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:

Un agente può usare più di un modello di accesso. Creare criteri separati per ogni soggetto del token usato dall'agente. Un criterio destinato a un'identità agente non si applica all'account utente dell'agente e un criterio destinato all'account utente dell'agente non si applica all'identità dell'agente.

Agenti che agiscono per conto di un utente

Il modello di accesso più comune è il flusso OBO (On-behalf-of). Nel flusso OBO un utente accede a un'applicazione agente. L'agente accede alle risorse downstream con 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 connesso è l'oggetto del token in questo flusso, l'Accesso Condizionale valuta i criteri assegnati a tale utente, indipendentemente dal fatto che l'utente sia destinato direttamente, tramite un gruppo o tramite un altro meccanismo di destinazione utente supportato. La selezione di un'identità agente come oggetto del criterio non copre le richieste dell'agente effettuate per conto dell'utente.

Agenti che fungono da applicazioni

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 Proteggere gli agenti autonomi con l'accesso condizionale.

Agenti che fungono da utenti

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 che funge da ruolo di lavoro digitale con la propria cassetta postale, l'accesso alla chat e la possibilità di 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 considerati anche 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. Un modello di identità dell'agente definisce il modello di configurazione e governance per le identità dell'agente create a partire da esso. Una policy rivolta a un blueprint si applica a tutte le identità dell'agente create da quel blueprint, comprese quelle create successivamente.

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 un esempio di criteri, vedere Consentire gli agenti approvati usando attributi di sicurezza personalizzati.

Limiti e limitazioni

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 definiti tramite l'assegnazione "Utenti" non si applicano agli account utente dell'agente. Questo limite si applica sia che il criterio sia destinato a tutti gli utenti, agli utenti selezionati, ai gruppi, ai ruoli della directory o agli utenti esterni. Per proteggere gli account utente dell'agente, creare una policy destinata a "Utenti agente".
• Definizione dell'ambito di un criterio di accesso condizionale per includere o escludere l'account utente dell'agente in base all'appartenenza ai gruppi.
• 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.

Invece, per definire l'ambito dei criteri per gli utenti dell'agente, in Assegnazioni>utenti, agenti o identità del carico di lavoro selezionare Agenti e quindi impostare come destinazione tutti gli utenti dell'agente o utenti di agenti specifici.

Contenuti correlati

• Identità dell'agente di destinazione nei criteri di accesso condizionale
• Proteggere gli agenti autonomi con accesso condizionale
• Proteggere gli agenti che fungono da utenti con accesso condizionale