Sistema di AI agentica multi-tenant

Last reviewed 2026-10-16 UTC

Questo documento fornisce un'architettura di riferimento per aiutarti a progettare ed eseguire il deployment di un sistema di AI agentica multi-tenant su Google Cloud. Man mano che la tua organizzazione scala le implementazioni di AI generativa, diverse unità aziendali richiedono agenti AI specializzati che accedano a strumenti unici, seguano regole operative specifiche ed elaborino dati sensibili. Le unità aziendali potrebbero sviluppare silos di applicazioni frammentati all'interno di un'organizzazione, il che può causare un overhead operativo elevato, gravi lacune di governance e un rischio di esposizione dei dati. Questa architettura mostra come creare un sistema centralizzato che consente di fornire ai team decentralizzati funzionalità di AI autonome, mantenendo al contempo la sicurezza e la conformità unificate.

Il pubblico di destinazione di questo documento include architetti, sviluppatori e amministratori che creano e gestiscono sistemi multi-agente di livello enterprise nel cloud. Il documento presuppone che tu abbia una conoscenza di base dei concetti di AI, ML e LLM, nonché di AI agentica.

La sezione Deployment di questo documento fornisce una strategia di implementazione per aiutarti a creare ed eseguire il deployment di un sistema di AI agentica multi-tenant.

Architettura

Il seguente diagramma mostra un'architettura per un sistema di AI agentica multi-tenant che segue un modello hub and spoke. Un modello hub and spoke è un design di rete in cui un ambiente centrale, noto come hub, si connette a più ambienti isolati, noti come spoke.

Un'architettura che mostra un sistema di AI agentica multi-tenant.

L'architettura è costituita dai seguenti componenti:

Controlli di servizio VPC
L'architettura utilizza i Controlli di servizio VPC per configurare un perimetro di servizio a livello di organizzazione. Questo perimetro di servizio fornisce un confine di sicurezza rigoroso e aiuta a prevenire l'esfiltrazione di dati.
Hub di routing

L'hub di routing funge da punto di ingresso centrale per l'architettura e include i seguenti componenti:

  • Bilanciatore del carico delle applicazioni esterno: funge da punto di ingresso centrale per gli utenti esterni o interni. Il bilanciatore del carico contribuisce a garantire che solo il traffico autenticato e sicuro raggiunga il portale di frontend.
  • Google Cloud Armor e Model Armor: il bilanciatore del carico integra Cloud Armor e Model Armor per ispezionare e ripulire i prompt dannosi sul perimetro di rete. L'hub di routing utilizza Service Extensions sul bilanciatore del carico delle applicazioni esterno per integrare Model Armor direttamente nel flusso di richieste.
  • Identity-Aware Proxy (IAP): applica un modello zero trust per verificare l'identità e il contesto dell'utente prima che qualsiasi richiesta raggiunga l'applicazione.
  • Portale di frontend: un'applicazione Cloud Run serverless che funge da motore di routing per instradare le richieste al progetto tenant isolato appropriato.
Hub centrale di governance e Pannello di sicurezza

L'hub centrale di governance e sicurezza è un progetto Google Cloud dedicato che fornisce Identity and Access Management (IAM), logging, monitoraggio e sicurezza centralizzati per l'intera piattaforma. Questo hub include i seguenti componenti:

  • Security Command Center: un servizio che monitora l'intero sistema di AI agentica multi-tenant per rilevare eventuali rischi per la sicurezza.
  • IAM: un framework di controllo dell'accesso che gestisce le identità e le autorizzazioni negli hub condivisi e nei progetti tenant. Questo componente fornisce una governance centralizzata per tutte le identità umane e delle macchine.
  • Cloud Logging: un sistema che aggrega i log degli hub condivisi e dei progetti tenant isolati nell'hub centrale di governance e sicurezza.
Progetti tenant

Ogni progetto tenant è un progetto Google Cloud dedicato per ogni unità aziendale. I singoli progetti tenant sono ambienti isolati che includono i seguenti componenti:

Flusso agentico

