Considerazioni per i sistemi agenti multi-tenant

Gli agenti sono applicazioni basate sull'intelligenza artificiale che usano un modello linguistico per ragionare sull'obiettivo di un utente, intraprendere azioni per conto dell'utente chiamando strumenti, accedere e archiviare lo stato e adattarne il comportamento in base ai risultati. In un ambiente multi-tenant, gli agenti richiedono particolare attenzione. Se non si è attenti, potrebbero usare strumenti al di fuori dei limiti del tenant e accedere ai dati in modi che inavvertitamente trapelano dati specifici del tenant.

Questo articolo descrive alcune delle aree principali da considerare quando si progetta un sistema agentico multi-tenant, soprattutto per quanto riguarda l'isolamento del tenant. Non è una guida alla progettazione, ma fornisce invece considerazioni e misure di sicurezza da esaminare durante il processo di progettazione e prima che un sistema agentico multi-tenant venga completato e rilasciato.

Che cosa sono gli agenti?

Un agente è un'applicazione che esegue un ciclo iterativo di ragionamento e azione. L'utente fornisce un obiettivo, che l'agente tenta quindi di raggiungere tramite una combinazione di tecniche:

• Ragionamento basato su modelli di intelligenza artificiale. Interpreta gli obiettivi e le dichiarazioni dell'utente, decide le azioni successive e pianifica come raggiungere l'obiettivo complessivo.
• Chiamata di strumenti. Recupera informazioni da sistemi come database, richiama azioni in altri sistemi e genera contenuto o risposte.
• Osservare gli output. Interpreta gli output degli strumenti e dei passaggi di ragionamento, li confronta con l'obiettivo e pianifica i passaggi successivi.
• Ripetizione fino a quando non viene soddisfatta una condizione di fine. Le condizioni finali tipiche includono:
  • Quando l'agente è soddisfatto del raggiungimento dell'obiettivo.
  • Quando l'agente richiede più input dall'utente per continuare.
  • Quando l'applicazione raggiunge un limite predefinito per turni di conversazione, utilizzo dei token, tempo trascorso o un'altra risorsa.

Multitenancy e agenti

Quando si progettano agenti in una soluzione multi-tenant, tenere presente le posizioni in cui l'agente potrebbe lavorare con dati specifici del tenant o richiedere in altro modo un contesto tenant attivo. Se non si presta attenzione, i dati del tenant e i dati di utilizzo potrebbero fuoriuscire o sovrapporsi. Il diagramma seguente illustra diverse posizioni in cui il rischio di perdita di dati del tenant è particolarmente elevato:

1. Identità agente: L'identità di un agente multi-tenant ha in genere le autorizzazioni per funzionare in più tenant, ma non comprende intrinsecamente il contesto del tenant. Applicare i limiti nel codice deterministico, non nell'identità.

2. Comportamento e decisioni del modello: Il comportamento del modello è intrinsecamente imprevedibile e non è possibile basarsi sul modello per propagare il tenant o il contesto utente anche se il modello sembra comportarsi correttamente nei test. Come per altre operazioni critiche per la sicurezza, impostare e propagare l'ID del tenant solo nel codice deterministico.

3. Invocazione degli strumenti: Quando l'agente passa il contesto del tenant agli strumenti, un gateway per gli strumenti (in questo caso, Gestione API di Azure) funge da controllo di accesso e può essere configurato per garantire che il contesto venga passato a ogni strumento in token a prova di manomissione.

4. Invocazione del subagente e passaggio di consegne dell'agente: Se il tuo agente invoca un altro agente o gli passa il controllo, utilizza una logica deterministica per trasferire il contesto del tenant e dell'utente tra gli agenti e convalida ogni transizione da un tenant singolo a un ambiente multi-tenant o viceversa.

5. Archivi dati: Verificare che ogni archivio dati applichi l'isolamento del tenant prima che l'agente legga o scriva dati o conoscenze.

Nella parte restante di questo articolo vengono descritti in modo più dettagliato questi rischi e mitigazioni.

Piattaforme per agenti

Poiché gli agenti sono applicazioni, è possibile compilarli completamente e ospitarli come applicazioni normali. Questo approccio offre flessibilità, ma richiede che l'utente si assuma la responsabilità di una serie di problemi, molti dei quali non sono specifici della logica dell'applicazione.

