Système d'IA agentive mutualisé

Last reviewed 2026-10-16 UTC

Ce document fournit une architecture de référence pour vous aider à concevoir et à déployer un système d'IA agentive mutualisé sur Google Cloud. À mesure que votre organisation déploie l'IA générative, différentes unités commerciales ont besoin d'agents IA spécialisés qui accèdent à des outils uniques, suivent des règles opérationnelles spécifiques et traitent des données sensibles. Les unités commerciales peuvent développer des silos d'applications fragmentés au sein d'une organisation, ce qui peut entraîner des frais généraux élevés, de graves lacunes de gouvernance et un risque d'exposition des données. Cette architecture vous montre comment créer un système centralisé qui permet à des équipes décentralisées de bénéficier de fonctionnalités d'IA autonomes tout en maintenant une sécurité et une conformité unifiées.

Ce document s'adresse aux architectes, aux développeurs et aux administrateurs qui créent et gèrent des systèmes multi-agents de niveau entreprise dans le cloud. Dans ce document, nous partons du principe que vous possédez des connaissances de base sur les concepts d'IA, de ML et de LLM, ainsi que sur l'IA agentique.

La section Déploiement de ce document fournit une stratégie d'implémentation pour vous aider à créer et à déployer un système d'IA agentique mutualisé.

Architecture

Le schéma suivant illustre l'architecture d'un système d'IA agentique mutualisé qui suit un modèle hub-and-spoke. Un modèle en étoile est une conception de réseau dans laquelle un environnement central, appelé hub, se connecte à plusieurs environnements isolés, appelés spokes.

Architecture d'un système d'IA agentique mutualisé.

L'architecture se compose des éléments suivants :

VPC Service Controls
L'architecture utilise VPC Service Controls pour configurer un périmètre de service au niveau de l'organisation. Ce périmètre de service fournit une limite de sécurité stricte et permet d'empêcher l'exfiltration de données.
Hub de routage

Le hub de routage sert de point d'entrée central pour l'architecture et comprend les composants suivants :

  • Équilibreur de charge d'application externe : sert de point d'entrée central pour les utilisateurs externes ou internes. L'équilibreur de charge permet de s'assurer que seul le trafic authentifié et sécurisé atteint le portail d'interface.
  • Google Cloud Armor et Model Armor : l'équilibreur de charge intègre Cloud Armor et Model Armor pour inspecter et nettoyer les requêtes malveillantes à la périphérie du réseau. Le hub de routage utilise Service Extensions sur l'équilibreur de charge d'application externe pour intégrer Model Armor directement dans le flux de requêtes.
  • Identity-Aware Proxy (IAP) : applique un modèle zéro confiance pour vérifier l'identité et le contexte de l'utilisateur avant qu'une requête n'atteigne l'application.
  • Portail d'interface : application Cloud Run sans serveur qui sert de moteur de routage pour acheminer les requêtes vers le projet de locataire isolé approprié.
Hub central de gouvernance et de sécurité

Le hub central de gouvernance et de sécurité est un projet Google Clouddédié qui fournit une gestion centralisée de l'authentification et des accès (IAM), de la journalisation, de la surveillance et de la sécurité pour l'ensemble de la plate-forme. Ce hub comprend les composants suivants :

  • Security Command Center : service qui surveille l'ensemble du système d'IA agentive mutualisé pour détecter les risques de sécurité.
  • IAM : framework de contrôle des accès qui gère les identités et les autorisations sur les hubs partagés et les projets locataires. Ce composant fournit une gouvernance centralisée pour toutes les identités humaines et de machine.
  • Cloud Logging : système qui regroupe les journaux des hubs partagés et des projets locataires isolés dans le hub central de gouvernance et de sécurité.
Projets locataires

Chaque projet locataire est un projet Google Cloud dédié à chaque unité commerciale. Les projets de locataire individuels sont des environnements isolés qui incluent les composants suivants :

Flux agentique

