Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Microsoft Entra Agent ID introduce nuovi costrutti di identità e nuovi modi di pensare ai modelli di autenticazione e autorizzazione esistenti. Per comprendere meglio come questi costrutti si integrano, è utile esaminare i modelli di distribuzione comuni dell'agente di intelligenza artificiale e come eseguono il mapping all'ID agente Microsoft Entra.
Questo articolo descrive i modelli di distribuzione comuni dell'agente di intelligenza artificiale e il relativo mapping all'ID agente Microsoft Entra. L'articolo inizia con una revisione dei concetti chiave relativi all'identità, descrive le autorizzazioni e i limiti di attendibilità e quindi illustra i modelli di distribuzione comuni.
Per indicazioni dettagliate sulla decisione sul numero di progetti e identità dell'agente da creare, vedere Pianificare l'architettura dell'identità dell'agente.
Concetti chiave
I componenti seguenti sono la base dell'ID agente di Microsoft Entra. Se non si ha familiarità, iniziare con i concetti chiave del Microsoft Entra ID Agent prima di continuare con questo articolo.
Costrutti di identità
I costrutti di identità seguenti vengono usati in tutti i modelli descritti in questo articolo:
- Progetto di identità agente: modello e base di autenticazione per una o più identità dell'agente. Contiene le credenziali e i criteri che vengono applicati a tutte le identità dell'agente create da esso.
- Entità progetto di identità agente: l'oggetto Microsoft Entra creato quando un progetto viene aggiunto a un tenant. Si tratta di ciò che acquisisce effettivamente i token, crea le identità dell'agente e viene visualizzato nei log di controllo per conto del progetto.
- Identità agente: l'identità di runtime per un agente di intelligenza artificiale specifico, con le proprie autorizzazioni per le risorse downstream.
- Account utente dell'agente: un account 1:1 facoltativo associato a un'identità agente, necessario solo quando l'agente deve accedere ai sistemi che richiedono un oggetto utente.
Modelli di autorizzazioni
Le autorizzazioni a livello di progetto e le autorizzazioni a livello di identità dell'agente servono a scopi diversi:
- Le autorizzazioni del progetto rappresentano le autorizzazioni minime condivise tra tutte le identità dell'agente create dal progetto. Usare le autorizzazioni ereditabili sul modello per far sì che tutte le identità dell'agente inizino con una baseline comune.
- Le autorizzazioni di identità agente rappresentano autorizzazioni differenziate per un agente specifico. Usare queste autorizzazioni quando agenti diversi nello stesso sistema necessitano di accesso diverso alle risorse downstream.
Per altre informazioni, vedere Configurare le autorizzazioni ereditabili per i progetti e l'autorizzazione nell'ID agente di Microsoft Entra.
Limite di attendibilità
Un limite di attendibilità si riferisce alla superficie di rischio condivisa in cui si presuppone che una singola compromissione influisca sull'intero perimetro. Gli agenti che operano su piattaforme separate, con account di servizio, segreti e segmenti di rete distinti, non condividono un confine di fiducia.
Un limite di attendibilità è una decisione di modellazione delle minacce dell'applicazione, non uno definito dall'ID agente di Microsoft Entra per l'utente.
Modelli di distribuzione
I modelli seguenti sono basati su distribuzioni di agenti reali. Ognuno descrive l'architettura dell'agente, la relativa struttura di identità e le considerazioni relative alle autorizzazioni e alla governance.
Agente singleton a basso codice
Un singolo agente che assiste con un'attività specifica, in genere basata su una piattaforma con poco codice o senza codice come Microsoft Copilot Studio. L'agente agisce sempre per conto di un utente connesso (interattivo) o agisce sempre come se stesso (autonomo).
Struttura: Un progetto → un'identità dell'agente
Anche se uno schema con una singola identità agente può sembrare ridondante, lo schema offre criteri di accesso condizionale coerenti applicati all'agente, oltre a monitoraggio, governance e voci di audit, ovvero l'infrastruttura necessaria per i sistemi multi-agente, con una configurazione minima.
Autorizzazioni: Concedi le autorizzazioni direttamente sull'identità dell'agente. Le autorizzazioni ereditabili dello schema non sono in genere necessarie per i singoli casi.
Account utente dell'agente: Non obbligatorio, a meno che l'agente non debba accedere a Exchange, Teams o a un altro sistema che richiede un oggetto utente.
Lavoratore di dominio (multi-agente sequenziale)
Più agenti interagiscono in un flusso di lavoro strettamente associato e sequenziale per soddisfare un obiettivo comune del dominio. Gli agenti condividono in genere una codebase, vengono eseguiti nello stesso ambiente di runtime (ad esempio, lo stesso spazio dei nomi o contenitore Kubernetes) e hanno lo stesso comportamento di sicurezza. Ogni agente ha responsabilità distinte e accesso diverso alle risorse downstream. Questo modello mappa all'orchestrazione sequenziale nella progettazione multi-agente.
Struttura: Un progetto → più identità dell'agente (uno per ogni ruolo agente)
L'uso di un singolo progetto è appropriato perché tutti gli agenti condividono lo stesso limite di attendibilità. Ogni agente ottiene la propria identità dell'agente in modo che le azioni possano essere attribuite a un agente specifico nei log di controllo e accesso e ognuna può contenere autorizzazioni diverse per le risorse downstream.
Esempio: un sistema di gestione dei prodotti al dettaglio ha tre agenti: inventario dei negozi, confronto dei prodotti e inventario fornitore. Tutte e tre le istanze eseguite nello stesso namespace di Kubernetes e create dallo stesso team. Usano un progetto con tre identità dell'agente, ognuna con autorizzazioni limitate alle proprie risorse.
Autorizzazioni: Impostare le autorizzazioni di base condivise come ereditabili nel progetto. Assegnare le autorizzazioni specifiche del ruolo direttamente a ogni identità dell'agente.
Account utente dell'agente: Non richiesto in genere per agenti operativi di dominio.
Orchestratore concorrente con lavoratori di dominio
Un agente di orchestrazione attiva dinamicamente diversi ruoli di lavoro di dominio in base all'attività in ingresso. Gli operatori di dominio possono funzionare su piattaforme diverse, essere gestiti da team diversi e attraversare confini di fiducia. Questo modello corrisponde all'orchestrazione simultanea nella progettazione multi-agente.
Struttura:
- Blueprint A → Identità dell'agente orchestratore
- Progetto B → identità degli agenti di lavoro dominio (una per ruolo, gruppo di confini tra affidabilità)
- Blueprint C → un altro gruppo di lavoro di dominio, se gestito da un team o una piattaforma separata
Poiché i lavoratori di dominio superano i confini di fiducia — ovvero runtime separati, segreti o team distinti — richiedono schemi distinti. Le credenziali dello schema sono delimitate al suo ambito di fiducia, quindi una compromissione in un dominio non influisce sugli agenti pari.
Identità temporanee dell'agente: Una variante di questo modello usa identità temporanee dell'agente. L'agente di orchestrazione crea un'identità dell'agente temporaneo in fase di esecuzione per facilitare un'interazione specifica( ad esempio, il coordinamento con un sottosistema di manutenzione), concede le autorizzazioni ereditate dal progetto ed elimina l'identità al termine della sessione. Questo limita il raggio dell'esplosione alla durata dell'attività.
Annotazioni
La creazione dell'identità dell'agente temporanea avviene in fase di esecuzione, che introduce una latenza non deterministica. Valutare questo compromesso per scenari sensibili alla latenza.
Autorizzazioni: Orchestrator e ogni gruppo di lavoro del dominio hanno set di autorizzazioni singolari, con ambito per i rispettivi modelli e identità dell'agente.
Account utente dell'agente: Non richiesto in genere a livello di agente di orchestrazione o di lavoro di dominio, a meno che un ruolo di lavoro di dominio specifico non debba accedere a una risorsa dipendente dall'oggetto utente.
Agenti per utente (small-n)
Viene creata un'identità dell'agente separata per ogni utente o unità organizzativa. Ad esempio, un agente analista SOC potrebbe avere un'istanza per ogni ambiente cloud o un agente di controllo potrebbe avere un'istanza per reparto. Il numero di identità degli agenti è moderato, da decine a centinaia basse, non una per utente della directory.
Struttura: Un progetto → un'identità agente per utente, reparto o ambiente
Questo modello è appropriato quando ogni istanza dell'agente necessita di autorizzazioni diverse, limiti di controllo diversi o ciclo di vita indipendente( ad esempio, l'agente per un reparto può essere disabilitato senza influire sugli altri).
Autorizzazioni: Ogni identità agente contiene autorizzazioni con ambito per l'utente o l'unità organizzativa. Le autorizzazioni ereditabili dal progetto impostano una baseline minima e a ogni identità dell'agente vengono concesse autorizzazioni aggiuntive in base alle esigenze.
Account utente dell'agente: Valutare la possibilità di associare ogni identità agente all'account utente di un agente quando ogni agente funge da rappresentante denominato per il proprio utente o reparto, ad esempio un agente di vendita dedicato che riceve posta elettronica per conto di un territorio.
Lavoratore digitale (agente autonomo)
Un agente completamente autonomo funge da dipendente digitale, fornito di risorse in genere riservate ai dipendenti umani: una cassetta postale di Exchange, uno spazio di condivisione OneDrive e una presenza su Teams. Questo è il massimo livello di autonomia dell'agente.
Struttura: Un progetto → un'identità dell'agente → account utente di un agente
Ogni lavoratore digitale richiede il proprio account utente dell'agente. La relazione 1:1 tra l'identità dell'agente e l'account utente dell'agente è fissa. Non è possibile condividere l'account utente di un agente tra più identità agente.
Esempio: un rappresentante vendite di intelligenza artificiale con una cassetta postale reale, elencata nell'elenco indirizzi globale, che risponde al messaggio di posta elettronica e viene assegnato un responsabile umano nel grafico dell'organizzazione.
Autorizzazioni: Concedere all'account utente dell'agente le autorizzazioni specifiche di Exchange, Teams e OneDrive necessarie. Concedere le autorizzazioni a livello di applicazione per l'identità dell'agente ai sistemi che non richiedono un oggetto utente. Per altre informazioni, vedere Concedere l'accesso dell'agente a Microsoft 365.
Account utente dell'agente: Obbligatorio. Creare un account utente dell'agente per ogni identità dell'agente di lavoro digitale.
Modelli da evitare
Le repliche con scalabilità orizzontale non necessitano di identità dell'agente separate
L'esecuzione di più istanze dello stesso codice agente (scale-out) non richiede identità dell'agente separate. Lo scale-out è un problema di runtime: il blueprint acquisisce i token come identità dell'agente e più istanze dell'agente possono essere eseguite contemporaneamente con la stessa identità. La creazione di un'identità agente separata per replica aggiunge oggetti directory e sovraccarico di gestione senza alcun vantaggio in termini di controllo, accesso o tracciabilità.
La gestione della memoria e del contesto non richiede identità dell'agente separate
La memoria dell'agente è in genere un archivio dati condiviso ,ad esempio Cache Redis di Azure o Ricerca di intelligenza artificiale di Azure, in cui i dati vengono filtrati in base all'ID sessione in fase di recupero. L'accesso a tale archivio dati è controllato dalle autorizzazioni dell'identità dell'agente, non da identità separate per sessione. Le identità dell'agente separate per l'isolamento della memoria aggiungono complessità senza un vantaggio di sicurezza.
Non usare le identità dell'agente scalate per singolo oggetto nella directory
La creazione di un'identità agente per riunione, per documento o per oggetto temporaneo su larga scala non è attualmente pratica oggi con le identità a livello di directory. Per scenari ad alto flusso, usare le identità dell'agente condiviso e basarsi su identificatori di sessione o contesto a livello di applicazione per distinguere le interazioni.