Bonnes pratiques pour sécuriser les interactions des agents avec le Model Context Protocol

Le Model Context Protocol (MCP) standardise la façon dont les agents d'IA générative se connectent à Bigtable. En raison des risques inhérents aux agents autonomes, l'atténuation des failles telles que l'injection de prompts nécessite un modèle de responsabilité partagée, combinant des contrôles de plate-forme et une conception d'application sécurisée.
Pour concevoir et déployer des applications d'IA qui utilisent les outils du Google Cloud Model Context Protocol (MCP), suivez les bonnes pratiques de ce guide.

Avant de commencer

Lorsque vous utilisez des outils MCP, la posture de sécurité de votre application dépend du modèle d'interaction de l'agent. Pour savoir comment votre utilisation des agents a un impact sur les risques de sécurité associés à l'intégration d'agents à un serveur MCP, consultez Sécurité et sûreté de l'IA.

Responsabilités en matière de sécurité

En tant que client, vous êtes responsable de la configuration et du fonctionnement sécurisés de votre plate-forme d'agent.

Suivez le principe du moindre privilège.

Exécutez votre agent avec un compte de service à portée minimale. Il s'agit de la première et de la plus importante couche de défense.

• Identité dédiée : créez un compte de service distinct et dédié pour chaque agent ou application unique à l'aide des outils MCP. Ne réutilisez pas les comptes de service existants, en particulier ceux qui disposent d'autorisations étendues.
• Champs d'application minimaux : n'accordez au compte de service que les rôles IAM (Identity and Access Management) nécessaires, par exemple alloydb.viewer et non alloydb.admin. Si l'agent n'a besoin que d'un accès en lecture à un ensemble de données spécifique, utilisez des rôles IAM personnalisés pour limiter l'accès au minimum absolu requis pour sa fonction.
• Séparation des tâches : si un agent a besoin à la fois d'un accès en lecture aux données et d'un accès en écriture à un journal ou à un espace de stockage temporaire, utilisez deux comptes de service distincts : un compte pour l'accès aux données à haut risque (à portée minimale) et un autre pour les tâches opérationnelles à faible risque.

Utilisez des contrôles précis natifs de la base de données

Pour une défense optimale, combinez les rôles IAM avec les contrôles d'accès précis proposés par la base de données elle-même. Ainsi, même si un pirate informatique compromet le jeton IAM de l'agent, l'étendue des dommages est limitée par les autorisations internes du moteur de base de données, par exemple en empêchant une commande DROP TABLE.

Conception d'agent sécurisée

Les modèles d'agent uniquement nécessitent des défenses robustes au niveau de l'application contre les attaques par injection de prompts, qui tentent de remplacer le prompt système. Pour en savoir plus, consultez Sécurité et sûreté de l'IA.

Traitez les données et les entrées utilisateur comme non fiables

Traitez les entrées des utilisateurs finaux ou les données récupérées par l'agent à partir de sources externes (comme un résultat de recherche Web ou un document tiers) comme non fiables.

Implémentez des modèles de sélection d'actions

Évitez les architectures planifier et exécuter ouvertes, dans lesquelles le système dissocie la spécification des tâches de haut niveau de l'exécution mécanique. Utilisez plutôt des modèles de conception qui limitent la liberté du modèle.