L'exemple de système mutualisé de l'architecture précédente présente le flux suivant :

  1. La requête d'un utilisateur est acheminée via un équilibreur de charge d'application externe. Dans le hub de routage, ces vérifications sont effectuées pour s'assurer que seul le trafic authentifié et sécurisé atteint le portail d'interface :
    1. Cloud Armor applique des stratégies de sécurité pour absorber les attaques par déni de service distribué (DDoS) initiales basées sur le protocole réseau de couche 4. Cloud Armor inspecte la requête et filtre le trafic malveillant, tel que les injection SQL (SQLi), les scripts intersites (XSS) et les signatures de bots connues.
    2. Model Armor intercepte la charge utile pour détecter et rejeter les attaques par injection de prompt ou les intentions malveillantes.
    3. Si l'une de ces couches détecte une menace ou un accès non autorisé, l'équilibreur de charge supprime la requête à la périphérie du réseau.
    4. Si les couches de sécurité ne détectent aucune menace et valident l'accès de l'utilisateur, l'équilibreur de charge achemine le trafic vers le service de backend.
  2. Si la requête passe toutes les vérifications, l'équilibreur de charge l'achemine vers la plate-forme d'interface, qui effectue les actions suivantes :
    1. Extrait l'identité de l'utilisateur, par exemple son unité commerciale ou son ID de locataire.
    2. Utilise IAP pour vérifier l'identité d'entreprise de l'utilisateur et l'état de l'appareil.
    3. Utilise un registre géré de manière dynamique pour identifier le locataire cible approprié.
  3. Le portail d'interface achemine la requête vers le locataire. Pour s'assurer que l'agent ne peut pas accéder à d'autres projets locataires ou à des services Google Cloudnon autorisés, Agent Runtime utilise une stratégie PAB pour limiter les ressources auxquelles l'agent peut accéder.
  4. Model Armor utilise Sensitive Data Protection pour inspecter et masquer de manière dynamique les informations permettant d'identifier personnellement l'utilisateur ou les contenus soumis à des restrictions. Model Armor effectue une vérification supplémentaire des injections de prompts malveillants à partir de la requête pour s'assurer que l'agent ne traite que des données sécurisées.

  5. Gemini effectue les tâches suivantes pour générer une réponse :

    1. Effectue une première passe de raisonnement pour comprendre l'intention de l'utilisateur.
    2. Si Gemini détermine qu'il ne dispose pas de faits spécifiques, il génère un plan pour appeler les outils de données spécifiques du locataire :
      1. Pour vérifier si un utilisateur est autorisé à accéder aux ressources de données, l'agent vérifie l'identité de l'utilisateur et les liaisons de rôles IAM.
      2. Pour récupérer le contexte, l'agent exécute un appel d'outil via le serveur MCP vers le datastore du locataire.
      3. L'agent crée une réponse ancrée en combinant sa logique interne avec les faits spécifiques au locataire nouvellement récupérés.

    Si Gemini n'a pas besoin d'informations supplémentaires, il génère une réponse et l'envoie à Model Armor.

  6. Model Armor inspecte et masque de manière dynamique les informations permettant d'identifier personnellement l'utilisateur ou les contenus soumis à des restrictions, puis envoie la réponse nettoyée à l'agent du locataire. Cette inspection finale permet de s'assurer qu'aucune donnée sensible ne fuit dans la sortie.

  7. La réponse est renvoyée à l'utilisateur, de l'agent locataire à la plate-forme d'interface, puis à l'équilibreur de charge.

Produits utilisés

Cette architecture de référence utilise les produits et outils Google Cloud et Open Source suivants, choisis pour leur nature sans serveur, leur évolutivité et leurs fonctionnalités de sécurité :

  • VPC Service Controls : fonctionnalité de mise en réseau gérée qui minimise les risques d'exfiltration de données pour vos ressources Google Cloud .
  • Cloud Load Balancing : portefeuille d'équilibreurs de charge hautes performances, évolutifs, mondiaux et régionaux.
  • Google Cloud Armor : service de sécurité réseau qui propose des règles de pare-feu d'application Web (WAF) et aide à se protéger contre les attaques DDoS et d'applications.
  • Model Armor : service qui protège vos ressources d'IA générative et d'IA agentique contre l'injection de prompt, les fuites de données sensibles et les contenus nuisibles.
  • Identity-Aware Proxy (IAP) : service qui permet d'appliquer un modèle d'accès zéro confiance à vos applications et machines virtuelles.
  • Identity and Access Management (IAM) : système qui vous permet de créer et de gérer des autorisations pour les ressources Google Cloud .
  • Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
  • Gemini Enterprise Agent Platform : plate-forme complète qui vous permet de créer, de faire évoluer, de gérer et d'optimiser des agents IA de niveau entreprise.
  • Gemini : famille de modèles d'IA multimodaux développés par Google.
  • Model Context Protocol (MCP) : norme Open Source permettant de connecter des applications d'IA à des systèmes externes.
  • Cloud Logging : système de gestion des journaux en temps réel avec stockage, recherche, analyse et alertes.

Cas d'utilisation

Les systèmes d'IA agentique mutualisés conviennent aux entreprises qui souhaitent faire évoluer les déploiements d'IA générative au-delà d'une seule application. Pour identifier les cas d'utilisation adaptés à cette architecture, analysez vos processus métier et identifiez les différentes équipes qui ont besoin de leurs propres agents IA spécialisés, qui accèdent à des outils uniques et à des données sensibles. Cette approche vous permet de doter les équipes décentralisées de fonctionnalités d'IA autonomes tout en maintenant une sécurité unifiée et la conformité de l'entreprise.

Voici un exemple de cas d'utilisation d'un système d'IA agentique mutualisé.

Service client à l'échelle de l'entreprise

Vous pouvez adapter cette architecture de référence pour fournir un service client optimisé par l'IA dans différentes divisions de l'entreprise. Par exemple, pour prendre en charge une division électronique et une division d'articles ménagers, vous déployez un agent électronique et un agent d'articles ménagers en tant que deux agents distincts dans des projets locataires distincts. Ces agents IA spécialisés agissent comme des assistants intelligents qui gèrent les demandes d'assistance spécifiques à chaque division en accédant à des caractéristiques techniques, des garanties ou des conditions de retour uniques. Cette automatisation permet aux équipes d'assistance humaines de se concentrer sur les réclamations client plus complexes.