Il sistema multi-tenant di esempio nell'architettura precedente ha il seguente flusso:

  1. La richiesta di un utente viene instradata tramite un bilanciatore del carico delle applicazioni esterno. All'interno dell'hub di routing, vengono completati questi controlli per garantire che solo il traffico autenticato e sicuro raggiunga il portale frontend:
    1. Cloud Armor applica policy di sicurezza per assorbire eventuali attacchi distributed denial of service (DDoS) iniziali basati su protocollo di rete di livello 4. Cloud Armor ispeziona la richiesta e filtra il traffico dannoso, come SQL injection (SQLi), cross-site scripting (XSS) e firme di bot note.
    2. Model Armor intercetta il payload per rilevare e rifiutare attacchi di prompt injection o intenti dannosi.
    3. Se uno di questi livelli rileva una minaccia o un accesso non autorizzato, il bilanciatore del carico rifiuta la richiesta sul perimetro della rete.
    4. Se i livelli di sicurezza non rilevano minacce e convalidano l'accesso dell'utente, il bilanciatore del carico instrada il traffico al servizio di backend.
  2. Se la richiesta supera tutti i controlli, il bilanciatore del carico la indirizza alla piattaforma di frontend, che esegue le seguenti azioni:
    1. Estrae l'identità dell'utente, ad esempio l'unità aziendale o l'ID tenant dell'utente.
    2. Utilizza IAP per verificare l'identità aziendale dell'utente e lo stato del dispositivo.
    3. Utilizza un registry gestito dinamicamente per identificare il tenant di destinazione corretto.
  3. Il portale frontend instrada la richiesta al tenant. Per garantire che l'agente non possa accedere ad altri progetti tenant o a servizi Google Cloudnon autorizzati, Agent Runtime utilizza una policy PAB per limitare le risorse a cui l'agente può accedere.
  4. Model Armor utilizza Sensitive Data Protection per ispezionare e mascherare dinamicamente qualsiasi informazione che consente l'identificazione personale (PII) o contenuto con limitazioni. Model Armor esegue un controllo aggiuntivo per rilevare prompt injection dannose dalla richiesta, per garantire che l'agente elabori solo dati sicuri.

  5. Gemini esegue le seguenti attività per generare una risposta:

    1. Esegue un passaggio di ragionamento iniziale per comprendere l'intent dell'utente.
    2. Se Gemini determina che non dispone di informazioni specifiche, genera un piano per chiamare gli strumenti di dati specifici del tenant:
      1. Per verificare se un utente dispone dell'autorizzazione per accedere alle risorse di dati, l'agente verifica l'identità dell'utente e le associazioni dei ruoli IAM.
      2. Per recuperare il contesto, l'agente esegue una chiamata allo strumento tramite il server MCP al datastore del tenant.
      3. L'agente crea una risposta fondata combinando la sua logica interna con le informazioni specifiche del tenant appena recuperate.

    Se Gemini non ha bisogno di ulteriori informazioni, genera una risposta e la invia a Model Armor.

  6. Model Armor ispeziona e maschera dinamicamente eventuali PII o contenuti con limitazioni e invia la risposta sanitizzata all'agente tenant. Questa ispezione finale aiuta a garantire che non vengano divulgati dati sensibili nell'output.

  7. La risposta viene indirizzata all'utente dall'agente tenant tramite la piattaforma frontend e poi tramite il bilanciatore del carico.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti e strumenti Google Cloud e open source, scelti per la loro natura serverless, scalabilità e funzionalità di sicurezza:

  • Controlli di servizio VPC: una funzionalità di networking gestita che riduce al minimo i rischi di esfiltrazione di dati per le tue risorse Google Cloud .
  • Cloud Load Balancing: un portfolio di bilanciatori del carico globali e regionali scalabili e ad alte prestazioni.
  • Google Cloud Armor: un servizio di sicurezza di rete che offre regole di web application firewall (WAF) e aiuta a proteggersi dagli attacchi DDoS e alle applicazioni.
  • Model Armor: un servizio che protegge le tue risorse di AI generativa e agentica da prompt injection, fughe di dati sensibili e contenuti dannosi.
  • Identity-Aware Proxy (IAP): un servizio che consente un modello di accesso Zero Trust per le tue applicazioni e macchine virtuali.
  • Identity and Access Management (IAM): un sistema che consente di creare e gestire le autorizzazioni per le risorse Google Cloud .
  • Cloud Run: una piattaforma di serverless computing che consente di eseguire container direttamente sull'infrastruttura scalabile di Google.
  • Gemini Enterprise Agent Platform: una piattaforma completa che ti consente di creare, scalare, gestire e ottimizzare agenti AI di livello enterprise.
  • Gemini: una famiglia di modelli di AI multimodali sviluppati da Google.
  • Model Context Protocol (MCP): uno standard open source per connettere le applicazioni AI a sistemi esterni.
  • Cloud Logging: un sistema di gestione dei log in tempo reale con archiviazione, ricerca, analisi e avvisi.

Caso d'uso

I sistemi di AI agentica multi-tenant sono adatti alle organizzazioni aziendali che vogliono scalare i deployment di AI generativa oltre una singola applicazione. Per identificare i casi d'uso per cui questa architettura è adatta, analizza i tuoi processi aziendali e identifica i diversi team che richiedono i propri agenti AI specializzati che accedono a strumenti unici e dati sensibili. Questo approccio ti aiuta a fornire ai team decentralizzati funzionalità di AI autonome, mantenendo al contempo la sicurezza unificata e la conformità aziendale.

Di seguito è riportato un esempio di caso d'uso per un sistema di AI agentica multi-tenant.

Assistenza clienti a livello aziendale

Puoi adattare questa architettura di riferimento per fornire un'assistenza clienti basata sull'AI in diverse divisioni aziendali. Ad esempio, per supportare una divisione di elettronica e una divisione di articoli per la casa, esegui il deployment di un agente di elettronica e di un agente di articoli per la casa come due agenti separati in progetti tenant separati. Questi agenti AI specializzati fungono da assistenti intelligenti che gestiscono le richieste di assistenza specifiche della divisione accedendo a specifiche tecniche, garanzie o norme sui resi uniche. Questa automazione consente ai team di assistenza umana di concentrarsi sulle escalation dei clienti più complesse.

