~6 minutes
Le contexte MCP, c’est la mémoire de travail de l’agent. Quand cette mémoire est partagée, persistante ou mal scopée, les données d’un utilisateur se retrouvent chez un autre. RGPD, HIPAA, PCI DSS , toutes les réglementations data sont concernées.
Partie de la série OWASP MCP Top 10
Description du risque
On considère le context bleeding comme l’un des risques les plus sous-estimés dans les architectures MCP multi-tenant.
Le Context Injection & Over-Sharing se produit quand les fenêtres de contexte MCP sont partagées, persistantes ou insuffisamment scopées. Les informations sensibles d’une tâche ou d’un utilisateur peuvent se retrouver exposées à d’autres , un phénomène de context bleeding.
Dans un système MCP multi-tenant, le contexte est à la fois la force (l’agent se souvient) et la faiblesse (ce contexte peut contenir des données d’autres sessions). C’est le RGPD nightmare scenario.
Vecteurs d’attaque
On distingue quatre vecteurs principaux de fuite et d’injection de contexte :
1. Contexte partagé entre utilisateurs
Un contexte global accessible à tous les utilisateurs permet à l’utilisateur B de voir les données de l’utilisateur A.
2. Contexte qui persiste trop longtemps
Les données d’une session se retrouvent dans les sessions suivantes, même pour d’autres utilisateurs.
3. Injection de contenu persistant
Un attaquant injecte des instructions dans le contexte via un outil de stockage. Ces instructions affectent toutes les sessions futures.
4. Sur-partage entre agents
Dans un système multi-agents, un agent partage plus de contexte que nécessaire avec d’autres agents.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Modéré | L’injection de contexte peut faire adopter à l’agent de fausses identités ou instructions. |
| Tampering (Falsification) | Oui | L’injection dans le contexte persistant altère le comportement de toutes les sessions futures. |
| Repudiation (Répudiation) | Modéré | Le mélange de contextes rend l’attribution difficile. |
| Information Disclosure (Divulgation d’informations) | Oui (PRIMAIRE) | C’est le risque central : fuite de données entre utilisateurs, sessions, agents. |
| Denial of Service (Déni de service) | Modéré | Un contexte surchargé dégrade les performances de l’agent. |
| Elevation of Privilege (Élévation de privilèges) | Oui | Des instructions injectées dans le contexte persistant peuvent élever les actions de l’agent. |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Critique | Violation directe du RGPD (art. 5, 32), HIPAA pour les données médicales, PCI DSS pour les données de paiement. Les données personnelles d'un utilisateur sont exposées à des tiers sans consentement. |
| Intégrité | Élevé | L'injection de contexte persistant peut altérer durablement le comportement de l'agent. Des "règles" injectées par un attaquant deviennent partie intégrante du contexte de travail. |
| Disponibilité | Modéré | Un contexte surchargé ou corrompu dégrade les performances et la qualité des réponses de l'agent. |
| Réputation | Sévère | Une fuite de données médicales ou financières via un agent IA mal scopé génère des poursuites légales et une couverture médiatique négative. La CNIL ne plaisante pas avec les violations RGPD. |
Les 8 défenses recommandées par l’OWASP
1. Contextes éphémères
On crée un contexte MCP isolé par tâche, détruit automatiquement à la fin de l’exécution, aucune donnée ne survit à la session qui l’a produite. On ne réutilise jamais un contexte entre deux workflows distincts : chaque agent repart d’une ardoise vierge, sans résidu de la session précédente. Ce principe élimine la surface d’attaque la plus silencieuse : la persistance involontaire de secrets ou de données sensibles entre deux invocations.
2. Isolation par namespace
On segmente le contexte MCP par namespace strict : chaque utilisateur, agent, workflow et tenant dispose de son propre espace mémoire, cloisonné au niveau du moteur de persistance. Un agent ne peut jamais lire le contexte d’un autre namespace sans autorisation explicite , l’isolation est appliquée au niveau de l’infrastructure, pas uniquement par convention. Cette séparation empêche les scénarios de cross-tenant leakage où un agent compromis pivote vers les données d’un autre utilisateur via le contexte partagé.
3. Tagging de classification des données
On applique un label de classification (public, interne, confidentiel, restreint) à chaque entrée stockée dans le contexte MCP, au moment de l’ingestion. Les politiques d’accès et de rétention sont pilotées par ces tags : un contexte “restreint” ne peut être consulté que par les agents explicitement autorisés, avec log obligatoire. Le tagging permet aussi d’identifier rapidement les contextes à purger en priorité en cas d’incident, un registre de classification est un prérequis à toute réponse à incident efficace.
4. Time-to-live obligatoire
On fixe un TTL explicite sur chaque entrée de contexte , 15 minutes pour les sessions interactives, 1 heure maximum pour les workflows longs, jamais de persistance indéfinie. À l’expiration du TTL, la suppression est automatique et non révocable : ni l’agent ni l’utilisateur ne peut prolonger la durée de vie sans déclencher un nouveau cycle d’enregistrement audité. Ce mécanisme limite l’exposition en cas de compromission : un attaquant qui accède au contexte après le TTL ne trouve rien d’exploitable.
5. Sanitisation avant stockage
On applique une sanitisation systématique de toutes les données avant persistance : détection et masquage des PII (noms, emails, numéros), des secrets (tokens, clés API, mots de passe) et des identifiants internes. On utilise des outils dédiés (ex: Microsoft Presidio, AWS Macie, ou règles regex auditées) intégrés en pre-hook dans le pipeline de stockage du contexte MCP. Aucune donnée brute issue d’une source externe (mail, fichier, réponse API) n’est stockée telle quelle , la sanitisation est un prérequis, pas une option.
6. Approbation humaine pour les contextes sensibles
On implémente un gate d’approbation humaine explicite avant toute réutilisation d’un contexte classifié “confidentiel” ou “restreint” dans un nouveau workflow. L’agent présente un résumé du contexte concerné et attend une validation de l’opérateur , aucune réutilisation automatique de données sensibles sans consentement actif. Ce principe applique le concept de “human-in-the-loop” là où il est le plus critique : les décisions qui impliquent des données à haut risque ne doivent jamais être déléguées entièrement à l’automatisation.
7. Logs d’accès intégrés au monitoring
On enregistre chaque accès au contexte MCP ; lecture, écriture, suppression ; dans un log immuable corrélé au SIEM de l’organisation. Les logs incluent : identifiant de l’agent appelant, namespace ciblé, classification de la donnée accédée, timestamp et résultat (succès/refus). Ces traces permettent de détecter les patterns anormaux (agent accédant à un volume inhabituel de contextes, accès hors plage horaire) et de reconstituer la chaîne d’événements après un incident.
8. Filtrage d’injection pour la persistance
On déploie un filtre d’analyse sémantique sur toutes les données candidates à la persistance, pour détecter les payloads d’injection de prompt conçus pour contaminer le contexte futur.
Les patterns détectés incluent : instructions cachées dans des fichiers texte, métadonnées malveillantes, commandes déguisées en contenu utilisateur (ex: <!-- SYSTEM: ignore previous instructions -->).
Tout contexte flaggué est mis en quarantaine et soumis à revue humaine avant d’être autorisé à persister , jamais de stockage automatique d’un contexte suspect.
Quelques références pour aller plus loin
À retenir