Pour ce cas d'utilisation, l'architecture offre les avantages suivants :

  • Isolation stricte des données : la conception mutualisée permet de s'assurer que les connaissances d'assistance de chaque division sont strictement isolées. La stratégie PAB fournit des garde-fous qui permettent de s'assurer qu'une identité d'agent d'un locataire ne peut pas accéder aux données d'un autre locataire.
  • Connaissances spécialisées de l'agent : comme chaque agent réside dans un projet locataire isolé, il ne récupère que le contexte de son datastore spécifique à la division. Cette récupération ciblée permet d'améliorer la précision et d'éviter que l'agent ne confonde les règles de différentes unités commerciales.
  • Réduction des risques interdomaines : l'architecture permet d'éliminer le risque d'exposition des données entre les unités commerciales. Même si l'identité d'un agent est compromise, l'agent ne peut pas accéder aux ressources Google Cloud non autorisées.

Cette architecture est idéale pour les grandes entreprises et les organisations de vente au détail qui gèrent plusieurs marques ou unités commerciales distinctes et qui nécessitent une souveraineté stricte des données.

Alternatives de conception

Cette section présente d'autres approches de conception que vous pouvez envisager pour votre déploiement d'IA agentique mutualisé dans Google Cloud.

Déploiement de l'accès privé

Dans l'architecture décrite dans ce document, les utilisateurs accèdent au système d'IA agentique mutualisé via l'Internet public via un équilibreur de charge d'application externe exposé de manière centralisée. Si votre organisation nécessite un système qui reste inaccessible depuis l'Internet public, vous pouvez adapter l'architecture pour utiliser l'une des stratégies d'accès privé suivantes.

Bloquer le trafic avec des stratégies de sécurité périphérique

Pour n'autoriser que le trafic provenant des adresses IP d'entreprise validées de votre organisation, vous pouvez configurer des règles de sécurité Cloud Armor afin de refuser tout autre trafic. Cette règle de sécurité hautement prioritaire bloque toutes les requêtes non autorisées à la périphérie du réseau. Pour ajouter une couche de sécurité, vous pouvez utiliser IAP pour exiger une session d'identité d'entreprise valide et configurer des autorisations IAM pour tous les utilisateurs.

Cette approche vous permet de profiter des stratégies de sécurité périphériques Cloud Armor pour décharger l'atténuation des attaques DDoS et le filtrage WAF, comme les attaques SQLi et XSS, et offre une expérience zéro confiance. Toutefois, l'adresse IP d'interface de l'équilibreur de charge d'application externe reste publique et peut ne pas répondre aux exigences de conformité de certaines organisations.

Acheminer le trafic via un équilibreur de charge d'application interne

L'architecture décrite dans ce document utilise un équilibreur de charge d'application externe, qui fournit des règles Cloud Armor robustes, des fonctionnalités de sécurité plus avancées et une complexité opérationnelle moindre par rapport aux équilibreurs de charge internes. Cependant, l'utilisation d'un équilibreur de charge externe signifie que le trafic transite par l'Internet public.

Pour que le trafic reste entièrement au sein du réseau Google privé, vous pouvez utiliser un équilibreur de charge d'application interne. L'utilisation d'un équilibreur de charge d'application interne est compatible avec IAP pour la validation de l'identité. Un équilibreur de charge d'application externe global évalue les règles IAP au niveau de la couche périphérique. En revanche, un équilibreur de charge d'application interne évalue les règles au niveau de la couche réseau interne. Comme le trafic ne transite jamais par l'Internet public, l'utilisation d'un équilibreur de charge d'application interne vous aide à respecter les exigences strictes en matière de souveraineté des données et d'absence d'adresse IP publique.

Pour maintenir une faible latence et respecter les exigences régionales de résidence des données, déployez un équilibreur de charge d'application interne régional dans chaque région principale. Avec un équilibreur de charge d'application interne régional, vous acheminez le trafic provenant d'environnements sur site via Cloud Interconnect ou Cloud VPN directement vers l'adresse IP interne de l'équilibreur de charge. Un équilibreur de charge d'application interne régional est compatible avec Cloud Armor régional pour la protection WAF interne. Toutefois, par rapport à un équilibreur de charge d'application externe, les équilibreurs de charge d'application internes régionaux sont compatibles avec un ensemble limité de stratégies de sécurité Cloud Armor, ne disposent pas de fonctionnalités de sécurité avancées et augmentent la complexité opérationnelle.

Pour réduire davantage la latence et garantir une haute disponibilité afin de répondre à vos exigences de reprise après sinistre, vous pouvez déployer un équilibreur de charge d'application interne interrégional. Avec un équilibreur de charge d'application interne interrégional, vous utilisez Cloud DNS avec des règles de routage de géolocalisation pour résoudre l'URL interne de l'application vers l'équilibreur de charge d'application interne interrégional dans la régionGoogle Cloud la plus proche de l'utilisateur. Toutefois, une configuration interrégionale n'est pas compatible avec l'intégration de Cloud Armor.

Infrastructure de calcul

Pour privilégier une approche sans serveur qui facilite la gestion et réduit les frais généraux d'exploitation, l'architecture de ce document utilise Cloud Run pour son infrastructure de calcul. Vous pouvez également exécuter des applications conteneurisées sur des clusters GKE. Google Kubernetes Engine (GKE) est un moteur d'orchestration de conteneurs qui automatise le déploiement, le scaling et la gestion des applications conteneurisées. GKE est entièrement compatible avec les équilibreurs de charge d'application internes et externes. Pour savoir comment choisir un service de calcul pour vos charges de travail sur Google Cloud, consultez Héberger des applications surGoogle Cloud.