• Modèle de sélecteur d'actions : la seule tâche du modèle consiste à traduire une requête utilisateur en l'un des petits ensembles prédéfinis de fonctions sécurisées. La logique d'action est codée en dur et ne peut pas être modifiée par le LLM. Cela permet de rendre l'agent immunisé contre les attaques par injection ciblant le flux de contrôle.
• Modèle à double LLM : utilisez un LLM principal (le LLM d'action) qui effectue la tâche principale, et un LLM secondaire hautement sécurisé (le LLM de garde-fou) qui présélectionne le prompt utilisateur pour détecter les intentions malveillantes et post-sélectionne la sortie du LLM d'action pour détecter les actions non autorisées ou les fuites de données.

Empêchez le chaînage d'outils non autorisé

Les agents ne doivent appeler que les outils nécessaires à la tâche. Assurez-vous que votre code d'orchestration empêche les éléments suivants :

• Outils dynamiques : l'agent ne doit pas pouvoir enregistrer dynamiquement de nouveaux outils ni modifier les autorisations des outils existants.
• Application de la liste d'autorisation : déclarez une liste d'autorisation de fonctions ou de tables de base de données auxquelles l'agent peut accéder dans son prompt système initial et son code backend. Pour obtenir un exemple de l'interface de ligne de commande Gemini, consultez Restreindre l'accès aux outils.

Limitez l'accès aux données dans les bases de données mutualisées

Un outil général tel que execute_sql permet à l'appelant d'exécuter des requêtes de base de données qui peuvent lire toutes les données auxquelles les autorisations IAM et de base de données autorisent l'accès. Lorsque vous créez un agent qui accède aux données d'une application mutualisée sans intervention humaine de confiance, vous devrez peut-être limiter davantage l'accès aux données.

Pour vous assurer que l'agent ne peut lire que des sous-ensembles des données auxquelles il a accès, nous vous recommandons de créer des outils personnalisés à l'aide d'un framework tel que MCP Toolbox for Databases. Pour en savoir plus, consultez Outils prédéfinis ou personnalisés.

Supposons, par exemple, que votre base de données stocke les commandes de tous les utilisateurs finaux dans la table Orders. Vous développez un agent de chat qui interagit avec les utilisateurs et peut rechercher leurs commandes. L'agent de chat est autorisé à lire l'intégralité de la table Orders, mais un utilisateur final ne doit pas pouvoir demander des informations sur les commandes d'un autre utilisateur.

Dans un scénario non sécurisé, vous équipez l'agent d'un seul outil execute_sql, ce qui crée un risque de fuite de données. Un utilisateur malveillant peut inciter l'agent à lire et à renvoyer les commandes d'autres utilisateurs. Demander à l'agent d'appliquer les règles d'accès n'est généralement pas suffisant pour protéger les données.

Dans un scénario sécurisé, vous fournissez à l'agent un outil personnalisé plus spécifique, tel que lookup_active_order, où l'identité de l'utilisateur dans le filtre de requête est définie en dehors du contrôle de l'agent.

Configurations de sécurité et de sûreté

Bigtable fournit Model Armor pour appliquer des limites de sécurité au niveau de la plate-forme. Vous devez activer et configurer ces paramètres.

Activer Model Armor

Utilisez Google Cloud CLI pour activer Model Armor sur le déploiement de votre modèle. Cela active la protection intégrée contre les vecteurs d'attaque connus, tels que l'injection et le jailbreak.

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

Pour en savoir plus et obtenir des exemples, consultez Configurer la protection Model Armor pour MCP sur Google Cloud.

Appliquez des seuils de sécurité minimaux pour les opérations sur les données sensibles

Model Armor vous permet d'appliquer un seuil de sécurité minimal pour les opérations sur les données sensibles, par exemple la détection et l'anonymisation des informations permettant d'identifier personnellement l'utilisateur. Utilisez un DeidentifyTemplate de protection des données sensibles pour expurger ou masquer les informations sensibles avant qu'elles ne soient renvoyées à l'utilisateur, même si le modèle est compromis.

Voici un exemple conceptuel de configuration :

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

Dans l'exemple suivant, model_armor_config.json peut faire référence à un modèle DLP :

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

Audit et observabilité

La visibilité sur les actions de l'agent est essentielle pour l'analyse post-incident et la détection des agents compromis.

Mettez en œuvre une stratégie de récupération des données

Bien que les contrôles multicouches tels que les rôles IAM et natifs de la base de données soient conçus pour empêcher les actions destructrices, vous devez disposer d'un plan de récupération en cas d'échec de ces défenses. Un agent compromis ou naïf disposant d'autorisations d'écriture (risque "Agent uniquement") peut être amené à exécuter une commande destructrice telle que DROP TABLE ou à corrompre des données.

Votre principale défense contre ce scénario est une stratégie de récupération robuste.

Presque tous les produits Data Cloud fournissent des fonctionnalités de récupération des données, que ce soit par le biais de sauvegardes traditionnelles, de la récupération à un moment précis (PITR) ou d'instantanés de données. Vous êtes responsable de l'activation et de la configuration de ces fonctionnalités.

Activer Cloud Audit Logging

Assurez-vous que les journaux d'audit d'accès aux données sont activés pour MCP, ainsi que pour tous les Google Cloud services pertinents tels que BigQuery, Cloud SQL, AlloyDB, Firestore et Spanner. Par défaut, seuls les journaux d'audit des activités d'administration sont activés. Les journaux d'audit d'accès aux données enregistrent chaque opération de lecture et d'écriture effectuée par l'agent. Pour en savoir plus, consultez Journaux d'audit d'accès aux données pour MCP.

Auditez les actions sensibles

Configurez des alertes dans Cloud Logging pour détecter les actions anormales ou à haut risque. La requête de l'explorateur de journaux identifie les comptes de service qui effectuent des opérations d'écriture de données dans Firestore, par exemple, qui est une cible courante pour l'exfiltration ou les attaques destructrices :

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

Utilisez la journalisation spécifique à l'agent

En plus de Cloud Audit Logs, assurez-vous que le code de votre application enregistre les données suivantes pour chaque décision de l'agent :

• Exécution de l'outil : outil MCP appelé.
• Commande brute : commande exacte (par exemple, une requête SQL ou un chemin d'accès à un document) générée par le LLM.
• Action finale : si l'action est exécutée (modèle d'agent uniquement) ou approuvée (intervention humaine). Pour en savoir plus, consultez Comprendre l'utilisation des agents.
• ID utilisateur et de session : identifiant de l'utilisateur final qui a lancé la requête.