Sécuriser les agents IA et le Model Context Protocol (MCP)
Le Model Context Protocol, publié en open source par Anthropic en novembre 2024, est devenu le moyen standard de connecter des agents IA à des outils et des données : tickets, dépôts de code, bases de données, messagerie, API cloud. C'est aussi une nouvelle surface d'attaque. En mai 2026, la NSA américaine a publié une fiche d'information cybersécurité (CSI) sur la conception sécurisée de MCP, dont la conclusion tient en une phrase : le protocole est prometteur mais immature, et sa sécurité dépend de la rigueur d'implémentation, pas de garanties intégrées au protocole. Cet article résume les menaces, les cas réels cités par la NSA, et les règles de conception qui gardent un agent utile sans lui confier toutes les clés. Il complète nos articles sur les agents IA et la gouvernance de l'IA.
Pourquoi MCP change le modèle de menace
Un hôte MCP (l'application IA) fait tourner un client qui se connecte à un ou plusieurs serveurs ; chaque serveur expose des outils, des ressources et des prompts. Trois propriétés comptent pour la sécurité :
- Les descriptions d'outils sont lues par le modèle. Un texte qui ressemble à des métadonnées est en réalité un canal d'instructions.
- Le contexte est partagé. Un client connecté à plusieurs serveurs mélange leurs contenus dans la même fenêtre de contexte : un serveur peu fiable peut influencer les appels vers un serveur de confiance.
- Le schéma d'interaction est inversé. Les serveurs peuvent interroger le client et parfois y déclencher des actions : la confiance circule dans un sens inhabituel.
Le modèle ne sait pas distinguer de façon fiable les données des instructions. Tous les contrôles doivent donc se situer en dehors du modèle : identité, permissions, bacs à sable, validations humaines et journaux.
- Human principal and approvals — who the agent acts for, what needs confirmation
- Orchestrator / planner — system prompt, goals, step limits, stop conditions
- Memory — conversation, long-term vector memory, shared scratchpads
- Tools via MCP or function calling — APIs, browser, code execution, file system, e-mail, tickets
- Credentials — OAuth (delegated-access standard) tokens, API keys, cloud roles the tools use
- Execution environment — sandbox, container, VM; network egress
- Other agents (A2A, agent-to-agent protocols) — delegation, agent cards, cross-agent messages
Extrait de la fiche « Agentic AI and MCP Security » · Demander la fiche complète
Les menaces
| Menace | Mécanisme | OWASP LLM Top 10 2025 |
|---|---|---|
| Injection de prompt indirecte via les outils | Des instructions cachées dans une page web, un ticket, un courriel ou une sortie d'outil orientent l'agent | LLM01 Prompt Injection |
| Empoisonnement d'outil et « rug pull » | Texte malveillant dans la description ou le schéma d'un outil ; un serveur sain à l'installation qui change ensuite | LLM01, LLM03 Supply Chain |
| Jetons trop larges | Un seul jeton donnant accès à tous les dépôts, boîtes mail ou buckets | LLM06 Excessive Agency |
| Adjoint confus (confused deputy) | Un serveur réutilise le jeton de l'utilisateur, ou agit avec ses propres privilèges pour un appelant moins privilégié | LLM06 |
| Exfiltration de données | Entrée non fiable + données privées + canal sortant dans le même agent | LLM02 Sensitive Information Disclosure |
| Injection de commande ou de code dans les outils | Un outil construit une commande shell ou évalue un texte fourni par le modèle (CWE-77/78/94/95) | LLM05 Improper Output Handling |
| Confusion de noms d'outils | Des outils homonymes de sources différentes sont résolus de façon imprévisible | LLM03 |
| Déni de service, coûts | Tâches récursives, rafales de prompts, boucles d'outils incontrôlées | LLM10 Unbounded Consumption |
| OWASP Agentic AI threat (Feb 2025 guide) | Agent-specific example | Primary mitigation |
|---|---|---|
| T1 Memory poisoning | injected 'fact' stored in long-term memory steers future sessions | memory write review, provenance, TTL (time to live: expiry), per-user isolation |
| T2 Tool misuse | agent tricked into calling a legitimate tool harmfully | tool allow-list per task, parameter validation, approvals |
| T3 Privilege compromise | agent's broad token used beyond the user's rights | per-user delegated OAuth scopes, no shared service accounts |
| T4 Resource overload | loops of tool calls, runaway cost | step, token and spend limits; circuit breakers |
| T5 Cascading hallucination | fabricated output reused by later steps or agents | grounding checks, verification step, citations |
| T6 Intent breaking / goal manipulation | injected goal replaces the user's task | plan-then-execute with fixed plan, goal re-confirmation |
| T7 Misaligned and deceptive behaviour | agent hides actions to reach a metric | independent monitoring, immutable action logs |
| T8 Repudiation and untraceability | no record of which agent did what for whom | signed, correlated logs of prompts, tool calls, identities |
| T9 Identity spoofing | agent or user impersonated in agent-to-agent messages | workload identity, mutual authentication, signed agent cards |
| T10 Overwhelming human in the loop | approval fatigue: dozens of prompts rubber-stamped | risk-tiered approvals, batch summaries, deny by default |
| T11 Unexpected remote code execution (RCE) and code attacks | generated code executed on the host | sandbox (container, microVM), no host mounts, egress deny |
| T12 Agent communication poisoning | malicious content passed between agents | treat peer output as untrusted, schema validation |
| T13 Rogue agents in multi-agent systems | compromised agent acts outside its role | least privilege per agent, kill switch, anomaly detection |
| T14 Human attacks on multi-agent systems | exploiting delegation between agents to bypass checks | end-to-end authorisation on the original principal |
| T15 Human manipulation | agent output used to socially engineer its own user | output policy, provenance labels, user awareness |
Extrait de la fiche « Agentic AI and MCP Security » · Demander la fiche complète
Ce qu'a constaté la NSA
La CSI recense neuf préoccupations de sécurité dans la conception et l'usage de MCP. Les deux jugées critiques sont le contrôle d'accès (lier une session à une identité est optionnel dans le protocole ; beaucoup d'implémentations n'ont pas d'authentification, et celles qui en ont appliquent rarement des rôles) et la confiance implicite entre composants (tâches transmises entre serveurs sans vérification d'origine, de périmètre ni d'intention). Les autres : sérialisation non sécurisée du contexte, circuits d'approbation faibles (pas de nouveau consentement quand les capacités changent), sécurité des jetons et sessions, erreurs de configuration, comportements non déterministes, journaux d'audit absents, déni de service.
Elle cite ensuite six classes de problèmes réels :
| Cas | Ce qui s'est passé | Leçon |
|---|---|---|
| Injection dans les paramètres d'outil | Un outil transmettait à une commande des paramètres fournis par le modèle | Valider les paramètres contre un schéma strict ; journaliser chaque appel |
| Confusion de chemin d'outil | Un outil homonyme d'une autre source s'exécutait à la place du bon | Résoudre les noms explicitement, sans repli entre registres |
| Accès global via le serveur MCP GitHub | Un ticket dans un dépôt public demandait à un agent de code de copier des données de dépôts privés dans une pull request publique | Limiter les jetons par dépôt et par opération |
| Exfiltration WhatsApp, « rug pull » | Un serveur connecté à côté d'un serveur de confiance a modifié la description de son outil après approbation et détourné des messages | Figer et comparer les descriptions ; réapprouver à chaque changement ; isoler les serveurs détenant des données privées |
| Sortie empoisonnée dans une chaîne | La sortie d'un outil orientait l'agent suivant | Toute sortie est une entrée non fiable |
| CVE-2025-49596 | Exécution de code à distance dans MCP Inspector avant la 0.14.1 | L'hygiène de base s'applique aussi aux outils de développement IA |
Le cas GitHub est le schéma type : une entrée non fiable (un ticket public), des données privées (les autres dépôts) et un canal sortant (une pull request publique) réunis dans un même agent, avec un seul jeton très large. Supprimez l'un des trois et l'attaque échoue.
Recommandations de conception
Les neuf recommandations de la CSI, combinées à la spécification d'autorisation de MCP et aux travaux de l'OWASP, forment un socle pratique.
1. Moindre privilège, par outil et par tâche. Jetons fins et éphémères, limités à un dépôt, un dossier de messagerie, un jeu de données. Lecture seule par défaut ; les outils d'écriture sont distincts et plus rares. Un agent de code qui travaille sur un dépôt ne doit pas détenir un jeton valable pour toute l'organisation.
2. Respecter le modèle d'autorisation. Les serveurs MCP distants agissent comme des serveurs de ressources OAuth 2.1. Les jetons sont liés à une audience (resource indicators, RFC 8707) et chaque serveur vérifie cette audience. Pas de transmission de jeton : un serveur obtient son propre jeton pour les API en aval ; relayer le jeton du client en fait un adjoint confus et casse l'attribution dans les journaux.
3. Validation humaine pour les actions à conséquence. Envoyer un courriel, fusionner du code, payer, supprimer, modifier des droits : afficher l'action et ses paramètres exacts et exiger une confirmation. L'approbation doit être redemandée quand les outils ou descriptions d'un serveur changent.
4. Listes d'autorisation et registre validé. Uniquement des serveurs approuvés, issus de projets maintenus, épinglés par version, relus avec votre niveau de revue de code le plus strict, enregistrés avec un responsable et les classes de données autorisées. Lisez chaque description d'outil : aucune instruction destinée au modèle, aucun texte caché.
5. Zones de confiance. Ne connectez pas, dans la même session, un serveur qui lit du contenu non fiable (web, tickets publics, courriels entrants) et des serveurs détenant des données privées, sauf à intercaler une validation. Préférez des serveurs locaux pour les données privées.
6. Valider les paramètres. Schémas JSON stricts, limites de taille, énumérations plutôt que texte libre, champs inconnus rejetés. Jamais de commande shell ni d'eval construits à partir de la sortie du modèle ; bloquez la transmission vers un autre composant de données ambiguës fournies par l'utilisateur.
7. Isoler l'exécution des outils. Chaque outil dans son conteneur ou processus avec seccomp/AppArmor (ou AppContainer sous Windows), sans accès aux systèmes de fichiers sensibles ni au réseau interne, avec des flux sortants passant par un proxy filtrant à liste d'autorisation. Les serveurs HTTP locaux écoutent sur 127.0.0.1 et vérifient l'en-tête Origin contre le DNS rebinding.
8. Traiter les sorties comme non fiables. Filtrer et inspecter les sorties d'outils avant qu'elles n'atteignent le modèle ou l'outil suivant ; surveiller les motifs d'injection et les secrets.
9. Tout journaliser, puis détecter. Chaque invocation avec identité de l'utilisateur, serveur, outil, paramètres, empreinte du résultat et décision d'approbation, envoyée au SIEM. Sans cela, la réponse à incident sur un agent relève de la devinette.
10. Suivre et scanner. Inventaire des serveurs MCP avec leurs versions ; veille sur les avis de sécurité et les CVE ; recherche sur le réseau des points d'accès MCP non authentifiés ou exposés sur Internet.
Liste de contrôle
| # | Contrôle | Responsable |
|---|---|---|
| 1 | Inventaire des agents, serveurs MCP, jetons et données accessibles par chacun | Sécurité + plateforme |
| 2 | Registre de serveurs approuvés, versions épinglées, comparaison des descriptions | Plateforme |
| 3 | Jetons par tâche, éphémères, liés à une audience ; aucune transmission de jeton | Développeurs |
| 4 | Validation humaine pour écrire, envoyer, payer, supprimer, modifier des droits | Responsable produit |
| 5 | Serveurs de contenu non fiable isolés des serveurs de données privées | Architecture |
| 6 | Exécution des outils en bac à sable, flux sortants sur liste d'autorisation | Plateforme |
| 7 | Validation par schéma sur chaque outil ; ni shell ni eval sur la sortie du modèle | Développeurs |
| 8 | Journaux d'invocation complets dans le SIEM, alertes sur les séquences inhabituelles | Sécurité |
| 9 | Limites de débit et de coût par agent et par utilisateur | Plateforme |
| 10 | Tests red team avec injection indirecte avant la mise en production | Sécurité |
Ces contrôles s'inscrivent aussi dans une démarche EBIOS RM : un agent est un nouveau bien support doté d'un écosystème inhabituellement large (voir EBIOS RM en pratique).
Notre accompagnement
Les plateformes d'agents tournent sur des infrastructures cloud et Kubernetes : leur sécurité tient largement à l'identité, à l'isolation, aux secrets et aux pipelines. L'offre sécurité cloud et DevSecOps de Tadata couvre l'isolation, les identités de charge de travail et la gestion des secrets des déploiements d'agents, et notre activité audit de sécurité et conformité peut inclure une analyse de risques dédiée aux agents IA. Voir notre page cybersécurité ; la bibliothèque de fiches, gratuite, résume la CSI de la NSA sur MCP en trois fiches, ainsi que l'OWASP LLM Top 10 2025.