Serveurs MCP locaux et partagés

Pour permettre aux composants de votre système d'agents d'interagir, vous devez établir des protocoles de communication clairs. MCP est un protocole ouvert qui fournit une interface standardisée permettant aux agents d'accéder aux outils, données et autres services nécessaires, et de les utiliser.

Pour connecter vos agents locataires à votre datastore, tenez compte des exigences de votre application pour choisir l'une des options de déploiement de serveur MCP suivantes. Lorsque vous choisissez entre des déploiements MCP locaux et partagés, tenez compte des compromis entre l'isolation des données et l'efficacité opérationnelle.

  • Serveur MCP local : un serveur MCP local, ou un serveur MCP spécifique à un locataire, est un serveur MCP que vous déployez dans chaque projet de locataire et qui permet aux agents d'accéder aux datastores et aux outils spécifiques à cette unité commerciale.

    Voici les principales caractéristiques et considérations concernant les serveurs MCP locaux :

    • Réseau : un périmètre VPC Service Controls au niveau du projet et une stratégie PAB fournissent une sécurité et une isolation inhérentes, ce qui permet d'éviter tout accès entre locataires.
    • Gestion : les équipes de développeurs et d'opérations gèrent les projets de locataire de manière indépendante. Cette isolation offre une autonomie à chaque unité commerciale.
    • Sécurité : les limites IAM fixes du projet locataire permettent de minimiser les surfaces de risque latéral et ne nécessitent pas de mappages d'identité complexes.

    Les serveurs MCP locaux offrent une isolation maximale et peuvent gérer l'accès aux données hautement sensibles ou réglementées. Toutefois, si vous déployez plusieurs serveurs MCP locaux, vous augmentez votre charge opérationnelle. Nous recommandons les serveurs MCP locaux pour les applications qui nécessitent un accès restrictif aux datastores pouvant contenir des informations sensibles.

  • Serveur MCP partagé : un serveur MCP partagé, ou serveur MCP global, est un serveur MCP que vous déployez dans un projet de services partagés. Les serveurs MCP partagés permettent d'accéder aux outils et aux systèmes communs à plusieurs locataires.

    Voici les principales fonctionnalités et considérations concernant les serveurs MCP partagés :

    • Réseau : pour s'assurer que le trafic ne passe pas par l'Internet public, les serveurs MCP partagés nécessitent une connectivité privée, telle que Private Service Connect ou l'appairage de réseaux VPC.
    • Gestion : une équipe d'exploitation centralisée gère la mise en œuvre pour l'ensemble du système. Cette gestion consolidée optimise l'efficacité opérationnelle et élimine la nécessité de dupliquer les implémentations locales sur plusieurs locataires.
    • Sécurité : vous propagez de manière sécurisée l'identité de l'utilisateur final de l'agent dans le projet locataire vers le serveur MCP partagé. Pour s'assurer que les utilisateurs ne peuvent accéder qu'aux données qu'ils sont autorisés à consulter ou à modifier, le serveur MCP partagé utilise l'identité utilisateur propagée pour appliquer un contrôle ultraprécis des accès sur le système de backend.

    Les serveurs MCP partagés centralisent la gestion des outils courants, ce qui réduit la duplication et optimise l'efficacité opérationnelle. Bien que les serveurs MCP partagés réduisent les frais de gestion, ils nécessitent une propagation d'identité et une logique d'autorisation robustes pour maintenir un accès sécurisé. Nous recommandons d'utiliser des serveurs MCP partagés pour les interactions avec les systèmes et outils d'entreprise courants, tels que les outils de reporting des dépenses, les systèmes de ressources humaines (RH), les bases de connaissances à l'échelle de l'entreprise ou les gestionnaires de présence.

Dans cette architecture, vous utilisez des serveurs MCP pour standardiser la connexion entre vos agents locataires et vos datastores. En fonction des exigences de votre charge de travail, vous pouvez utiliser d'autres types d'outils d'agent pour connecter vos agents à des API et des systèmes externes spécifiques. Pour en savoir plus sur les interactions entre les agents et les outils, consultez Outils d'agent.

Considérations de conception

Les sections suivantes décrivent les facteurs de conception, les bonnes pratiques et les recommandations à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, de coût et de performances. Les conseils de cette section ne sont pas exhaustifs. En fonction des exigences de votre charge de travail et des produits et fonctionnalités que vous utilisez, il peut y avoir d'autres facteurs de conception et compromis à prendre en compte.

Sécurité, confidentialité et conformité

Cette section décrit les considérations de conception et les recommandations pour concevoir une topologie dans Google Cloud qui répond aux exigences de sécurité, de confidentialité et de conformité de votre charge de travail.

Considérations de sécurité pour les agents