Per questo caso d'uso, l'architettura offre i seguenti vantaggi:

  • Isolamento rigoroso dei dati: il design multi-tenant contribuisce a garantire che le conoscenze di assistenza per ogni divisione siano rigorosamente isolate. La policy PAB fornisce misure di protezione che contribuiscono a garantire che l'identità di un agente in un tenant non possa accedere ai dati di un altro tenant.
  • Conoscenza specializzata degli agenti: poiché ogni agente risiede in un progetto tenant isolato, recupera il contesto solo dal datastore specifico della sua divisione. Questo recupero mirato contribuisce a migliorare l'accuratezza e aiuta l'agente a non confondere le policy di diverse unità aziendali.
  • Rischio ridotto tra domini: l'architettura aiuta a eliminare il rischio di esposizione dei dati tra le unità aziendali. Anche se l'identità di un agente viene compromessa, l'agente non può accedere alle risorse Google Cloud non autorizzate.

Questa architettura è ideale per le grandi organizzazioni e aziende di vendita al dettaglio che gestiscono più brand o unità aziendali distinti e che richiedono una rigorosa sovranità dei dati.

Alternative di design

Questa sezione presenta approcci di progettazione alternativi che puoi prendere in considerazione per il deployment dell'AI agentica multi-tenant in Google Cloud.

Deployment dell'accesso privato

Nell'architettura descritta in questo documento, gli utenti accedono al sistema di AI agentica multi-tenant tramite internet pubblico attraverso un bilanciatore del carico delle applicazioni esterno esposto centralmente. Se la tua organizzazione richiede un sistema che rimanga inaccessibile dalla rete internet pubblica, puoi adattare l'architettura in modo da utilizzare una delle seguenti strategie di accesso privato.

Blocca il traffico con le policy di sicurezza perimetrale

Per consentire il traffico solo dagli indirizzi IP aziendali verificati della tua organizzazione, puoi configurare le policy di sicurezza di Cloud Armor in modo da negare qualsiasi altro traffico. Questa regola di sicurezza ad alta priorità blocca tutte le richieste non autorizzate sul perimetro della rete. Per un ulteriore livello di sicurezza, puoi utilizzare IAP per richiedere una sessione di identità aziendale valida e puoi configurare le autorizzazioni IAM per tutti gli utenti.

Questo approccio ti consente di sfruttare le policy di sicurezza perimetrale di Cloud Armor per l'offload della mitigazione DDoS e del filtro WAF, come SQLi e XSS, e offre un'esperienza zero trust. Tuttavia, l'indirizzo IP frontend del bilanciatore del carico delle applicazioni esterno rimane pubblico e potrebbe non soddisfare i requisiti di conformità di alcune organizzazioni.

Instrada il traffico tramite un bilanciatore del carico delle applicazioni interno

L'architettura in questo documento utilizza un bilanciatore del carico delle applicazioni esterno, che fornisce policy Cloud Armor efficaci, funzionalità di sicurezza più avanzate e una complessità operativa inferiore rispetto ai bilanciatori del carico interni. Tuttavia, l'utilizzo di un bilanciatore del carico esterno implica che il traffico attraversi la rete internet pubblica.

Per mantenere il traffico interamente all'interno della rete Google privata, puoi utilizzare un bilanciatore del carico delle applicazioni interno. L'utilizzo di un bilanciatore del carico delle applicazioni interno supporta IAP per la verifica dell'identità. Un bilanciatore del carico delle applicazioni esterno globale valuta le policy IAP a livello perimetrale. Al contrario, un bilanciatore del carico delle applicazioni interno valuta le policy a livello di rete interna. Poiché il traffico non attraversa mai la rete internet pubblica, l'utilizzo di un bilanciatore del carico delle applicazioni interno ti aiuta a soddisfare i requisiti rigorosi di sovranità dei dati e di indirizzi IP pubblici pari a zero.

Per mantenere una bassa latenza e rispettare i requisiti di residenza dei dati regionali, esegui il deployment di un bilanciatore del carico delle applicazioni interno regionale in ogni regione principale. Con un bilanciatore del carico delle applicazioni interno regionale, instradi il traffico dagli ambienti on-premise tramite Cloud Interconnect o tramite Cloud VPN direttamente all'indirizzo IP interno del bilanciatore del carico. Un bilanciatore del carico delle applicazioni interno regionale supporta Cloud Armor regionale per la protezione WAF interna. Tuttavia, rispetto a un bilanciatore del carico delle applicazioni esterno, i bilanciatori del carico delle applicazioni interni regionali supportano un insieme limitato di policy di sicurezza di Cloud Armor, non dispongono di funzionalità di sicurezza avanzate e aumentano la complessità operativa.

Per ridurre ulteriormente la latenza e garantire l'alta affidabilità per soddisfare i requisiti di ripristino di emergenza, puoi fare il deployment di un bilanciatore del carico delle applicazioni interno tra regioni. Con un bilanciatore del carico delle applicazioni interno tra regioni, utilizzi Cloud DNS con policy di routing di geolocalizzazione per risolvere l'URL interno dell'applicazione nel bilanciatore del carico delle applicazioni interno tra regioni nella regioneGoogle Cloud più vicina all'utente. Tuttavia, una configurazione tra regioni non supporta l'integrazione con Cloud Armor.

Infrastruttura di computing

