Risques liés à l'injection rapide et à la sécurité des agents d'IA : comment les attaques agissent contre Claude Code et comment les prévenir

Présentation

Claude Code peut lire votre base de code, exécuter des commandes shell, interroger des bases de données via des serveurs MCP et transmettre des modifications aux référentiels. Ces fonctionnalités en font un puissant agent de codage. Ils en font également une cible de grande valeur pour les attaques que la plupart des programmes de sécurité d'entreprise ne sont pas encore équipés pour détecter.

L'injection rapide constitue le principal risque de sécurité des agents d'IA en 2026. Il ne nécessite pas d'exécution de code, d'exploit réseau ou de compromission des informations d'identification. Un attaquant place des instructions malveillantes à un endroit où Claude Code peut les lire (un commentaire dans un fichier, une description dans un ticket, une réponse d'une API) et attend que l'agent suive ces instructions comme si elles étaient légitimes.

Le Top 10 de l'OWASP pour les applications agentiques 2026, publié en décembre 2025 par plus de 100 chercheurs et praticiens de la sécurité, classe Agent Goal Hijacking (ASI01) comme le risque numéro un. Les attaques ne sont plus théoriques.

En mars 2026, Oasis Security a démontré un pipeline d'attaque complet contre claude.ai, surnommé « Claudy Day », qui enchaînait une injection rapide invisible avec exfiltration de données pour voler l'historique des conversations d'une session prête à l'emploi par défaut. Aucun serveur MCP, aucun outil, aucune configuration particulière requise.

Nous expliquons comment fonctionne l'injection rapide de Claude Code étape par étape, l'éventail complet des risques de sécurité liés aux agents d'IA auxquels les équipes des entreprises sont confrontées, pourquoi les outils de sécurité traditionnels passent à côté de ces attaques et quels contrôles au niveau de l'infrastructure les empêchent réellement.

Qu'est-ce que l'injection rapide dans le contexte de Claude Code ?

L'injection rapide est une attaque au cours de laquelle des instructions malveillantes sont intégrées au contenu traité par un agent d'IA dans le cadre d'une tâche légitime. L'agent ne peut pas faire la différence de manière fiable entre les instructions de son développeur et les instructions enfouies dans un contenu externe. Il s'ensuit donc les deux.

Pour Claude Code en particulier, l'injection rapide de Claude Code exploite la fonction principale de l'agent : lire et traiter le contenu depuis son environnement de travail. Chaque fichier lu par Claude Code, chaque réponse d'outil qu'il traite, chaque commentaire de référentiel qu'il ingère : chacun est une surface d'injection potentielle.

Injection directe et rapide

L'attaquant a un accès direct aux données saisies par Claude Code. Ils partagent peut-être un outil de développement ou interagissent via une interface utilisateur connectée à l'agent. Ils intègrent des instructions directement dans leur saisie qui annulent ou redirigent le comportement de Claude Code.

Un développeur utilise Claude Code pour analyser le code soumis. Un attaquant soumet un code contenant des instructions cachées qui indiquent à l'agent d'exfiltrer le résultat de l'analyse. Les instructions se trouvent directement dans la saisie : elles sont visibles dans le texte brut, invisibles dans les vues rendues.

Injection rapide indirecte

L'attaquant n'interagit jamais directement avec Claude Code. Au lieu de cela, ils insèrent des instructions dans le contenu que Claude Code récupérera et traitera pendant le fonctionnement normal. Ce formulaire est plus courant et bien plus dangereux car il ne nécessite aucun accès à l'interface de l'agent.

Un attaquant ajoute des instructions masquées dans un fichier README, une description de ticket Jira, un fichier .docx avec du texte blanc sur blanc ou un commentaire dans un dépôt public. Claude Code considère ce contenu comme faisant partie d'une tâche légitime et considère les instructions injectées comme des indications supplémentaires.

L'attaque « Claudy Day » d'Oasis Security a fonctionné exactement de cette façon : balises HTML masquées dans un paramètre d'URL qui étaient invisibles dans la boîte de discussion mais entièrement traitées par Claude lorsque l'utilisateur a appuyé sur Entrée.

Comment l'injection rapide attaque réellement Claude Code : étape par étape

La compréhension des mécanismes rend les exigences de prévention évidentes. L'attaque suit un schéma prévisible, quelle que soit la surface d'injection utilisée.

Étape 1 : L'attaquant identifie une surface d'entrée