Gli agenti tendono ad avere responsabilità e requisiti simili, quindi è comune usare un framework agente o una piattaforma agente. I framework e le piattaforme dell'agente gestiscono alcune delle responsabilità, lasciandoti concentrarsi sul problema aziendale che l'agente ha lo scopo di risolvere.

I framework agente sono SDK che creano applicazioni agente. Il framework fornisce un comportamento predefinito.

Le piattaforme ospitate, come Foundry Agent Service, contribuiscono ad accelerare la distribuzione dei tuoi agenti, a ridurre al minimo la quantità di codice boilerplate che devi scrivere e a ridurre le tue responsabilità relative all'archiviazione e alla gestione dei dati. Tuttavia, è necessario verificare che la piattaforma offra il livello di controllo necessario. Molte piattaforme agentitiche non sono basate sulla multi-tenancy. È necessario valutarli per capire se è possibile soddisfare i requisiti, incluso soddisfare eventuali requisiti normativi o di conformità.

Approcci alla distribuzione degli agenti

Esistono due approcci di distribuzione generali per gli agenti in una soluzione multi-tenant:

• Agenti multitenant. Un agente multi-tenant viene distribuito come singola applicazione, con un singolo endpoint, con cui gli utenti di più tenant interagiscono.

  Un agente multitenant deve essere consapevole del tenant. Se si configurano misure di protezione appropriate, può operare con dati e strumenti per un singolo tenant. Applicare vincoli in modo deterministico nei punti di confine critici, inclusi i passaggi tra agenti e durante l'invocazione degli strumenti.

  Gli agenti multi-tenant tendono a essere relativamente semplici da distribuire, ma sono più difficili da implementare a causa del livello di isolamento del tenant richiesto. A seconda della piattaforma dell’agente che utilizzi, potresti avere o meno il controllo sull’isolamento di determinati aspetti, come l’invocazione degli strumenti e lo stato.

• Agenti dedicati a singolo tenant. Un agente single-tenant è dedicato a un singolo tenant. Potrebbe ricevere un ampio accesso ai dati o agli strumenti di quello specifico tenant. Può essere semplice configurare le protezioni del tenant in un agente a tenant singolo perché è possibile incorporarle nella configurazione dell'agente anziché compilare la logica condizionale.

  Tuttavia, gli agenti a tenant singolo introducono complessità operative su larga scala. È necessario definire, distribuire, versione e gestire un'istanza separata dell'agente per ogni tenant. Se si usano piattaforme agente ospitate, è necessaria una strategia per creare, aggiornare e gestire in modo efficiente le distribuzioni specifiche del tenant.

In una soluzione multi-tenant, è comune utilizzare sia agenti multi-tenant sia agenti a tenant singolo. Ad esempio, un agente multi-tenant potrebbe rispondere a domande sui dati del tenant archiviati nel sistema, mentre gli agenti a tenant singolo si integrano con i sistemi back-end di ogni tenant.

Configurazione specifica del tenant

Le soluzioni multi-tenant spesso consentono ai tenant di personalizzare il comportamento degli agenti per soddisfare i requisiti aziendali, di conformità e operativi. Considera la configurazione specifica del tenant come dati con ambito limitato al tenant. Applicare gli stessi controlli di isolamento, autorizzazione e gestione del ciclo di vita usati per altri dati del tenant.

L'elenco seguente fornisce esempi comuni di posizioni in cui viene usata la configurazione specifica del tenant. Valutare se i tenant possono avere requisiti diversi per ognuno di questi elementi:

• Strumenti e integrazioni abilitati, incluse le API esterne, i server MCP (Model Context Protocol) e gli endpoint Agent2Agent (A2A)
• Selezione del modello o parametri del modello
• Origini delle informazioni e impostazioni di recupero
• Criteri di conservazione della memoria
• Flussi di lavoro di approvazione per azioni sensibili
• Funzionalità sperimentali abilitate

Convalidare questa configurazione prima di esporre strumenti o agenti e non consentire al modello di selezionare o modificare la configurazione, gli endpoint, le credenziali o il contesto del tenant.

Evitare di consentire alle scelte di configurazione di un tenant di influire sull'esperienza di un altro tenant. Ad esempio, assicurarsi che i flag di funzionalità, le autorizzazioni degli strumenti e le impostazioni di recupero dati vengano valutati nel contesto del tenant corrente.

Quando la configurazione influisce sull'accesso ai dati, sulle decisioni di autorizzazione o sull'esecuzione degli strumenti, applicare la configurazione tramite controlli deterministici anziché basarsi su richieste o istruzioni dell'agente.