Per dare priorità a un approccio serverless-first che semplifica la gestione e riduce l'overhead operativo, l'architettura in questo documento utilizza Cloud Run per la sua infrastruttura di computing. Puoi anche eseguire applicazioni containerizzate su cluster GKE. Google Kubernetes Engine (GKE) è un motore di orchestrazione dei container che automatizza il deployment, la scalabilità e la gestione delle applicazioni containerizzate. GKE supporta completamente i bilanciatori del carico delle applicazioni sia interni che esterni. Per informazioni su come scegliere un servizio di computing per i tuoi workload su Google Cloud, consulta Hosting di applicazioni suGoogle Cloud.

Server MCP locali e condivisi

Per consentire ai componenti del tuo sistema di agenti di interagire, devi stabilire protocolli di comunicazione chiari. L'MCP è un protocollo aperto che fornisce un'interfaccia standardizzata per consentire agli agenti di accedere e utilizzare gli strumenti, i dati e altri servizi necessari.

Per connettere gli agenti tenant al datastore, considera i requisiti della tua applicazione per scegliere tra le seguenti opzioni di deployment del server MCP. Quando scegli tra deployment MCP locali e condivisi, considera i compromessi tra isolamento dei dati ed efficienza operativa.

  • Server MCP locale: un server MCP locale o un server MCP specifico per il tenant è un server MCP di cui esegui il deployment all'interno di ogni progetto tenant e che fornisce agli agenti l'accesso ai datastore e agli strumenti specifici per l'unità aziendale.

    Di seguito sono riportate le funzionalità e le considerazioni principali per i server MCP locali:

    • Rete: un perimetro dei Controlli di servizio VPC a livello di progetto e una policy PAB forniscono sicurezza e isolamento intrinseci, contribuendo a garantire l'assenza di accesso tra tenant.
    • Gestione: i singoli team di sviluppo e operativi gestiscono i progetti tenant in modo indipendente. Questo isolamento garantisce l'autonomia di ogni unità aziendale.
    • Sicurezza: i confini IAM fissi del progetto tenant aiutano a ridurre al minimo le superfici di rischio laterali e non richiedono mappature di identità complesse.

    I server MCP locali offrono il massimo isolamento e possono gestire l'accesso a dati altamente sensibili o regolamentati. Tuttavia, se esegui il deployment di più server MCP locali, il carico operativo aumenta. Consigliamo i server MCP locali per le applicazioni che richiedono un accesso restrittivo ai datastore che potrebbero contenere informazioni sensibili.

  • Server MCP condiviso: un server MCP condiviso o un server MCP globale è un server MCP di cui esegui il deployment in un progetto di servizi condivisi. I server MCP condivisi forniscono l'accesso a strumenti e sistemi comuni a più tenant.

    Di seguito sono riportate le funzionalità e le considerazioni principali per i server MCP condivisi:

    • Rete: per garantire che il traffico non attraversi la rete internet pubblica, i server MCP condivisi richiedono una connettività privata, come Private Service Connect o il peering di rete VPC.
    • Gestione: un team operativo centralizzato gestisce l'implementazione per l'intero sistema. Questa gestione consolidata ottimizza l'efficienza operativa ed elimina la necessità di duplicare le implementazioni locali su più tenant.
    • Sicurezza: propaghi in modo sicuro l'identità dell'utente finale dall'agente nel progetto tenant al server MCP condiviso. Per garantire che gli utenti possano accedere o modificare solo i dati per cui dispongono dell'autorizzazione, il server MCP condiviso utilizza l'identità utente propagata per applicare controllo dell'accesso granulare dell'accesso sul sistema di backend.

    I server MCP condivisi centralizzano la gestione degli strumenti comuni, riducendo la duplicazione e ottimizzando l'efficienza operativa. Sebbene i server MCP condivisi riducano l'overhead di gestione, richiedono una logica di propagazione dell'identità e di autorizzazione solida per mantenere un accesso sicuro. Consigliamo i server MCP condivisi per le interazioni con i sistemi e gli strumenti aziendali comuni, come gli strumenti di generazione dei report sulle spese, i sistemi di risorse umane (RU), le knowledge base aziendali o i gestori delle presenze.

In questa architettura, utilizzi i server MCP per standardizzare la connessione tra gli agenti tenant e i datastore. A seconda dei requisiti del tuo workload, potresti utilizzare altri tipi di strumenti per gli agenti per connetterli con API e sistemi esterni specifici. Per ulteriori informazioni sulle interazioni degli strumenti dell'agente, consulta Strumenti dell'agente.

Considerazioni sulla progettazione

Le sezioni seguenti descrivono i fattori di progettazione, le best practice e i consigli da considerare quando utilizzi questa architettura di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti specifici di sicurezza, affidabilità, costi e prestazioni. Le indicazioni riportate in questa sezione non sono esaustive. A seconda dei requisiti del tuo workload e dei prodotti e delle funzionalità che utilizzi, potrebbero esserci ulteriori fattori di progettazione e compromessi da considerare.

Sicurezza, privacy e conformità

Questa sezione descrive le considerazioni e i suggerimenti per la progettazione di una topologia in Google Cloud che soddisfi i requisiti di sicurezza, privacy e conformità del tuo workload.

Considerazioni sulla sicurezza per gli agenti

