Atténuer les jailbreaks et les injections de prompt

Le « jailbreaking » (contournement des garde-fous) et la « prompt injection » (injection de prompt) sont des tentatives visant à faire en sorte que Claude ignore ses directives ou vos instructions. Bien que Claude soit intrinsèquement résilient face à de telles attaques, les étapes supplémentaires de cette page renforcent vos garde-fous, en particulier contre les utilisations qui violent les Conditions d'utilisation ou la Politique d'utilisation d'Anthropic.

Ces attaques se répartissent en deux catégories avec des modèles de menace différents :

• Les jailbreaks et l'injection de prompt directe, où l'utilisateur de votre application est l'adversaire et élabore des entrées destinées à contourner vos garde-fous.
• L'injection de prompt indirecte, où l'utilisateur est de confiance mais Claude traite du contenu tiers (pages web, e-mails, documents, résultats d'outils) qui contient des instructions adverses.



Jailbreaks et injection de prompt directe

Dans ce modèle de menace, un utilisateur élabore délibérément des entrées pour manipuler votre application afin qu'elle produise du contenu ou effectue des actions que vous ne souhaitez pas. Ces mesures d'atténuation renforcent les garde-fous de votre application :

• Filtres d'innocuité : Utilisez un modèle léger comme Claude Haiku 4.5 pour pré-filtrer les entrées utilisateur avant qu'elles n'atteignent votre conversation principale. Utilisez les sorties structurées pour contraindre la réponse à une classification simple.

  Exemple : Filtre d'innocuité pour la modération de contenu

• Validation des entrées : Filtrez les entrées utilisateur à la recherche de motifs d'injection connus avant qu'elles n'atteignent Claude. Vous pouvez utiliser un LLM pour créer un filtre de validation généralisé en fournissant des formulations de jailbreaking connues comme exemples.

• Ingénierie de prompt : Élaborez des invites système qui mettent l'accent sur les limites éthiques et légales, et qui indiquent explicitement à Claude comment refuser.

  Exemple : Invite système éthique pour un chatbot d'entreprise

• Réagir face aux récidivistes : Ajustez les réponses et envisagez de limiter ou de bannir les utilisateurs qui tentent à plusieurs reprises de contourner les garde-fous de votre application. Par exemple, si un utilisateur particulier déclenche plusieurs fois le même type de refus (comme « sortie bloquée par la politique de filtrage de contenu »), informez l'utilisateur que ses actions violent les politiques d'utilisation pertinentes et prenez les mesures appropriées.



Injection de prompt indirecte

Dans ce modèle de menace, vous protégez vos utilisateurs contre des instructions intégrées dans du contenu que Claude lit en leur nom : le corps d'un e-mail entrant, une page web récupérée, la sortie OCR d'un fichier téléversé, ou le résultat d'un appel d'outil. Un attaquant capable d'influencer ce contenu peut y intégrer des instructions qui tentent de rediriger Claude.

Structurez votre application de manière à ce que Claude puisse distinguer de manière fiable le contenu non fiable de vos instructions :

• Placez le contenu non fiable uniquement dans les résultats d'outils. Transmettez le contenu tiers à Claude à l'intérieur de blocs tool_result, jamais dans des invites system ou des blocs text utilisateur ordinaires. Claude est entraîné à traiter les instructions qui apparaissent à l'intérieur des résultats d'outils avec un scepticisme approprié. Consultez Gérer les appels d'outils pour le format tool_result.

• Indiquez à Claude ce qu'est le contenu et d'où il provient. Dans la description de l'outil, ou dans la structure du résultat lui-même, rendez explicites la nature et la source du contenu : par exemple, qu'il s'agit du corps d'un e-mail entrant provenant d'un expéditeur inconnu, ou de texte OCR extrait d'une image téléversée par l'utilisateur. Ce contexte aide Claude à calibrer le degré de confiance à accorder aux directives intégrées.

• Énoncez la politique dans votre invite système. Indiquez explicitement à Claude que le contenu renvoyé par les outils, les documents ou les recherches constitue des données non fiables et ne doit jamais prévaloir sur l'invite système ou la demande originale de l'utilisateur.

  Exemple : Directives d'invite système pour un agent de traitement de documents

• Encodez le contenu non fiable en JSON. Dans la mesure du possible, encapsulez les chaînes tierces dans un objet JSON plutôt que de les concaténer dans du texte libre. L'échappement JSON fournit des délimiteurs non ambigus entre la charge utile non fiable et la structure environnante, de sorte qu'un attaquant ne peut pas fermer un guillemet ou une balise pour « s'échapper » vers un contexte d'instruction.

  Exemple : Résultat d'outil encodé en JSON pour un e-mail entrant

• Ne placez pas vos propres instructions dans les résultats d'outils. Étant donné que Claude traite le contenu des résultats d'outils comme des données non fiables, les instructions que vous y placez peuvent être ignorées ou signalées comme une injection potentielle. Envoyez vos instructions dans un tour user qui suit le bloc tool_result. Sur les modèles pris en charge, vous pouvez également utiliser un message système en milieu de conversation.

• Limitez l'accès de Claude aux données et actions sensibles. Appliquez le principe du moindre privilège afin qu'une injection réussie puisse causer un minimum de dégâts : ne donnez pas à Claude accès à des secrets dont il n'a pas besoin, exécutez les outils dans des environnements en bac à sable, et limitez les permissions aussi étroitement que possible.

• Filtrez les sorties d'outils avant que Claude n'agisse dessus. Appliquez le même schéma de filtrage par modèle léger que vous utilisez pour les entrées utilisateur au contenu renvoyé par vos outils. Exécutez chaque outil, transmettez sa sortie brute à un petit appel de classification avec Claude Haiku 4.5, et ne renvoyez le contenu sous forme de bloc tool_result que si le filtre ne signale aucune tentative d'injection. Utilisez les sorties structurées afin que le verdict du classificateur soit une valeur analysable sur laquelle votre application peut se brancher.

  Exemple : Filtre d'injection pour la sortie d'outil

  Vous pouvez également appliquer les schémas de validation des entrées de la section précédente aux résultats d'outils avant de les transmettre à Claude.

• Testez votre propre agent en mode « red team ». Avant le déploiement, testez votre flux de travail avec des documents, des e-mails et des sorties d'outils qui contiennent délibérément des tentatives d'injection, et confirmez que Claude les ignore et que vos étapes de filtrage et de confirmation interceptent le reste.



Surveillance continue

Analysez régulièrement les sorties à la recherche de signes d'injection réussie. Utilisez cette surveillance pour affiner de manière itérative vos prompts, votre validation et vos stratégies de filtrage.



Avancé : Chaîner les protections

Combinez les stratégies pour une protection robuste. Voici un exemple de niveau entreprise avec utilisation d'outils :

En superposant ces stratégies, vous créez une défense robuste contre le jailbreaking et les injections de prompt, garantissant que vos applications propulsées par Claude maintiennent les normes les plus élevées de sécurité et de conformité.