Les agents IA introduisent des risques de sécurité uniques et critiques que les pratiques de sécurité déterministes conventionnelles ne sont peut-être pas en mesure d'atténuer de manière adéquate. Google recommande une approche pour les agents IA sécurisés qui combine les avantages des contrôles de sécurité déterministes avec des défenses dynamiques basées sur le raisonnement. Cette approche repose sur trois principes fondamentaux : la supervision humaine, une autonomie des agents soigneusement définie et l'observabilité. Voici des recommandations spécifiques qui s'alignent sur ces principes fondamentaux :

  • Supervision humaine : un système d'IA agentive peut parfois échouer ou ne pas fonctionner comme prévu. Par exemple, le modèle peut générer du contenu inexact ou un agent peut sélectionner des outils inappropriés. Dans les systèmes d'IA agentique essentiels à l'activité, intégrez un flux human-in-the-loop (avec intervention humaine) pour permettre aux superviseurs humains de surveiller, de remplacer et de suspendre les agents. Par exemple, les utilisateurs humains peuvent examiner les résultats des agents, les approuver ou les rejeter, et fournir des conseils supplémentaires pour corriger les erreurs ou prendre des décisions stratégiques. Cette approche combine l'efficacité des systèmes d'IA agentive avec l'esprit critique et l'expertise métier des utilisateurs humains.
  • Identité de l'agent et accès de moindre privilège :
    • Fournissez à chaque agent une identité basée sur SPIFFE et liée à la charge de travail à l'aide de l'identité de l'agent. Vous pouvez utiliser Agent Identity lorsque vous déployez des agents sur Agent Runtime ou sur Cloud Run.
    • Configurez les autorisations par agent à l'aide des stratégies d'accès IAM et du contrôle des accès Agent Platform avec IAM. N'accordez à chaque agent que les autorisations dont il a besoin pour effectuer ses tâches et communiquer avec les outils et les autres agents. Pour isoler davantage chaque agent et limiter l'impact potentiel d'une brèche de sécurité, associez une stratégie PAB à l'identité de l'agent.
    • Lorsque les agents doivent s'authentifier auprès d'outils externes ou d'API tierces, utilisez le gestionnaire d'authentification Agent Identity. Cette approche vous permet de contrôler de manière centralisée les jetons OAuth et les clés API au lieu d'avoir à intégrer des identifiants dans le code ou les prompts de l'agent.

  • Gouvernance du trafic entrant et sortant : acheminez le trafic de l'agent via Agent Gateway pour appliquer des règles de sécurité d'exécution aux limites d'entrée et de sortie. Pour en savoir plus sur les plates-formes d'exécution compatibles avec Agent Gateway, consultez Environnements d'exécution d'agent compatibles.

    • Client vers agent (entrée) : déployez Agent Gateway devant votre Agent Runtime. La passerelle permet d'authentifier les appelants et d'inspecter les requêtes entrantes en temps réel à l'aide de Model Armor.

    • Agent vers n'importe quelle destination (sortie) :

      • Router les requêtes sortantes d'agent à agent (A2A) et d'agent à outil (MCP) via Agent Gateway en mode sortie.
      • Appliquez des règles d'accès de refus par défaut à l'aide des règles d'accès IAM et d'IAP.
      • Vérifiez que les agents et les outils cibles sont enregistrés dans Agent Registry.
      • Inspectez les appels et les réponses des outils sortants avec Model Armor pour empêcher l'exfiltration de données, l'injection indirecte de prompts et l'utilisation abusive des outils.

  • Surveillance : surveillez le comportement des agents à l'aide de fonctionnalités de traçage complètes qui vous permettent de suivre chaque action d'un agent, y compris son processus de raisonnement, la sélection d'outils et les chemins d'exécution. Pour en savoir plus, consultez Connexion d'un agent dans Agent Runtime et Connexion dans l'ADK.

Pour en savoir plus sur la sécurisation des agents IA, consultez Sûreté et sécurité des agents IA.

Considérations de sécurité liées au cloud privé virtuel (VPC)

Dans cette architecture, vous déployez chaque locataire dans un projetGoogle Cloud dédié. Pour créer une limite de sécurité stricte, combinez l'isolation au niveau du projet locataire avec la stratégie PAB et VPC Service Controls au niveau de l'organisation.

Points à noter concernant la sécurité IAM

Pour mettre en œuvre le principe du moindre privilège, utilisez un modèle d'accès basé sur les personas. Par exemple, vous pouvez définir des rôles IAM personnalisés pour vous assurer qu'un développeur qui crée un agent dans un locataire ne peut pas accéder aux données d'un autre locataire.

Considérations de sécurité pour Cloud Armor

Cloud Armor fournit une sécurité et une protection WAF pour défendre le portail d'interface contre les attaques DDoS et les failles Web. Un équilibreur de charge d'application externe global est compatible avec l'ensemble des fonctionnalités de périphérie avancées, telles que la gestion des bots et Google Cloud Armor Adaptive Protection.

Si vous déployez un équilibreur de charge d'application interne régional, Cloud Armor fonctionne avec un ensemble limité de règles WAF standards. L'ensemble restreint de règles est adapté aux limites du réseau interne et inclut des règles telles que la protection contre les injections SQL et les attaques XSS. Pour en savoir plus, consultez Intégrer Cloud Armor à d'autres produits Google.

Points à noter concernant la sécurité d'Agent Platform