Gli agenti AI introducono alcuni rischi per la sicurezza unici e critici che le pratiche di sicurezza convenzionali e deterministiche potrebbero non essere in grado di mitigare adeguatamente. Google consiglia un approccio per agenti AI sicuri che combina i punti di forza dei controlli di sicurezza deterministici con difese dinamiche basate sul ragionamento. Questo approccio si basa su tre principi fondamentali: supervisione umana, autonomia degli agenti attentamente definita e osservabilità. Di seguito sono riportati alcuni consigli specifici in linea con questi principi fondamentali:

  • Supervisione umana: un sistema di AI agentica potrebbe a volte non funzionare o non comportarsi come previsto. Ad esempio, il modello potrebbe generare contenuti imprecisi o un agente potrebbe selezionare strumenti inappropriati. Nei sistemi di AI agentica critici per l'attività, incorpora un flusso human-in-the-loop per consentire ai supervisori umani di monitorare, eseguire l'override e mettere in pausa gli agenti. Ad esempio, gli utenti umani possono esaminare l'output degli agenti, approvarlo o rifiutarlo e fornire ulteriori indicazioni per correggere gli errori o prendere decisioni strategiche. Questo approccio combina l'efficienza dei sistemi di AI agentica con il pensiero critico e l'esperienza di dominio degli utenti umani.
  • Identità dell'agente e accesso con privilegio minimo:
    • Fornisci a ogni agente un'identità basata su SPIFFE e associata al workload utilizzando Agent Identity. Puoi utilizzare l'identità dell'agente quando esegui il deployment degli agenti in Agent Runtime o in Cloud Run.
    • Configura le autorizzazioni per agente utilizzando le policy di accesso IAM e il controllo controllo dell'accesso di Agent Platform con IAM. Concedi a ogni agente solo le autorizzazioni necessarie per eseguire le sue attività e per comunicare con gli strumenti e con altri agenti. Per isolare ulteriormente ogni agente e limitare il potenziale impatto di una violazione della sicurezza, associa una policy PAB all'identità dell'agente.
    • Quando gli agenti devono autenticarsi con strumenti esterni o API di terze parti, utilizza il gestore di autenticazione di Agent Identity. Con questo approccio, puoi controllare centralmente i token OAuth e le chiavi API anziché dover incorporare le credenziali nel codice o nei prompt dell'agente.

  • Governance del traffico in entrata e in uscita: instrada il traffico degli agenti tramite Agent Gateway per applicare le policy di sicurezza di runtime sia ai confini in entrata che in uscita. Per informazioni sulle piattaforme di runtime che supportano Agent Gateway, consulta Runtime degli agenti supportati.

    • Da client ad agente (in entrata): esegui il deployment di Agent Gateway davanti all'Agent Runtime. Il gateway aiuta ad autenticare i chiamanti e a ispezionare i prompt in entrata in tempo reale utilizzando Model Armor.

    • Da agente a ovunque (in uscita):

      • Instrada le richieste in uscita da agente ad agente (A2A) e da agente a strumento (MCP) tramite Agent Gateway in modalità in uscita.
      • Applica policy di accesso con negazione predefinita utilizzando le policy di accesso IAM e IAP.
      • Verifica che gli agenti e gli strumenti di destinazione siano registrati in Agent Registry.
      • Ispeziona le chiamate e le risposte degli strumenti in uscita con Model Armor per prevenire l'esfiltrazione di dati, il prompt injection indiretto e l'uso improprio degli strumenti.

  • Monitoraggio: monitora il comportamento degli agenti utilizzando funzionalità di tracciamento complete che ti offrono visibilità su ogni azione intrapresa da un agente, tra cui il processo di ragionamento, la selezione degli strumenti e i percorsi di esecuzione. Per maggiori informazioni, consulta Accesso di un agente in Agent Runtime e Accesso in ADK.

Per saperne di più sulla protezione degli agenti AI, consulta Sicurezza e protezione per gli agenti AI.

Considerazioni sulla sicurezza di Virtual Private Cloud (VPC)

In questa architettura, esegui il deployment di ogni tenant in un progettoGoogle Cloud dedicato. Per creare un confine di sicurezza rigoroso, combina l'isolamento a livello di progetto tenant con la policy PAB e i Controlli di servizio VPC a livello di organizzazione.

Considerazioni sulla sicurezza IAM

Per implementare il principio del privilegio minimo, utilizza un modello di accesso basato sui ruoli. Ad esempio, puoi definire ruoli IAM personalizzati per garantire che uno sviluppatore che crea un agente in un tenant non possa accedere ai dati in un altro tenant.

Considerazioni sulla sicurezza di Cloud Armor

Cloud Armor fornisce sicurezza e protezione WAF per difendere il portale frontend da attacchi DDoS e vulnerabilità web. Un bilanciatore del carico delle applicazioni esterno globale supporta la suite completa di funzionalità perimetrali avanzate, come la gestione dei bot e Google Cloud Armor Adaptive Protection.

Se esegui il deployment di un bilanciatore del carico delle applicazioni interno regionale, Cloud Armor opera con un insieme limitato di policy WAF standard. L'insieme limitato di policy è personalizzato per i confini della rete interna e include policy come la protezione da SQLi e XSS. Per saperne di più, consulta Integrazione di Cloud Armor con altri prodotti Google.