Identità

Gli agenti possono funzionare in modo autonomo o semi-autonomo per conto degli utenti. Prendere in considerazione l'identità usata per accedere ai dati e ai sistemi, incluse le credenziali e l'autorizzazione. I due approcci comuni sono le identità degli agenti e l'accesso delegato.

• Identità agente: L'agente ha una propria identità indipendente, che concede le autorizzazioni ai dati o ai sistemi separatamente da qualsiasi identità utente.

  Se possibile, usare modelli di identità appositamente progettati per gli agenti. Preferisce le identità gestite o federate anziché le credenziali di lunga durata. La riduzione dei requisiti di gestione delle credenziali può migliorare la sicurezza e aumentare la semplicità operativa.

  Quando utilizzi un'identità dell'agente con un agente multitenant, progetta l'intero flusso della richiesta in modo da isolare i tenant. Un'identità agente stabilisce chi è l'agente e quali risorse può accedere, ma non determina i dati del tenant a cui l'agente è autorizzato ad accedere. Propagare e applicare il contesto del tenant in tutto il flusso di richiesta usando codice deterministico anziché basarsi sull'identità stessa.

  Preferisce le progettazioni che riducono l'ambito delle autorizzazioni concesse a qualsiasi identità dell'agente singolo. I limiti di autorizzazione più piccoli possono contribuire a limitare l'impatto dei difetti di autorizzazione o degli errori di configurazione.

  Caution

  L'identità di un agente potrebbe avere autorizzazioni in più tenant o nelle risorse del tenant per poter svolgere il proprio lavoro. Spetta all'utente assicurarsi che tali autorizzazioni non consentano di oltrepassare i confini del tenant.

  In Azure è consigliabile usare le identità dell'agente Microsoft Entra per autenticare un agente.

• Delega: L'agente usa un token di accesso delegato per chiamare API downstream o altri sistemi per conto dell'utente. L'agente può accedere ai dati e ai sistemi a cui l'utente ha accesso.

  Il flusso OAuth On-Behalf-Of (OBO) è un esempio di un modello di autorizzazione delegata. In altri modelli di delega, l'utente potrebbe essere in grado di limitare l'agente a un subset delle autorizzazioni o dei dati dell'utente.

  Questo tipo di identità consente di applicare controlli di accesso utente e tenant. Può semplificare l'autorizzazione perché il contesto e le autorizzazioni del tenant dell'utente sono disponibili per i sistemi downstream. Tuttavia, l'isolamento multi-tenant deve comunque essere garantito tramite autorizzazioni esplicite e controlli di accesso alle risorse basati sul contesto del tenant.

  In Azure è consigliabile usare le identità dell'agente Microsoft Entra con il flusso OAuth OBO per l'autorizzazione delegata.

Scelta di un modello di identità

I sistemi agenti comportano spesso più identità all'interno di un singolo flusso di richiesta:

• Identità utente. Utente che ha avviato la richiesta.
• Identità delegata. Le autorizzazioni concesse per conto dell'utente, ad esempio tramite la delega OAuth o i flussi OBO.
• Identità dell'agente Identità del carico di lavoro utilizzata dall'agente stesso.

Queste identità possono coesistere all'interno dello stesso flusso di lavoro e soddisfare scopi diversi.

Selezionare il modello di identità in base a chi è autorizzato a eseguire l'azione.

Gli approcci di identità e delega dell'agente possono essere usati insieme in parti diverse di una soluzione. Ad esempio, un agente potrebbe accedere ai documenti tenant usando l'identità dell'utente, ma usarne la propria identità per archiviare lo stato del flusso di lavoro o generare dati di telemetria.

È opportuno applicare le decisioni di autorizzazione utilizzando un contesto tenant esplicito, anziché presumere il tenant in base al tipo di identità utilizzato. Per l'accesso autorizzato dall'utente ai dati del tenant, preferire modelli di autorizzazione delegata, ad esempio la delega OAuth o i flussi OBO, anziché concedere l'accesso generale alla propria identità dell'agente.

Strategia di isolamento delle identità

Dopo aver selezionato un modello di autorizzazione, scegliere un'architettura di identità allineata ai requisiti operativi e di isolamento. Diverse architetture multi-tenant usano modelli di isolamento delle identità diversi. Alcuni sistemi usano un'identità dell'agente multi-tenant condivisa e si basano sull'autorizzazione e sul partizionamento delle risorse. Altri usano identità a livello di tenant o distribuzioni dedicate per migliorare l'isolamento. Questi approcci possono migliorare l'isolamento, ma spesso introducono complessità operative aggiuntive.

Considerare le strategie di isolamento seguenti:

Nessuna architettura di identità singola è appropriata per tutti i sistemi agenti multi-tenant. Man mano che aumentano i requisiti di isolamento, molte soluzioni passano dalle identità multi-tenant condivise verso le identità con ambito tenant o le distribuzioni dedicate. Questi approcci possono ridurre l'impatto dei difetti di autorizzazione o degli errori di configurazione, ma in genere aumentano la complessità operativa.

Gestione delle autorizzazioni

I sistemi multi-tenant basati su agenti possono creare una complessa matrice di autorizzazioni, soprattutto se si distribuiscano più agenti o si utilizzi un insieme di identità di agenti specifiche del tenant. Ogni agente potrebbe dover accedere a strumenti e risorse diversi e tali autorizzazioni devono essere concesse separatamente per ogni tenant.

Per gestire questa complessità, seguire queste linee guida:

Richiesta di inserimento e convalida dell'input

Gli agenti usano spesso l'input fornito dall'utente per selezionare strumenti, recuperare informazioni ed eseguire azioni. In una soluzione multi-tenant, richieste dannose o accidentali potrebbero tentare di accedere ai dati appartenenti a un altro tenant. Analogamente, qualsiasi contenuto inviato a un modello come contesto può potenzialmente contenere tentativi di oltrepassare i confini tra tenant, inclusi i risultati della chiamata di strumenti, la memoria e i documenti usati come fonti di grounding.

Considerare le richieste come input non attendibile. Convalidare tutte le richieste che influenzano l'accesso ai dati, il recupero, la chiamata allo strumento o l'esecuzione di azioni prima di eseguire l'operazione. Usare Prompt Shields in Content Safety e progettare anche l'architettura complessiva per garantire che gli agenti non possano accedere ai sistemi o ai dati che non hanno bisogno.

Richiamo dello strumento

Gli strumenti sono in genere API, applicazioni da riga di comando o altre interfacce strutturate che forniscono l'accesso ai dati o alle funzionalità di un altro sistema. Molti strumenti vengono implementati per essere deterministici ed è possibile testarli in isolamento dagli agenti che li usano. È anche possibile usarli in altre applicazioni oltre agli agenti.

In un ambiente multi-tenant è possibile avere uno o entrambi i tipi di strumenti seguenti:

• Strumenti specifici per tenant: Alcuni strumenti sono specifici per un singolo tenant o per un sottoinsieme di tenant. Ad esempio, un sistema di elaborazione finanziaria multi-tenant può usare uno strumento specifico del tenant per generare e inviare fatture per conto di tale tenant. È importante che la disponibilità degli strumenti sia limitata al contesto del tenant attuale. Un agente deve essere in grado di individuare e richiamare solo gli strumenti autorizzati per il tenant corrente.

• Strumenti condivisi: Altri strumenti vengono condivisi tra tenant, ma richiedono un contesto tenant valido per tutto il flusso di richiesta. Ad esempio, uno strumento di ricerca di documenti potrebbe cercare una Knowledge Base condivisa, ma filtrare in base al tenant.

  L'agente deve assicurarsi che venga fornito il contesto del tenant appropriato. Il contesto del tenant deve essere derivato dallo stato dell'applicazione attendibile o dai token di sicurezza anziché dal contenuto generato dal modello. Potresti derivare il contesto attraverso i token, che possono contenere attestazioni relative all'identificazione del tenant. Oppure potresti avere un altro modo per inserire un identificatore del tenant tramite i processi di chiamata degli strumenti. Verificare che questi processi siano sicuri e resistenti alle manomissioni. Ad esempio, il passaggio di un ID tenant tramite una stringa di query è un rischio per la sicurezza se l'agente si basa sulla logica dell'applicazione lato client per richiamare gli strumenti.

Individuazione degli strumenti

L'individuazione degli strumenti è il processo in base al quale l'applicazione indica all'agente quali strumenti può richiamare. La rilevazione dei tool comporta considerazioni relative alla multi-tenancy, perché l'insieme dei tool disponibili diventa un dato specifico del tenant. Considerazioni analoghe si applicano al rilevamento dinamico degli agenti, che dovrebbe anch'esso essere regolato da controlli di autorizzazione basati sul tenant.

Un tenant deve essere in grado di individuare solo gli strumenti disponibili per tale tenant. Anche se la chiamata viene bloccata in un secondo momento, l'esposizione dei metadati degli strumenti può rivelare informazioni su altri tenant, servizi o processi aziendali.

I server MCP sono un modo per esporre strumenti e origini dati esterne agli agenti. Se i tenant forniscono connessioni ai server MCP, considera tali connessioni, la relativa configurazione di autenticazione e gli strumenti che espongono come configurazione con ambito del tenant. Consentire solo server e strumenti MCP approvati per il tenant corrente.

Considerare le descrizioni degli strumenti, le annotazioni e i risultati dei server MCP remoti come input non attendibile. I metadati degli strumenti forniti dai sistemi esterni diventano parte del contesto del modello e possono influenzare il comportamento del modello. Convalidare e gestire i metadati dello strumento nello stesso modo di qualsiasi altro input del modello.

Gateway degli strumenti

Valutare l'uso di un gateway degli strumenti, ad esempio Gestione API di Azure, come livello di astrazione centralizzato per una suite di strumenti. I gateway degli strumenti possono fungere da controllori, garantendo governance e conformità e verificando che il contesto del tenant venga trasmesso a ogni strumento che lo richiede. Possono anche applicare criteri di accesso e fornire funzionalità di limitazione della frequenza delle richieste utili per applicazioni agentiche ad alta scalabilità.

Prendere in considerazione l'uso di un gateway degli strumenti centralizzato per:

• Limitare gli strumenti individuabili per ogni tenant e abilitare o disabilitare le connessioni server MCP per ogni tenant.
• Applicare l'autorizzazione prima della chiamata allo strumento.
• Convalidare i metadati dello strumento prima di essere esposti al modello.
• Controlla l'individuazione e l'attività di utilizzo degli strumenti.

Invocazione di strumenti lato client e lato server

Quando un agente chiama uno strumento, il modello di esecuzione influisce sulla possibilità di applicare il contesto del tenant. Nella chiamata allo strumento sul lato client, il codice è responsabile dell'esecuzione dello strumento e può inserire in modo deterministico il contesto del tenant prima di ogni chiamata. Per gli strumenti lato server, verificare che l'applicazione della piattaforma o dell'agente possa propagare il contesto tenant attendibile e le credenziali o la configurazione con ambito tenant a ogni chiamata. Se non è possibile, utilizzare contenitori dedicati o configurazioni separate per gli strumenti per ogni tenant. Indipendentemente dal modello di esecuzione che si utilizzi, assicurarsi che gli strumenti e la progettazione dell'agente garantiscano insieme il rispetto dei confini tra tenant. I meccanismi specifici dipendono dal framework o dalla piattaforma dell'agente.

Valutare le decisioni di autorizzazione ogni volta che viene richiamato uno strumento. Non dedurre l'autorizzazione dai passaggi precedenti nel flusso di lavoro.

Accesso alle risorse condivise

Se si distribuiscono agenti specifici del tenant, potrebbe comunque essere necessario che tali agenti accedano a risorse condivise, come un database condiviso o una base di conoscenza, tramite strumenti. In questo scenario sono disponibili diverse opzioni tra cui scegliere, in base ai requisiti di conformità e al modello operativo:

• Identità con agente singolo con strumenti in grado di identificare i tenant. Concedere all'identità dell'agente condiviso l'accesso alla risorsa condivisa e usare gli strumenti e il codice deterministico per filtrare i dati in modo appropriato per il tenant. Questo approccio semplifica le autorizzazioni, ma richiede un'attenta implementazione per evitare la perdita di dati tra tenant.

• Identità degli agenti specifiche per il tenant con accesso basato su partizione. Se la risorsa condivisa supporta il controllo degli accessi in base alla partizione (ad esempio, la sicurezza a livello di riga in un database), concedere all'identità dell'agente di ogni tenant l'accesso solo alla partizione. Questo approccio offre un isolamento sicuro, ma potrebbe richiedere la gestione delle credenziali su larga scala.

• Autorizzazione delegata. Usare le autorizzazioni utente delegate per accedere alle risorse condivise per conto di un utente. Questo approccio può ridurre la necessità di autorizzazioni generali per l'identità dell'agente e allineare il controllo di accesso alle autorizzazioni esistenti dell'utente.