Pour vous assurer que les configurations et l'utilisation de votre plate-forme d'agents répondent à vos exigences de sécurité, tenez compte des recommandations suivantes :

  • Responsabilité partagée : la sécurité est une responsabilité partagée. Agent Platform sécurise l'infrastructure sous-jacente et fournit des outils et des contrôles de sécurité pour vous aider à protéger vos données, votre code et vos modèles. Vous êtes responsable de la configuration de vos services, de la gestion des contrôles d'accès et de la sécurisation de vos applications. Pour en savoir plus, consultez Responsabilité partagée de la plate-forme d'agent.
  • Contrôles de sécurité : Agent Platform est compatible avec Google Cloud des contrôles de sécurité que vous pouvez utiliser pour répondre à vos exigences en matière de résidence des données, de clés de chiffrement gérées par le client (CMEK), de sécurité réseau à l'aide de VPC Service Controls et d'Access Transparency. Pour en savoir plus, consultez la documentation suivante :
  • Sécurité : les modèles d'IA peuvent produire des réponses nuisibles, parfois en réponse à des requêtes malveillantes.
    • Pour renforcer la sécurité et limiter les cas d'utilisation abusive du système d'IA agentique, vous pouvez configurer des filtres de contenu afin de bloquer les entrées et les réponses potentiellement nuisibles. Pour en savoir plus, consultez Filtres de sécurité et de contenu.
    • Pour inspecter et nettoyer les requêtes d'inférence, les prompts d'agent, les appels d'outils et les réponses afin de détecter les menaces telles que l'injection de prompt et les contenus nuisibles, vous pouvez utiliser Model Armor pour les appels d'API de modèle directs et pour les requêtes acheminées via Agent Gateway. Model Armor vous aide à empêcher les entrées malveillantes, à vérifier la sécurité du contenu, à protéger les données sensibles, à maintenir la conformité et à appliquer de manière cohérente les règles de sécurité.
  • Accès aux modèles : vous pouvez configurer des règles d'administration pour limiter le type et les versions des modèles d'IA pouvant être utilisés dans un projet Google Cloud . Pour en savoir plus, consultez Contrôler l'accès aux modèles Model Garden.
  • Protection des données : pour découvrir et anonymiser les données sensibles dans les requêtes et les réponses, ainsi que dans les données de journaux, utilisez l'API Cloud Data Loss Prevention. Pour en savoir plus, regardez cette vidéo : Protéger les données sensibles dans les applications d'IA.

  • Points de terminaison de modèle partagés : pour éviter les abus et garantir une utilisation équitable des points de terminaison de modèle partagés, mettez en œuvre l'une des stratégies suivantes :

    • Limitation du débit au niveau du locataire : appliquez des quotas dans le portail d'interface pour chaque locataire avant que les requêtes n'atteignent le point de terminaison partagé. Appliquez les quotas en procédant comme suit :

      1. Extrayez l'identité du locataire du contexte IAP.
      2. Suivez l'utilisation par rapport aux limites prédéfinies pour chaque locataire à l'aide d'un magasin externe tel que Memorystore pour Redis.
      3. Rejeter les requêtes des locataires qui dépassent leurs limites.

    • API Gateway : pour appliquer des quotas par locataire à l'aide de clés API et de plans d'utilisation, implémentez API Gateway avant le point de terminaison partagé.

Points à noter concernant la sécurité de MCP

Pour vous assurer que votre implémentation de MCP répond à vos exigences de sécurité, tenez compte des recommandations suivantes :

  • Enregistrement et découverte d'outils : enregistrez les serveurs et les outils MCP dans Agent Registry afin que les agents ne se connectent qu'aux points de terminaison MCP inventoriés et approuvés par l'administrateur.
  • Contrôle des accès et inspection du trafic : routez le trafic entre l'agent et le serveur MCP via Agent Gateway en mode Agent-to-Anywhere (sortie) et protégez les serveurs MCP (comme ceux hébergés sur Cloud Run) à l'aide d'IAP et de stratégies d'accès IAM. Configurez des règles Model Armor ou de gouvernance sémantique sur Agent Gateway pour inspecter les entrées et les sorties de l'outil MCP afin de détecter l'exposition de données sensibles et l'injection indirecte de prompt.
  • Sécurité générale du MCP : lorsque vous configurez vos agents pour qu'ils utilisent le MCP, assurez-vous que l'accès aux données et aux outils externes est autorisé, implémentez des contrôles de confidentialité tels que le chiffrement, appliquez des filtres pour protéger les données sensibles et surveillez les interactions des agents. Pour en savoir plus, consultez MCP et sécurité.

Considérations de sécurité pour Cloud Run

Pour améliorer la stratégie de sécurité du portail d'interface, privilégiez le rendu côté serveur (SSR) au rendu côté client (CSR). Par rapport au CSR, le SSR offre les avantages suivants :

  • Exécute la logique d'application et gère les secrets dans un environnementGoogle Cloud contrôlé.
  • Réduit la surface d'attaque côté client et aide à prévenir les fuites de données sensibles vers le navigateur non fiable de l'utilisateur.
  • Limiter l'exposition des données en n'envoyant que le code HTML nécessaire au client.
  • Fournit un encodage de sortie centralisé pour se protéger contre les attaques par script intersites (XSS).

Considérations de sécurité pour Security Command Center

Pour surveiller les menaces et appliquer des règles de sécurité telles que l'authentification multifacteur (MFA) et le chiffrement des données, utilisez les outils de Security Command Center.

Autres recommandations de sécurité

Fiabilité