Considerazioni sulla sicurezza di Agent Platform

Per assicurarti che le configurazioni e l'utilizzo della piattaforma degli agenti soddisfino i tuoi requisiti di sicurezza, tieni presente i seguenti suggerimenti:

  • Responsabilità condivisa: la sicurezza è una responsabilità condivisa. Agent Platform protegge l'infrastruttura sottostante e fornisce strumenti e controlli di sicurezza per aiutarti a proteggere i tuoi dati, il tuo codice e i tuoi modelli. Sei responsabile della corretta configurazione dei tuoi servizi, della gestione dei controlli degli accessi e della protezione delle tue applicazioni. Per saperne di più, consulta Responsabilità condivisa di Agent Platform.
  • Controlli di sicurezza: Agent Platform supporta i controlli di sicurezza di Google Cloud che puoi utilizzare per soddisfare i tuoi requisiti di residenza dei dati, chiavi di crittografia gestite dal cliente (CMEK), sicurezza di rete utilizzando i Controlli di servizio VPC e Access Transparency. Per saperne di più, consulta la seguente documentazione:
  • Sicurezza: i modelli di AI potrebbero produrre risposte dannose, a volte in risposta a prompt dannosi.
    • Per migliorare la sicurezza e mitigare il potenziale uso improprio del sistema di AI agentica, puoi configurare i filtri dei contenuti in modo che fungano da barriere per input e risposte dannosi. Per saperne di più, consulta Filtri di sicurezza e dei contenuti.
    • Per ispezionare e sanificare le richieste di inferenza, i prompt degli agenti, le chiamate degli strumenti e le risposte per rilevare minacce come prompt injection e contenuti dannosi, puoi utilizzare Model Armor per le chiamate API dirette al modello e per le richieste instradate tramite Agent Gateway. Model Armor ti aiuta a prevenire input dannosi, verificare la sicurezza dei contenuti, proteggere i dati sensibili, mantenere la conformità e applicare in modo coerente le policy di sicurezza.
  • Accesso ai modelli: puoi configurare policy dell'organizzazione per limitare il tipo e le versioni dei modelli di AI che possono essere utilizzati in un progetto Google Cloud . Per saperne di più, consulta Controlla l'accesso ai modelli di Model Garden.
  • Protezione dei dati: per rilevare e anonimizzare i dati sensibili nei prompt e nelle risposte e nei dati di log, utilizza l'API Cloud Data Loss Prevention. Per saperne di più, guarda questo video: Protezione dei dati sensibili nelle app di AI.

  • Endpoint dei modelli condivisi: per contribuire a prevenire gli abusi e garantire un utilizzo equo degli endpoint dei modelli condivisi, implementa una delle seguenti strategie:

    • Limitazione di frequenza a livello di tenant: applica le quote nel portale frontend per ogni tenant prima che le richieste raggiungano l'endpoint condiviso. Applica le quote seguendo questi passaggi:

      1. Estrai l'identità del tenant dal contesto IAP.
      2. Monitora l'utilizzo rispetto ai limiti predefiniti per ogni tenant utilizzando un archivio esterno come Memorystore for Redis.
      3. Rifiuta le richieste dei tenant che superano i limiti.

    • API Gateway: per applicare le quote per tenant utilizzando le chiavi API e i piani di utilizzo, implementa API Gateway prima dell'endpoint condiviso.

Considerazioni sulla sicurezza di MCP

Per assicurarti che l'implementazione di MCP soddisfi i tuoi requisiti di sicurezza, tieni presente i seguenti suggerimenti:

  • Registrazione e rilevamento degli strumenti: registra i server e gli strumenti MCP in Agent Registry in modo che gli agenti si connettano solo agli endpoint MCP inventariati e approvati dall'amministratore.
  • Controllo degli accessi e ispezione del traffico: instrada il traffico dagli agenti a MCP tramite Agent Gateway in modalità Agent-to-Anywhere (in uscita) e proteggi i server MCP (ad esempio i server MCP ospitati su Cloud Run) utilizzando IAP e le policy di accesso IAM. Configura Model Armor o le norme di governance semantica su Agent Gateway per ispezionare gli input e gli output degli strumenti MCP per l'esposizione di dati sensibili e il prompt injection indiretto.
  • Sicurezza generale dell'MCP: quando configuri gli agenti per l'utilizzo dell'MCP, assicurati che l'accesso a dati e strumenti esterni sia autorizzato, implementa controlli per la privacy come la crittografia, applica filtri per proteggere i dati sensibili e monitora le interazioni degli agenti. Per saperne di più, consulta MCP e sicurezza.

Considerazioni sulla sicurezza di Cloud Run

Per migliorare la security posture del portale frontend, dai la priorità al rendering lato server (SSR) rispetto al rendering lato client (CSR). Rispetto al CSR, l'SSR offre i seguenti vantaggi:

  • Esegue la logica dell'applicazione e gestisce i secret all'interno di un ambienteGoogle Cloud controllato.
  • Riduce la superficie di attacco lato client e aiuta a prevenire le fughe di dati sensibili nel browser non attendibile dell'utente.
  • Limita l'esposizione dei dati inviando al client solo l'HTML necessario.
  • Fornisce la codifica dell'output centralizzata per proteggersi dagli attacchi di cross-site scripting (XSS).

