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

Preview

Cette fonctionnalité est soumise(s) aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Le protocole MCP (Model Context Protocol) normalise 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 d'invite nécessite un modèle de responsabilité partagée, combinant des contrôles de plate-forme à une conception d'application sécurisée.
Pour concevoir et déployer des applications d'IA qui utilisent des outils MCP (Model Context Protocol), suivez les bonnes pratiques de ce guide. Google Cloud

Avant de commencer

Lorsque vous utilisez des outils MCP, la stratégie 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.
• Étendues minimales : 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 strict minimum nécessaire à sa fonction.
• Séparation des tâches : si un agent a besoin d'accéder aux données en lecture et d'accéder à un journal ou à un espace de stockage temporaire en écriture, utilisez deux comptes de service distincts : un compte pour l'accès aux données à haut risque (avec un champ d'application minimal) et un autre pour les tâches opérationnelles à faible risque.

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

Pour une protection 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, cela empêche un DROP TABLE

Produit	Mécanisme de contrôle précis	Focus
Cloud SQL et AlloyDB	Rôles au niveau de la base de données, comme CREATE ROLE dans PostgreSQL et MySQL.	Gérez les autorisations dans une instance et des schémas de base de données spécifiques.
BigQuery	Contrôle des accès au niveau des colonnes (à l'aide de tags avec stratégie)	Restreignez l'accès des agents aux colonnes sensibles (par exemple, les informations permettant d'identifier personnellement l'utilisateur), même dans une table autorisée.
Spanner	Contrôle précis des accès (rôles de base de données avec GRANT/REVOKE)	Appliquez des autorisations de lecture, d'écriture et de mise à jour précises sur les tables et les colonnes.
Firestore	Règles de sécurité Firestore	Restreignez l'accès au niveau du document ou du champ en fonction de la logique de l'application ou du contexte de l'utilisateur qui en fait la demande.
Bigtable	Rôles IAM	Bigtable offre un contrôle précis grâce aux rôles IAM au niveau du projet, de l'instance et de la table.

Conception d'agent sécurisée

Les modèles "Agent-Only" nécessitent des défenses robustes au niveau de l'application contre les attaques par injection de prompt, qui tentent de remplacer le prompt système. Pour en savoir plus, consultez Sécurité et protection de l'IA.

Considérez les données et les saisies utilisateur comme non fiables

Considérez 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émenter des modèles de sélection d'actions

Évitez les architectures planifier et exécuter ouvertes, dans lesquelles le système découple 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.

• Schéma de sélection d'action : le seul rôle du modèle est de traduire une requête utilisateur en l'une des fonctions sûres d'un petit ensemble prédéfini. 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.
• Schéma Dual-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 la requête de l'utilisateur pour détecter toute intention malveillante et post-sélectionne la sortie du LLM d'action pour détecter toute action non autorisée ou fuite de données.

Empêcher l'enchaînement 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 être en mesure d'enregistrer dynamiquement de nouveaux outils ni de 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 code backend et son invite système initiale. Pour obtenir un exemple de Gemini CLI, consultez Restreindre l'accès aux outils.

Configurations de sécurité

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 jailbreaking.

L'exemple suivant active Model Armor sur un point de terminaison Vertex AI.

# 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.

Appliquer 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 la désidentification des informations permettant d'identifier personnellement l'utilisateur. Utilisez la protection des données sensibles DeidentifyTemplate pour 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 des agents est essentielle pour l'analyse post-incident et la détection des agents compromis.

Mettre 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 aux bases 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 destructive 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 offrent des fonctionnalités de récupération de 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.

Produit	Mécanismes de sauvegarde et de récupération
Cloud SQL	Compatible avec les sauvegardes à la demande et automatiques, ce qui vous permet de restaurer une instance à un état antérieur. Il est également compatible avec la récupération à un moment précis (PITR).
AlloyDB	Fournit la sauvegarde et la récupération continues par défaut. Cela permet la récupération à un moment précis avec une précision de l'ordre de la microseconde, ce qui vous permet de restaurer un cluster à n'importe quel moment de votre période de conservation.
BigQuery	La récupération des données s'effectue à l'aide de la fonctionnalité temporelle, qui vous permet d'accéder aux données et de les restaurer à partir de n'importe quel moment au cours des sept derniers jours. Pour une conservation à plus long terme, vous pouvez créer des instantanés de table.
Spanner	Compatible avec les sauvegardes à la demande et la récupération à un moment précis.
Firestore	Compatible avec les exportations/importations gérées en tant que sauvegardes. Il propose également la récupération à un moment précis (PITR, Point-in-time Recovery), désactivée par défaut, pour protéger les données contre les suppressions ou les écritures accidentelles.
Bigtable	Compatible avec les sauvegardes à la demande et automatiques. Ces sauvegardes sont entièrement gérées et peuvent être restaurées dans une nouvelle table.

Activer Cloud Audit Logs

Assurez-vous que les journaux d'audit de l'accès aux données sont activés pour MCP, ainsi que pour tous les Google Cloud services Google Cloud concernés, comme BigQuery, Cloud SQL, AlloyDB et Spanner. Par défaut, seuls les journaux d'audit des activités d'administration sont activés. Les journaux d'audit des 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 des accès aux données pour MCP.

Auditer 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 les attaques d'exfiltration ou 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"

Utiliser 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 : indique si l'action est exécutée (modèle Agent-Only) ou approuvée (Human-in-the-Middle). 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.