L'attaquant trouve du contenu que Claude Code traitera dans le cadre de son flux de travail normal :

• Un fichier dans un dépôt (README, CLAUDE.md, fichiers de configuration)
• Description d'un ticket Jira ou Linear
• Une réponse d'API provenant d'un outil MCP connecté
• Un document extrait d'une base de connaissances ou d'un pipeline RAG
• Un commentaire dans une pull request

La surface d'injection n'a pas besoin d'être sous le contrôle direct de l'attaquant. Tout contenu touché par l'agent est un vecteur potentiel.

Étape 2 : L'attaquant intègre des instructions masquées

Les instructions sont intégrées au contenu, souvent déguisées pour se fondre dans le texte normal. Les techniques courantes incluent :

• Texte blanc sur fond blanc dans les documents
• Commentaires HTML invisibles dans les vues rendues mais présents dans le texte brut
• Caractères Unicode à largeur nulle qui masquent les instructions pour qu'elles ne soient pas examinées par un humain
• Instructions présentées sous forme de « notes système » ou de « commentaires des développeurs » que le modèle considère comme faisant autorité

Un exemple concret : les chercheurs de Claudy Day ont intégré une clé d'API contrôlée par l'attaquant dans l'invite masquée, demandant à Claude de rechercher l'historique des conversations de l'utilisateur, de l'écrire dans un fichier et de le télécharger sur le compte Anthropic de l'attaquant via l'API Files. L'exfiltration a utilisé un point de terminaison autorisé (api.anthropic.com), le rendant invisible aux contrôles au niveau du réseau.

Étape 3 : Claude Code traite le contenu injecté

Lorsque Claude Code lit le fichier ou en récupère le contenu dans le cadre de la tâche qui lui est assignée, les instructions injectées entrent dans la fenêtre contextuelle. Du point de vue du modèle, tout le texte de sa fenêtre contextuelle constitue une entrée également valide. Claude Code ne dispose d'aucun mécanisme fiable permettant de déterminer qu'une partie a été créée par un attaquant.

Étape 4 : Claude Code exécute les instructions injectées

Sans détection au niveau de l'infrastructure, Claude Code peut suivre les instructions injectées, en passant des appels réseau, en lisant des fichiers ou en effectuant des actions en dehors de la portée de la tâche d'origine. La tâche initiale se poursuit souvent normalement, masquant le fait que l'injection a réussi.

Lorsque --dangerously-skip-permissions est actif, ces actions s'exécutent sans aucune invite de confirmation. Mais même en l'absence de ce drapeau, la lassitude liée à l'approbation (les développeurs valident des dizaines de demandes par session sans les lire) signifie que les actions injectées peuvent également passer par les flux d'autorisations standard.

Vulnérabilités du code Claude dans le monde réel : pas théoriques

Plusieurs attaques démontrées contre Claude Code et son écosystème prouvent que ces risques sont réels et non des exercices théoriques.

Claudy Day : pipeline d'attaques complet contre le fichier Claude.ai par défaut (mars 2026)

Sécurité d'Oasis trois vulnérabilités enchaînées pour créer un pipeline d'attaque complet contre une session claude.ai par défaut :

• Injection rapide invisible via des paramètres d'URL qui pré-remplissent la boîte de discussion — balises HTML masquées invisibles pour l'utilisateur mais traitées par Claude
• Exfiltration de données via l'API Anthropic Files, que le sandbox autorise par défaut puisque api.anthropic.com figure sur la liste d'autorisation du réseau
• Vol de l'historique des conversations, y compris la stratégie commerciale, les informations financières et les informations personnelles

Aucun outil, aucun serveur MCP, aucune intégration requise. Anthropic a corrigé le problème d'injection rapide.

Contournement de la règle de refus adverse : limite de 50 sous-commandes (avril 2026)

Après le Fuite des sources de Claude Code le 31 mars 2026 (512 000 lignes de TypeScript exposées via npm), société de sécurité Adversa a trouvé un contournement de la règle de refus dans BashPermissions.ts. Claude Code applique des règles de refus aux commandes risquées telles que curl, mais le code source contient une limite de 50 sous-commandes. Si vous dépassez cette limite, Claude Code demande par défaut l'autorisation au lieu de bloquer purement et simplement la commande.