Sicurezza e gestione

Per le azioni ad alto rischio, è consigliabile introdurre flussi di lavoro di approvazione prima dell'esecuzione dello strumento. Gli esempi includono transazioni finanziarie, operazioni amministrative, modifiche ai record dei clienti o azioni che influiscono sui sistemi esterni. I flussi di lavoro di approvazione umana consentono di ridurre l'impatto degli attacchi di prompt injection, degli errori di autorizzazione e del comportamento imprevisto del modello. Le approvazioni non sostituiscono i controlli deterministici di autorizzazione del tenant. Entrambi i controlli devono essere eseguiti.

Stato, memoria e persistenza

Gli agenti funzionano con più tipi di stato. Ognuno di questi tipi di stato deve essere isolato tra i tenant:

Valutare ogni archivio dati usato dall'agente e verificare che soddisfi i requisiti di isolamento del tenant. Se si usa un servizio ospitato, potrebbe astrarre i dettagli relativi alla modalità di archiviazione di alcuni dati. Verifica che il servizio fornisca i controlli di posizionamento dell'area geografica, partizionamento logico, esportazione, conservazione ed eliminazione richiesti dal tenant. In caso contrario, selezionare un altro servizio o inserire il tenant in una distribuzione a livello di area geografica o dedicata al tenant, in grado di applicare i requisiti.

Se possibile, archiviare i riferimenti ai dati del tenant anziché duplicare i dati del tenant all'interno della memoria o dello stato della conversazione dell'agente.

Per indicazioni più ampie sull'isolamento e la gestione dei dati del tenant durante il ciclo di vita, vedere Approcci architetturali per l'archiviazione e i dati nelle soluzioni multi-tenant.

Invocazione del subagente e passaggio dell'agente

È comune creare una suite di agenti specializzati, ognuno con un ruolo o un focus specifico. Ad esempio, un agente può avere accesso a informazioni o dati specializzati che consentono di rispondere a domande su un argomento, mentre un altro agente può essere ottimizzato per l'esecuzione di azioni.

Per raggiungere l'obiettivo di un utente, un agente potrebbe richiamare un subagente o passare il lavoro a un altro agente:

• Quando un agente invoca un subagente, l'agente che lo invoca delega un'attività ma mantiene la responsabilità della conversazione e del flusso di lavoro complessivo.
• In un handoff, la responsabilità per la parte successiva dell'interazione passa all'agente di destinazione.

Entrambi i modelli creano limiti in cui è necessario mantenere e convalidare il contesto del tenant. Alcuni agenti potrebbero essere dedicati a un solo tenant, mentre altri potrebbero essere multi-tenant.

Individuazione agente

Se gli agenti vengono individuati in modo dinamico, assicurarsi che l'individuazione sia mediata dalla logica di autorizzazione deterministica anziché dal ragionamento del modello. Un tenant deve essere in grado di individuare solo gli agenti installati, concessi in licenza o esplicitamente disponibili per tale tenant.

Implementare l'individuazione tramite un registro attendibile, un catalogo o un livello di orchestrazione che valuta il contesto e l'autorizzazione del tenant prima di restituire gli agenti disponibili. Considera i metadati dell'agente come informazioni a livello di tenant. Anche se la chiamata è bloccata, l'esposizione di metadati di agenti non autorizzati può rivelare informazioni su servizi, funzionalità o processi aziendali.

Agent2Agent

Il protocollo Agent2Agent (A2A) consente agli agenti di comunicare in modo standardizzato. È possibile usare A2A quando si richiama un subagente o si implementano altri modelli di collaborazione da agente a agente, ma il protocollo non determina se l'interazione è una chiamata o un handoff.

Valutare se considerare gli endpoint A2A, le impostazioni di autenticazione e i metadati dell'agente come dati con ambito tenant. Prima di ogni invocazione A2A, verificare che il tenant corrente sia autorizzato a individuare e invocare l'agente di destinazione. Scegliere l'autenticazione condivisa o individuale in base al fatto che l'operazione richieda l'identità e le autorizzazioni dell'utente e ristabilire il tenant e il contesto utente tramite logica deterministica.

Contesto del tenant e autorizzazioni