Considerazioni sulla sicurezza di Security Command Center

Per monitorare le minacce e applicare policy di sicurezza come l'autenticazione a più fattori (MFA) e la crittografia dei dati, utilizza gli strumenti di Security Command Center.

Altri suggerimenti sulla sicurezza

Affidabilità

Questa sezione descrive le considerazioni e i suggerimenti di progettazione per creare e gestire un'infrastruttura affidabile per il tuo deployment in Google Cloud.

Considerazioni sull'affidabilità di Cloud Load Balancing

Un bilanciatore del carico delle applicazioni esterno globale fornisce un singolo indirizzo IP Anycast che instrada automaticamente il traffico utente verso il perimetro Google geograficamente più vicino. Questa configurazione riduce la latenza tramite la terminazione Secure Sockets Layer (SSL) perimetrale. Inoltre, contribuisce a garantire l'alta affidabilità in caso di interruzione del servizio in una regione, perché reindirizza in modo intelligente il traffico ai backend regionali integri.

Considerazioni sull'affidabilità del tenant

Per tollerare o gestire gli errori a livello di agente, esegui il deployment degli agenti in progetti tenant isolati. Questo isolamento contribuisce a garantire che i problemi operativi o gli incidenti di sicurezza rimangano all'interno di una singola unità aziendale e non influiscano su altre risorse o unità aziendali.

Considerazioni sull'affidabilità di Agent Platform

Se il numero di richieste al modello supera la capacità allocata, il modello restituisce il codice di errore 429. Per i workload business-critical che richiedono un throughput costantemente elevato, puoi prenotare il throughput utilizzando il throughput riservato.

Considerazioni sull'affidabilità di Agent Runtime

Per assicurarti che le configurazioni e l'utilizzo del runtime dell'agente soddisfino i tuoi requisiti di affidabilità, tieni presente i seguenti suggerimenti:

  • Scalabilità serverless: gli agenti di cui viene eseguito il deployment su Agent Runtime scalano in modo indipendente in base alla domanda. Un picco improvviso di utilizzo in un tenant non esaurisce le risorse di computing né influisce sulla disponibilità di un agente in un altro progetto tenant.
  • Gestione degli errori: per gestire gli errori temporanei, come i limiti di frequenza del codice di errore 429, la logica di orchestrazione degli agenti utilizza il backoff esponenziale. Se viene superata una scadenza del contesto, l'agente esegue un arresto normale e segnala all'utente i progressi parziali. Ad esempio, una scadenza del contesto può essere superata a causa di chiamate agli strumenti lente, latenza delle API di terze parti, elaborazione di set di dati di grandi dimensioni o elaborazione ad alta intensità di calcolo.

Per i principi e i suggerimenti di affidabilità specifici per i workload di AI e ML, consulta Prospettiva di AI e ML: affidabilità nel Well-Architected Framework.

Efficienza operativa

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare una topologia Google Cloud che puoi gestire in modo efficiente.

Considerazioni su Google Cloud Observability

Logging e Cloud Monitoring ti consentono di monitorare l'integrità e le prestazioni dell'intera piattaforma. Puoi configurare avvisi per rilevare e risolvere i problemi in modo proattivo senza consentire l'accesso ai dati sensibili.

Considerazioni sull'efficienza operativa per tutti i prodotti dell'architettura

L'utilizzo di Agent Platform all'interno di un pattern di architettura tenant standardizzato ti consente di stabilire una base di riferimento coerente quando esegui l'onboarding di nuovi tenant. Per ridurre l'onere operativo, automatizza il processo di deployment utilizzando strumenti di Infrastructure as Code (IaC) come Terraform. Per il codice Terraform che puoi utilizzare per creare ed eseguire il deployment di un sistema di AI agentica multi-tenant, consulta la sezione Deployment di questo documento.

Per i principi e i suggerimenti di eccellenza operativa specifici per i workload di AI e ML, consulta Prospettiva di AI e ML: eccellenza operativa nel framework Well-Architected.

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare i costi di configurazione e gestione di una topologia Google Cloud creata utilizzando questa architettura di riferimento.

Considerazioni sui costi di Agent Platform