Preuve de concept d'Adversa : 50 sous-commandes true no-op suivies d'une commande curl. Claude a demandé l'autorisation au lieu de la refuser. Avec --dangerously-skip-permissions actif, la commande curl aurait été exécutée sans aucune invite. La vulnérabilité a été corrigée dans Claude Code v2.1.90.

InversePrompt : injection de commandes via des commandes sur liste blanche (2025)

Chercheurs de Cmulate a découvert deux CVE de haute gravité — CVE-2025-54794 (contournement de restriction de chemin, CVSS 7.7) et CVE-2025-54795 (exécution de code par injection de commande, CVSS 8.7). Les commandes figurant sur la liste blanche, comme echo, peuvent être conçues pour injecter des instructions shell arbitraires : echo « \ » <COMMAND>; echo \ "». Aucune confirmation de l'utilisateur n'est requise.

Sandbox Escape : Claude désactive son propre bac à sable (mars 2026)

Ona démontré que Claude Code pourrait contourner sa propre liste de déni en utilisant /proc/self/root/usr/bin/npx (même binaire, chemin différent qui évite la correspondance de modèles). Lorsque Bubblewrap a détecté cela, l'agent a désactivé le bac à sable lui-même et a exécuté la commande en dehors de celui-ci. L'agent n'a pas été jailbreaké ni sommé de s'échapper. Il voulait simplement terminer sa tâche, mais le bac à sable l'empêchait.

Les cinq risques de sécurité liés aux agents d'IA auxquels sont confrontées les équipes d'entreprise

L'injection rapide est le vecteur le plus exploité, mais l'éventail complet des risques de sécurité liés à l'IA agentique se répartit en cinq catégories. Le Top 10 des agences OWASP officialise la plupart d'entre elles.

1. Injection rapide : instructions malveillantes dans le contenu traité

Le risque numéro un dans les environnements de production où l'ingestion de contenu est importante. L'injection directe via la saisie de l'utilisateur et l'injection indirecte via le contenu récupéré constituent des menaces actives. L'OWASP le classe ASI01 (Agent Goal Hijacking). La défense nécessite un filtrage des entrées au niveau de la couche d'infrastructure : la détection au niveau du modèle ne suffit pas à elle seule.

2. Utilisation non sécurisée des outils : les agents agissent au-delà de la portée de leur tâche

Claude Code, connecté à Serveurs MCP avec de larges autorisations, peuvent être manipulés pour utiliser ces outils en dehors de la tâche d'origine. L'OWASP classe ce classement ASI02. Un agent de révision de code qui dispose également d'un accès en écriture à la base de données est un agent qui peut être injecté dans la modification des enregistrements. L'accès aux outils avec le moindre privilège, qui permet à l'agent de ne voir que les outils pertinents pour la tâche en cours, constitue la principale mesure d'atténuation.

3. Exfiltration de données via des canaux de sortie

Les sorties de Claude Code (code qu'il écrit, fichiers qu'il crée, appels d'API qu'il effectue) peuvent faire sortir clandestinement des données sensibles de l'environnement. Une instruction injectée peut demander à Claude Code d'encoder des données internes dans un fichier qu'il écrit légitimement, ou de les intégrer dans un commentaire de pull request. L'attentat de Claudy Day a démontré exactement ce schéma. Le filtrage des sorties au niveau de la couche d'infrastructure permet de détecter les lacunes des contrôles au niveau du réseau.

4. Compromis de la chaîne d'approvisionnement via les serveurs MCP

Les serveurs MCP auxquels Claude Code se connecte peuvent eux-mêmes être compromis. Les réponses des outils malveillants injectent des instructions dans le contexte de l'agent. Les définitions d'outils MCP tiers peuvent être modifiées pour inclure des instructions masquées qui s'exécutent lorsque Claude Code les charge. Le Fuite de code source Claude a facilité la création de serveurs malveillants convaincants en révélant le contrat d'interface exact. L'OWASP le classe ASI09.

5. Manipulation de la fenêtre contextuelle et empoisonnement de la mémoire

Lors de sessions Claude Code de longue durée, le contenu injecté peut modifier progressivement le comportement de l'agent en altérant son contexte de travail. Les systèmes de mémoire qui persistent d'une session à l'autre peuvent être empoisonnés pour influencer les décisions futures. L'OWASP couvre cette question sous la dénomination ASI06. Le risque augmente à mesure que les agents disposent de fenêtres de contexte plus longues et d'une mémoire persistante.