Cette section décrit les considérations de conception et les recommandations pour créer et exploiter une infrastructure fiable pour votre déploiement dans Google Cloud.

Considérations sur la fiabilité de Cloud Load Balancing

Un équilibreur de charge d'application externe global fournit une seule adresse IP Anycast qui achemine automatiquement le trafic utilisateur vers la périphérie Google la plus proche géographiquement. Cette configuration réduit la latence grâce à la terminaison SSL (Secure Sockets Layer) périphérique. Il permet également d'assurer une haute disponibilité en cas de panne dans une région, car il redirige intelligemment le trafic vers des backends régionaux opérationnels.

Considérations sur la fiabilité des locataires

Pour tolérer ou gérer les défaillances au niveau de l'agent, déployez les agents dans des projets de locataire isolés. Cette isolation permet de s'assurer que les problèmes opérationnels ou les incidents de sécurité restent au sein d'une seule unité commerciale et n'affectent pas d'autres ressources ou unités commerciales.

Considérations relatives à la fiabilité d'Agent Platform

Si le nombre de requêtes adressées au modèle dépasse la capacité allouée, le modèle renvoie le code d'erreur 429. Pour les charges de travail critiques qui nécessitent un débit constamment élevé, vous pouvez réserver du débit à l'aide du débit provisionné.

Considérations sur la fiabilité d'Agent Runtime

Pour vous assurer que vos configurations et votre utilisation d'Agent Runtime répondent à vos exigences de fiabilité, tenez compte des recommandations suivantes :

  • Évolutivité sans serveur : les agents déployés sur Agent Runtime évoluent indépendamment en fonction de la demande. Une augmentation soudaine de l'utilisation dans un locataire n'épuise pas les ressources de calcul et n'affecte pas la disponibilité d'un agent dans un autre projet locataire.
  • Gestion des erreurs : pour gérer les erreurs temporaires telles que les limites de débit du code d'erreur 429, la logique d'orchestration de l'agent utilise un intervalle exponentiel entre les tentatives. Si un délai de contexte est dépassé, l'agent effectue un arrêt progressif et signale une progression partielle à l'utilisateur. Par exemple, un délai de contexte peut être dépassé en raison d'appels d'outils lents, de la latence de l'API tierce, du traitement d'ensembles de données volumineux ou d'un traitement nécessitant beaucoup de ressources de calcul.

Pour connaître les principes et recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez Enjeux spécifiques à l'IA et au ML : fiabilité dans le Well-Architected Framework.

Efficacité opérationnelle

Cette section décrit les facteurs à prendre en compte lorsque vous utilisez cette architecture de référence pour concevoir une topologie Google Cloud que vous pouvez exploiter efficacement.

Points à prendre en compte concernant Google Cloud Observability

Logging et Cloud Monitoring vous permettent de surveiller l'état et les performances de l'ensemble de la plate-forme. Vous pouvez configurer des alertes pour détecter et résoudre les problèmes de manière proactive sans autoriser l'accès aux données sensibles.

Considérations liées à l'efficacité opérationnelle pour tous les produits de l'architecture

L'utilisation d'Agent Platform dans un modèle d'architecture de locataire standardisé vous permet d'établir une référence cohérente lorsque vous intégrez de nouveaux locataires. Pour réduire la charge opérationnelle, automatisez le processus de déploiement à l'aide d'outils d'Infrastructure as Code (IaC) tels que Terraform. Pour obtenir le code Terraform permettant de créer et de déployer un système d'IA agentique mutualisé, consultez la section Déploiement de ce document.

Pour connaître les principes et recommandations d'excellence opérationnelle spécifiques aux charges de travail d'IA et de ML, consultez Perspective de l'IA et du ML : excellence opérationnelle dans le Well-Architected Framework.

Optimisation des coûts

Cette section fournit des conseils pour optimiser les coûts de configuration et d'exploitation d'une topologie Google Cloud que vous créez à l'aide de cette architecture de référence.

Considérations relatives aux coûts d'Agent Platform