Considera ogni invocazione di un agente e ogni passaggio come un confine di attendibilità. Usare la logica deterministica per propagare e ristabilire il contesto tenant e utente dallo stato dell'applicazione attendibile anziché dal contenuto generato dal modello, dalla cronologia delle conversazioni o dalle richieste precedenti. Se un flusso passa da agenti single-tenant ad agenti multi-tenant, convalidare ogni transizione e convalidare nuovamente l'autorizzazione.

Gli utenti o i tenant possono concedere autorizzazioni diverse a agenti diversi. Ogni agente deve verificare che disponga delle autorizzazioni necessarie per eseguire l'attività e non deve presupporre che le autorizzazioni concesse a un agente precedente rimangano valide.

Le attività dell'agente asincrone o a esecuzione prolungata creano limiti di attendibilità dopo la chiamata iniziale. Verificare che tutti gli agenti e le relative attività associno il proprio lavoro al contesto del tenant.

Gestione delle risorse

Gli agenti possono usare molte risorse. In particolare, i tipi di interazioni basate sul modello incentrato sul ragionamento che gli agenti usano possono utilizzare un numero elevato di token. Alcuni modelli e piattaforme modello limitano il numero di token che una singola applicazione può usare durante un periodo di tempo definito. Se utilizzi Foundry Agent Service, consulta i limiti, le quote di utilizzo e il supporto a livello di area geografica durante la pianificazione della capacità.

Poiché gli agenti possono utilizzare un numero elevato di token, possono riscontrare problemi di prossimità rumorosi, in cui le attività di un tenant influiscono sulla capacità di usare il sistema di un altro tenant. Se un numero ridotto di tenant esaurisce il limite di token del modello, gli altri tenant non possono utilizzare l'agente.

Per gestire le risorse dell'agente in modo efficace, seguire queste linee guida:

Osservabilità e controllo

I sistemi agenti possono prendere molte decisioni e richiamare più strumenti durante una singola interazione. In un ambiente multi-tenant, mantenere i registri di audit per:

• Ogni operazione principale eseguita, tra cui l'identità utente, l'identificatore del tenant e l'identità dell'agente che l'ha eseguita.
• Invocazioni degli strumenti.
• Invocazione del subagente e operazioni di passaggio dell'agente.
• Azioni di recupero dei dati.

Se si usa Microsoft Foundry, vedere Agenti di traccia per indicazioni sulla raccolta e l'analisi dei dati di traccia.

Verifica e validazione dell'isolamento del tenant

I sistemi agentic introducono un comportamento probabilistico perché gli output del modello non sono deterministici. Un test riuscito non dimostra che i controlli di isolamento del tenant sono corretti.

Concentrarsi sui limiti deterministici anziché sul comportamento del modello. Valutare la convalida degli scenari seguenti:

• Verificare che un'identità rilasciata per un tenant non possa accedere alle risorse appartenenti a un altro tenant, anche se viene specificato un identificatore di tenant diverso.
• Verificare ogni invocazione del subagente e ogni percorso di passaggio all'agente, e accertarsi che il contesto del tenant venga ristabilito esplicitamente a ogni transizione.
• Tentare di accedere direttamente ai dati di un altro tenant sotto il livello dell'agente e verificare che i controlli di partizionamento dei tenant impediscano l'accesso.
• Esegui ripetutamente suite di test avversari e fuzz automatizzati come parte delle pipeline di distribuzione.

L'isolamento del tenant non deve dipendere dal comportamento del modello. L'isolamento deve continuare a funzionare anche quando il modello produce output imprevisti. È tuttavia necessario eseguire richieste antagoniste che tentano di accedere ai dati di un altro tenant e verificare che le richieste vengano rifiutate dai controlli autorizzazione, API o livello dati.

Contributori

Microsoft mantiene questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

• Daphne Choong | Architetto senior di soluzioni per i partner, Soluzioni per partner enterprise
• John Downs | Principal Software Engineer, Azure Patterns & Practices
• Daniel Scott-Raynsford | Senior Partner Solution Architect, Enterprise Partner Solutions

Altri contributori:

• Mamoru Kuroda | Partner Solution Architect, Enterprise Partner Solutions
• Kodai Sakabe | Architetto di soluzioni per i partner, Soluzioni per partner aziendali

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Risorse correlate

• Progettare una soluzione di inferenza RAG multi-tenant sicura
• Approcci architetturali per intelligenza artificiale e Machine Learning in soluzioni multi-tenant
• Multi-tenancy e modelli Microsoft Foundry
• Usare Gestione API di Azure in una soluzione multitenant