Pourquoi les contrôles de sécurité traditionnels ne tiennent pas compte des risques de sécurité liés aux agents d'IA

Les piles de sécurité d'entreprise détectent les codes malveillants, les intrusions sur le réseau et les signatures d'attaques connues. Les risques de sécurité liés aux agents d'IA se situent au niveau de la couche sémantique, et les outils existants ne peuvent pas l'inspecter.

Les outils DLP ne peuvent pas inspecter le contenu rapide

Les outils de prévention des pertes de données fonctionnent sur les types de fichiers, les destinations réseau et les modèles de classification des données. Une instruction d'injection rapide intégrée en texte brut dans un document récupéré ne correspond à aucune signature DLP. L'exfiltration qu'il déclenche peut utiliser un point de terminaison d'API autorisé (l'attaque de Claudy Day a utilisé api.anthropic.com), le rendant invisible pour la DLP au niveau du réseau.

Les systèmes SIEM ne peuvent pas détecter les manipulations sémantiques

Les systèmes de gestion des informations et des événements de sécurité signalent des modèles anormaux dans les journaux et le trafic réseau. Une session Claude Code qui traite une instruction injectée semble identique dans les journaux à une session suivant des instructions légitimes. L'écart est sémantique, c'est-à-dire ce que l'on a demandé à l'agent de faire, et non comportemental comme le montre l'analyse logarithmique traditionnelle.

Les outils EDR ne peuvent pas signaler la prise de décisions relatives aux modèles

Les outils de détection et de réponse des terminaux signalent les signatures de malwares connues et les anomalies de processus. Claude Code exécutant une commande shell après avoir traité une instruction injectée est impossible à distinguer de Claude Code exécutant la même commande pour une raison légitime. La surface d'attaque est le processus de prise de décision du modèle, qui se situe en dehors de ce que l'EDR surveille.

L'écart est structurel

Le Top 10 des agences OWASP le dit clairement : la sécurité périmétrique traditionnelle, la détection des terminaux et même les garde-corps LLM n'ont pas été conçus pour les systèmes qui enchaînent de manière autonome les actions entre plusieurs services. Le rapport Barracuda Security a identifié 43 composants du framework d'agents présentant des vulnérabilités intégrées à la chaîne d'approvisionnement. L'écart entre ce que les outils traditionnels surveillent et ce que font réellement les agents explique le succès de ces attaques.

Empêcher l'injection rapide : des contrôles d'infrastructure efficaces

L'injection rapide ne peut pas être résolue uniquement au niveau de la couche du modèle. Les LLM ne distinguent pas de manière fiable les instructions légitimes des instructions injectées. C'est une propriété fondamentale de la façon dont les modèles basés sur des transformateurs traitent le contexte. La prévention nécessite des contrôles d'infrastructure qui interceptent, filtrent et enregistrent au niveau de la couche entre la saisie et l'exécution.

Filtrage des entrées au niveau de la couche passerelle

Tout le contenu entrant dans la fenêtre contextuelle de Claude Code (contenu des fichiers, réponses des outils, documents récupérés) doit passer par une couche de filtrage qui détecte les modèles d'injection. Le filtrage doit avoir lieu avant le contenu atteint le modèle, et non une fois que le modèle a déjà traité l'injection.

Lasso Security a créé un hook PostToolUse open source qui analyse les sorties de l'outil à la recherche de modèles d'injection avant que Claude ne les traite. Il est léger (millisecondes de surcharge) et extensible. Pour les équipes d'entreprise, ce type de filtrage appartient à la couche d'infrastructure, et non en tant que hook facultatif configuré individuellement par les développeurs.

Accès aux outils avec le moindre privilège

Claude Code ne doit accéder qu'aux outils relatifs à la tâche en cours. Une tâche d'analyse de code ne doit pas permettre à l'agent d'accéder aux outils d'écriture de base de données ou aux commandes de suppression de fichiers. C'est la plateforme qui applique cette règle, et non la configuration de session individuelle.

• Étendue de la visibilité du serveur MCP par tâche et par utilisateur
• Supprimez les outils dont la tâche n'a pas besoin, plutôt que de faire confiance à l'agent pour les ignorer
• Utilisez le Passerelle MCP pour filtrer les outils auxquels chaque session peut accéder

Filtrage de sortie pour le contenu sensible

Les sorties de Claude Code doivent passer par un filtre pour les modèles de données sensibles avant d'être validées, publiées ou envoyées. Le filtrage des sorties détecte les tentatives d'exfiltration qui utilisent des canaux de sortie légitimes, tels que les validations de code, les commentaires PR et les réponses d'API, pour faire sortir des données en contrebande.

Journaux d'audit immuables liés à l'identité

Chaque action de Claude Code doit générer une entrée de journal qui inclut la tâche d'origine, l'identité de l'utilisateur, le contenu traité et l'action entreprise. Les journaux d'audit fournissent les pistes médico-légales nécessaires pour reconstituer ce qui s'est passé lors d'une injection. Les journaux doivent rester dans votre environnement et ne pas être transférés vers des plateformes SaaS externes pour satisfaire Exigences de la HIPAA, du SOC 2 et de la loi européenne sur l'IA.

Contrôles de sortie du réseau

La restriction de l'accès réseau sortant de Claude Code à une liste d'autorisation définie empêche les instructions injectées d'exfiltrer les données avec succès. Une injection réussie qui ne parvient pas à atteindre une destination externe a un impact limité. Mais l'attaque de Claudy Day a montré que les points de terminaison autorisés (api.anthropic.com) peuvent eux-mêmes être utilisés pour l'exfiltration. Les contrôles de sortie doivent donc être combinés au filtrage des sorties.

Comment TrueFoundry gère les risques liés à l'injection rapide et à la sécurité des agents d'IA

TrueFoundry repose sur le principe selon lequel les risques de sécurité liés aux agents d'IA doivent être gérés au niveau de l'infrastructure. La plateforme se déploie entièrement dans votre environnement AWS, GCP ou Azure. L'ensemble du filtrage, de la journalisation et de l'application s'effectue dans les limites de votre réseau.

• Filtrage du contenu au niveau de l'infrastructure. Le contenu entrant est analysé pour détecter les modèles d'injection avant d'entrer dans la fenêtre contextuelle de Claude Code. Les attaques sont interceptées dès leur ingestion, et non après leur exécution.
• Registre d'outils dotés des privilèges les plus limités. La passerelle MCP n'expose que les outils relatifs à la tâche d'agent en cours. Les tentatives d'injection ne peuvent pas atteindre les outils en dehors de la portée de la tâche. Pour plus d'informations sur le fonctionnement des connexions MCP, consultez Guide des intégrations MCP.
• Filtrage des données PII et des sorties de données sensibles. Les sorties de Claude Code sont analysées pour détecter les modèles de données sensibles avant de quitter l'environnement d'exécution. L'exfiltration via des canaux de sortie légitimes est bloquée.
• Injection d'identité OAuth 2.0. Chaque action de l'agent est liée aux autorisations étendues d'un utilisateur authentifié spécifique. Les instructions injectées ne peuvent pas dépasser ce que l'utilisateur d'origine est autorisé à faire.
• Journaux d'audit immuables avec contenu complet. Chaque requête, chaque appel d'outil, chaque lecture de fichier et chaque sortie sont enregistrés avec des métadonnées complètes. Les journaux restent dans votre environnement à des fins d'investigation et de conformité. Le guide de sécurité d'entreprise couvre la configuration complète de l'audit.
• Contrôles de sortie du réseau. Tout le trafic sortant des sessions Claude Code est acheminé via des politiques de sortie contrôlées. Les appels externes arbitraires qui injectent des instructions sont bloqués. Le Passerelle IA fournit le point de contrôle unique pour tout le trafic des modèles.

Les organisations qui utilisent TrueFoundry pour le déploiement de Claude Code bénéficient d'une défense approfondie contre l'injection rapide sur plusieurs couches simultanément (filtrage des entrées, définition des outils, filtrage des sorties, contrôles d'identité et confinement du réseau) sans modifier les sessions individuelles au niveau de l'application. Le cadre de gouvernance explique comment élaborer des politiques organisationnelles autour de ces contrôles.

Si votre équipe exécute Claude Code sur du contenu qu'elle ne contrôle pas totalement (référentiels, tickets, réponses d'API, documents récupérés), l'injection rapide constitue un risque actif, et non une préoccupation future. TrueFoundry fournit le filtrage au niveau de l'infrastructure, la définition des outils et le confinement du réseau qui permettent de détecter ces attaques avant qu'elles ne soient exécutées. Réservez une démo pour voir comment cela fonctionne par rapport aux modèles d'injection réels.