Pour vous assurer que les configurations et l'utilisation de votre Agent Platform répondent à vos exigences de coût, tenez compte des recommandations suivantes :

  • Consommation de jetons : pour gérer les coûts et éviter que votre modèle d'IA ne dépasse les fenêtres de contexte, utilisez les stratégies suivantes pour gérer le contexte du modèle d'IA :
    • Résumé du contexte : au lieu d'enregistrer l'intégralité d'une conversation de session en tant que contexte, utilisez un modèle d'IA pour résumer les conversations plus anciennes et les informations moins critiques.
    • Élaguer les résultats : identifiez et supprimez les parties moins pertinentes ou trop détaillées des résultats de l'outil ou du contexte récupéré. Par exemple, si vous n'avez besoin que des noms de colonnes de vos données, vous pouvez supprimer les métadonnées excessives d'une récupération de schéma de base de données. Cette stratégie nécessite une logique personnalisée qui utilise des heuristiques, un filtrage ou un petit modèle de langage (SLM) pour extraire les informations les plus importantes.
    • Limite maximale de jetons : pour éviter les boucles infinies et contrôler les coûts, appliquez une limite maximale de jetons par session.

  • Points de terminaison de modèle : pour gérer les quotas d'API et l'utilisation des ressources, vous pouvez déployer des points de terminaison Agent Platform dans une configuration dédiée ou partagée :

    • Points de terminaison dédiés : lorsque vous déployez des points de terminaison dans chaque projet locataire, vous fournissez une isolation inhérente des quotas. L'utilisation de chaque locataire est comptabilisée dans ses propres quotas de projet, ce qui évite tout impact entre les locataires. Par rapport aux points de terminaison partagés, les points de terminaison dédiés offrent une gestion des quotas plus simple. Toutefois, les points de terminaison dédiés vous empêchent de profiter des économies potentielles d'un point de terminaison partagé.
    • Points de terminaison partagés : pour optimiser les coûts, vous pouvez héberger un point de terminaison partagé dans le hub central de gouvernance et de sécurité. Étant donné que tous les locataires partagent le même pool de quotas, vous devez mettre en œuvre des stratégies d'atténuation telles que la limitation du débit au niveau du locataire ou l'application de quotas avec API Gateway pour empêcher les attaques malveillantes. Les points de terminaison partagés sont plus économiques que les points de terminaison dédiés. Toutefois, les points de terminaison partagés nécessitent un effort d'ingénierie supplémentaire et peuvent entraîner une latence et une surcharge de gestion.

    Pour en savoir plus sur les coûts sur Agent Platform, consultez Coût de création et de déploiement de modèles d'IA dans Agent Platform.

Considérations liées aux coûts de Cloud Run

L'instrumentation vous permet de surveiller les performances, de résoudre les problèmes et de suivre l'utilisation des ressources pour chaque locataire. Pour identifier le locataire de chaque requête, extrayez l'identité de l'utilisateur du contexte fourni par IAP. Pour en savoir plus sur l'instrumentation de votre application, consultez Choisir une approche d'instrumentation.

Considérations liées aux coûts de Model Armor

Pour appliquer une gouvernance stricte et une stratégie zéro confiance, cette architecture déploie Model Armor sur deux couches : dans le hub de routage et dans chaque projet de locataire. Bien que cette approche à deux couches contribue à garantir la souveraineté des données, elle augmente la latence et les coûts opérationnels. Pour réduire les coûts et la complexité du système, filtrez tous les prompts et toutes les réponses en déployant Model Armor exclusivement dans le hub de routage.

Considérations relatives aux coûts pour tous les produits de l'architecture

Pour vous assurer que votre architecture répond à vos exigences de coût, tenez compte des recommandations générales suivantes :

  • Infrastructure partagée : les composants d'infrastructure de base partagés, tels que le portail d'interface, le centre de sécurité et de gouvernance central, et Agent Platform, peuvent réduire les coûts par rapport à la création d'une pile personnalisée distincte pour chaque agent.

  • Frais généraux de la plate-forme : pour répartir les coûts partagés du centre de sécurité et de gouvernance central, utilisez un modèle d'allocation adapté à vos capacités de suivi et à vos modèles d'utilisation. Nous vous recommandons d'utiliser l'un des modèles de répartition des coûts suivants :

    • Répartition uniforme : un modèle de répartition uniforme répartit les coûts partagés de manière égale entre tous les locataires. Utilisez ce modèle lorsque la plate-forme est un utilitaire de référence ou lorsque la surcharge du suivi précis l'emporte sur les avantages en termes de coûts.
    • Allocation proportionnelle : un modèle proportionnel, ou processus de rétrofacturation, alloue les coûts partagés en fonction de la proportion des coûts directs encourus par chaque locataire. Utilisez ce modèle lorsque la consommation des locataires varie considérablement et que vous disposez d'une télémétrie robuste, telle que les libellés Resource Manager et l'analyse des journaux, pour attribuer les coûts avec précision.
    • Allocation fixe : un modèle fixe ou par niveaux alloue les coûts partagés en fonction de coefficients définis par l'entreprise. Utilisez ce modèle lorsque les locataires ont besoin de contrats de niveau de service (SLA) différents. Une allocation de modèle fixe vous permet de facturer des tarifs fixes pour les fonctionnalités dédiées premium par rapport aux fonctionnalités partagées standards.

    Pour en savoir plus sur la répartition des coûts des services partagés, consultez Cloud FinOps : répartition des coûts des services partagés.

  • Gestion centralisée des coûts : pour suivre avec précision le coût total de possession (TCO) de votre système d'IA agentique et attribuer les coûts à des unités commerciales individuelles, utilisez des étiquettes et les données d'exportation Cloud Billing. Pour en savoir plus sur l'utilisation des étiquettes pour sensibiliser aux coûts, consultez Favoriser une culture de sensibilisation aux coûts.

Pour estimer le coût de vos ressources Google Cloud , utilisez le simulateur de coûtGoogle Cloud .

Pour connaître les principes et recommandations d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez Perspective IA et ML : optimisation des coûts dans le framework d'architecture de référence.

Déploiement

Pour déployer cette architecture de référence, utilisez l'exemple Terraform d'IA agentique mutualisée disponible sur GitHub.

Étapes suivantes

Contributeurs

Auteurs :

  • Shivank Awasthi | Architecte de solutions sur le terrain
  • Utkarsh Bhardwaj | Consultant en solutions techniques, IA agentique, applications, plates-formes cloud et infrastructure

Autres contributeurs :