Per garantire che le configurazioni e l'utilizzo di Agent Platform soddisfino i tuoi requisiti di costo, tieni presente i seguenti suggerimenti:

  • Consumo di token: per gestire i costi ed evitare che il modello di AI superi le finestre contestuali, utilizza le seguenti strategie per gestire il contesto per il modello di AI:
    • Riassunto del contesto: anziché salvare un'intera conversazione della sessione come contesto, utilizza un modello di AI per riassumere la conversazione precedente e le informazioni meno importanti.
    • Elimina gli output: identifica e rimuovi le parti meno pertinenti o prolisse degli output degli strumenti o del contesto recuperato. Ad esempio, se hai bisogno solo dei nomi delle colonne dei tuoi dati, puoi rimuovere i metadati eccessivi da un recupero dello schema del database. Questa strategia richiede una logica personalizzata che utilizza l'euristica, il filtro o un modello linguistico di piccole dimensioni (SLM) per estrarre le informazioni più importanti.
    • Limite massimo di token: per evitare loop infiniti e controllare i costi, applica un limite massimo di token per la sessione.

  • Endpoint del modello: per gestire le quote dell'API e l'utilizzo delle risorse, puoi eseguire il deployment degli endpoint di Agent Platform in una configurazione dedicata o in una configurazione condivisa:

    • Endpoint dedicati: quando esegui il deployment degli endpoint all'interno di ogni progetto tenant, fornisci un isolamento intrinseco della quota. L'utilizzo di ogni tenant viene conteggiato rispetto alle quote del proprio progetto, il che impedisce l'impatto tra tenant. Rispetto agli endpoint condivisi, gli endpoint dedicati offrono una gestione più semplice delle quote. Tuttavia, gli endpoint dedicati ti impediscono di usufruire dei potenziali risparmi sui costi di un endpoint condiviso.
    • Endpoint condivisi: per ottimizzare i costi, puoi ospitare un endpoint condiviso nell'hub centrale di governance e Pannello di sicurezza. Poiché tutti i tenant condividono lo stesso pool di quote, per contribuire a prevenire attacchi dannosi devi implementare strategie di mitigazione come la limitazione di frequenza a livello di tenant o l'applicazione delle quote con API Gateway. Rispetto agli endpoint dedicati, gli endpoint condivisi sono più convenienti. Tuttavia, gli endpoint condivisi richiedono un impegno di progettazione aggiuntivo e possono introdurre latenza e overhead di gestione.

    Per informazioni sui costi su Agent Platform, consulta Costo della creazione e del deployment di modelli di AI in Agent Platform.

Considerazioni sui costi di Cloud Run

La strumentazione ti consente di monitorare le prestazioni, risolvere i problemi e monitorare l'utilizzo delle risorse per ogni tenant. Per identificare il tenant per ogni richiesta, estrai l'identità utente dal contesto fornito da IAP. Per informazioni su come instrumentare l'applicazione, consulta Scegli un approccio di strumentazione.

Considerazioni sui costi di Model Armor

Per applicare una governance rigorosa e una postura Zero Trust, questa architettura esegue il deployment di Model Armor su due livelli: nell'hub di routing e all'interno di ogni progetto tenant. Sebbene questo approccio a due livelli contribuisca a garantire la sovranità dei dati, aumenta la latenza e i costi operativi. Per ridurre i costi e la complessità del sistema, filtra tutti i prompt e le risposte eseguendo il deployment di Model Armor esclusivamente nell'hub di routing.

Considerazioni sui costi per tutti i prodotti dell'architettura

Per assicurarti che la tua architettura soddisfi i requisiti di costo, tieni presente i seguenti suggerimenti generali:

  • Infrastruttura condivisa: i componenti dell'infrastruttura di base condivisi, come il portale di frontend, il pannello di sicurezza e governance centrale e Agent Platform, possono ridurre i costi rispetto alla creazione di uno stack personalizzato separato per ogni agente.

  • Overhead della piattaforma: per distribuire i costi condivisi dell'hub centrale di governance e del pannello di sicurezza, utilizza un modello di allocazione adatto alle tue capacità di monitoraggio e ai tuoi modelli di utilizzo. Ti consigliamo di utilizzare uno dei seguenti modelli di allocazione dei costi:

    • Allocazione con suddivisione uniforme: un modello di suddivisione uniforme alloca i costi condivisi in modo uniforme tra tutti i tenant. Utilizza questo modello quando la piattaforma è un'utilità di base o quando l'overhead del monitoraggio granulare supera i vantaggi in termini di costi.
    • Allocazione proporzionale: un modello proporzionale o un processo di chargeback alloca i costi condivisi in base alla proporzione dei costi diretti sostenuti da ciascun tenant. Utilizza questo modello quando il consumo dei tenant varia drasticamente e disponi di una telemetria solida, come le etichette di Resource Manager e l'analisi dei log, per attribuire i costi in modo accurato.
    • Allocazione fissa: un modello fisso o a livelli alloca i costi condivisi in base a coefficienti definiti dall'azienda. Utilizza questo modello quando i tenant richiedono accordi sul livello del servizio (SLA) diversi. Un'allocazione del modello fissa ti consente di addebitare tariffe fisse per le funzionalità dedicate premium rispetto alle funzionalità condivise standard.

    Per ulteriori informazioni su come distribuire i costi dei servizi condivisi, consulta Cloud FinOps: distribuzione dei costi dei servizi condivisi.

  • Gestione centralizzata dei costi: per monitorare con precisione il costo totale di proprietà (TCO) del tuo sistema di AI agentica e attribuire i costi alle singole unità aziendali, utilizza le etichette e i dati di esportazione della fatturazione Cloud. Per saperne di più su come utilizzare le etichette per la consapevolezza dei costi, consulta Promuovi una cultura della consapevolezza dei costi.

Per stimare il costo delle tue risorse Google Cloud , utilizza il Calcolatore prezzi diGoogle Cloud .

Per i principi e i suggerimenti di ottimizzazione dei costi specifici per i workload di AI e ML, consulta Prospettiva di AI e ML: ottimizzazione dei costi nel Well-Architected Framework.

Deployment

Per eseguire il deployment di questa architettura di riferimento, utilizza l'esempio di Terraform per l'AI agentica multi-tenant disponibile su GitHub.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: