Corriger l'erreur de prompt sensible dans Cursor

L'erreur de prompt sensible est l'un des messages les plus déroutants de Cursor car elle survient au milieu d'un travail légitime de sécurité, médical ou juridique. Ce guide explique ce qu'est réellement cette erreur, quelles entrées la déclenchent, les contournements qui vous débloquent de manière fiable et comment signaler un faux positif lorsque le blocage était injustifié.
Ce que signifie l'erreur de prompt sensible
L'erreur n'est pas générée par Cursor. Elle provient d'un classificateur de sécurité côté Anthropic qui filtre les requêtes avant qu'elles n'atteignent un modèle Claude. Lorsque le classificateur signale la requête et le contexte combinés comme sensibles, Anthropic refuse la requête et Cursor remonte ce refus sous forme d'erreur dans le chat.
Faits clés sur le blocage :
- Il s'agit d'une décision de classificateur, pas d'une décision de modèle. Le modèle ne voit jamais la requête.
- Cela s'applique aux modèles Anthropic, donc vous le verrez avec les variantes Opus et Sonnet.
- C'est déclenché par la requête plus le contexte joint, et non par votre intention ni votre intitulé de poste.
- Cela peut se déclencher sur une seule requête et disparaître à la suivante après un léger changement de formulation ou de contexte.
Comme le classificateur travaille sur la texture plutôt que sur l'intention, un testeur d'intrusion et un attaquant peuvent soumettre un texte quasi identique et obtenir le même résultat. C'est la racine de presque tous les faux positifs.
En pratique, la solution n'est pas de dissimuler ce que vous faites, mais de l'énoncer clairement et de garder les artefacts bruts hors du contexte joint. Un relecteur qui écrit « explique la cause racine et le correctif » obtient une réponse utile. Le même relecteur qui colle un exploit non élagué à côté de « fais fonctionner ceci » se fait bloquer. La profondeur technique que vous recevez change à peine, mais la probabilité d'un blocage chute nettement.
Cursor ne peut pas simplement « désactiver » ce classificateur depuis le client. Il est imposé en amont par Anthropic pour les modèles qu'elle héberge. La solution pratique consiste à changer ce que vous envoyez, à changer de modèle, ou les deux.
Symptômes que vous verrez
Le blocage apparaît sous quelques formes reconnaissables. Associer le symptôme à la cause accélère votre correction.
Texte d'erreur dans le chat
Vous verrez typiquement quelque chose de proche de l'une de ces lignes :
The request was blocked because it contains sensitive content.
Please rewrite your request or start a new chat.
Error: prompt contains potentially sensitive content (Anthropic)
The model declined this request. This may be due to the content of
your prompt or the attached context. Try rephrasing or removing files.
La formulation exacte varie selon les versions de Cursor et les variantes de modèles, mais le schéma est stable : un refus, une suggestion de reformuler, et parfois une mention du contexte joint.
Le chat s'arrête au milieu d'une réponse
Parfois le classificateur laisse passer la requête puis un tour suivant le fait trébucher. Le résultat visible est une réponse qui s'arrête en cours de route, suivie de l'erreur de sensibilité au tour suivant. Cela signifie généralement que la sortie antérieure de l'assistant a introduit du texte signalé dans l'historique de la conversation.
Cela fonctionne sur d'autres modèles
Si la même requête réussit sur GPT, Gemini ou Grok mais échoue sur Opus ou Sonnet, le classificateur Anthropic est la contrainte. C'est un signal fort et cela pointe directement vers le contournement par changement de modèle.
Échecs répétés sur le même chat
Certains chats deviennent « empoisonnés » : une fois qu'un contenu signalé est dans l'historique, chaque tour ultérieur le renvoie. Repartir de zéro est souvent la seule solution fiable pour un fil empoisonné.
Dégradation silencieuse avant un blocage dur
Certaines sessions se dégradent avant d'échouer franchement. Le modèle raccourcit ses réponses, refuse une sous-étape ou répond à une autre question que celle posée. Ce sont souvent des pressions précoces du classificateur sur le contexte environnant. Si vous remarquez ce schéma, nettoyez le contexte avant que l'erreur dure n'arrive.
Échecs qui se déplacent entre les tours
Une requête peut passer au premier tour et échouer au troisième, car la sortie intermédiaire de l'assistant a ajouté du nouveau matériau signalé à l'historique. C'est pourquoi réessayer dans le même fil n'est pas fiable, et pourquoi démarrer un nouveau chat résout tant de cas.
Ce qui le déclenche
Le classificateur réagit à des motifs, pas à l'intention de votre projet. Les catégories suivantes représentent la majorité des déclencheurs.
| Déclencheur | Pourquoi il se déclenche | Exemple dans un flux légitime |
|---|---|---|
| Sortie d'outil de sécurité | Ressemble à de l'outillage d'attaque | Sortie de Semgrep ou Burp listant des charges d'injection |
| Code d'exploit ou de PoC | Ressemble à du code d'exploit fonctionnel | Un reproducteur de CVE pour une revue de correctif |
| Logs de scan bruts | Denses en tokens signalés | Sortie complète de nmap ou nuclei collée en bloc |
| Identifiants ou blobs encodés | Ressemble à des secrets et des charges utiles | Chaînes Base64, tokens ou dumps hachés |
| Contenu médical ou juridique | Mots-clés de domaine sensible | Notes d'une revue HIPAA ou de conformité |
| Violence dans du contenu de jeu | Langage violent hors contexte | Dialogue de combat ou conception d'un système de dégâts |
| Gros fichiers collés | Le contenu mixte pousse de nombreux signaux | Un fichier entier de dépôt joint sans élagage |
Une seule catégorie déclenche rarement un blocage à elle seule. Le classificateur a tendance à se déclencher lorsque plusieurs signaux s'empilent : par exemple, un log de scan brut avec des blobs encodés, collé à côté de code en forme d'exploit, dans une requête qui demande un « plan d'attaque ».
Les catégories ci-dessus sont illustratives, pas exhaustives. De nouveaux déclencheurs émergent à mesure que les modèles et les classificateurs changent, donc traitez tout blocage récurrent comme un signal pour inspecter ce qui se trouve dans le contexte joint plutôt que comme une liste figée à mémoriser.
Pourquoi cela arrive dans un travail légitime
L'ingénierie de sécurité, de santé et juridique exige régulièrement du texte qui ressemble exactement au contenu que le classificateur est conçu pour arrêter. C'est normal et attendu.
- Tests d'intrusion : les charges d'exploit, les PoC et les rapports de vulnérabilité sont le livrable.
- Analyse de malwares : les chaînes d'échantillons, le désassemblage et les IOC sont intrinsèquement suspects en apparence.
- Revues de sécurité : examiner un correctif pour une vulnérabilité implique de lire le code vulnérable.
- Outillage red team : écrire ou déboguer de l'outillage offensif se lit comme une intention offensive.
Le classificateur ne peut pas distinguer « aide-moi à corriger ce CVE » de « aide-moi à exploiter ce CVE » par le seul ton, donc le travail honnête se fait piéger. Votre tâche est d'envoyer le même contenu technique sous une forme qui se lit comme une remédiation plutôt qu'un plan d'attaque.
Un test utile avant d'envoyer une requête sensible : lisez-la comme si un inconnu la recevait sans contexte sur votre rôle. Si le premier paragraphe pouvait être pris pour une demande de nuire, le classificateur le fera probablement aussi. Réécrire pour cet inconnu suffit généralement à lever le blocage.
Contournements immédiats
Parcourez cette liste du plus léger au plus lourd. La plupart des blocages se lèvent dans les deux ou trois premières étapes.
Ordre des opérations
Commencez par le changement le plus léger qui vous garde sur votre modèle préféré : reformuler ou expurger. Si cela échoue, restreignez le contexte. Ne changez de modèle qu'après que les changements de formulation ont cessé de fonctionner, et ne démarrez un nouveau chat que lorsque le fil lui-même est le problème. Travailler dans cet ordre évite du churn inutile et garde votre choix de modèle stable quand il n'y a aucune raison d'en changer.
1. Reformuler la requête
Ouvrez avec l'objectif défensif et décrivez l'artefact de manière neutre. Remplacez « écris un exploit pour X » par « explique la cause racine de X et le correctif qui la résout ». Remplacez « comment contourner Y » par « quel contrôle empêche Y et comment vérifier qu'il est activé ».
2. Reformuler explicitement l'intention
Énoncez l'objectif dès la première phrase. Des formules comme « à des fins défensives », « dans le cadre d'une revue de remédiation » et « pour écrire un test de non-régression » donnent au classificateur un contexte que le texte brut n'a pas.
3. Scinder le contexte
Envoyez le matériau suspect isolément et posez une question étroite à son sujet, plutôt que de le regrouper avec une demande large du type « analyse tout ». Moins de signaux empilés signifie une probabilité plus faible de faire trébucher le classificateur.
4. Expurger les extraits signalés
Remplacez les octets réels par des placeholders. Substituez REDACTED_TOKEN, REDACTED_PAYLOAD ou <secret-value> et demandez au modèle de raisonner sur la structure et la forme plutôt que sur le contenu littéral.
Instead of pasting the raw payload:
payload = b"\x90\x90\x90...\xcc"
Paste a redacted form:
payload = b"<REDACTED_SHELLCODE>"
Length: 412 bytes
Ask: what defenses would detect this class of payload at the WAF layer?
5. Démarrer un nouveau chat
Si le fil est empoisonné par une sortie signalée antérieure, une nouvelle conversation écarte cet historique. C'est souvent plus rapide que d'essayer de nettoyer un vieux fil.
6. Réduire le contexte joint
Détachez les fichiers mentionnés avec @ et les blocs collés dont vous n'avez pas besoin. Chaque fichier supplémentaire ajoute de la surface sur laquelle le classificateur peut réagir.
7. Changer de modèle
Déplacez la tâche sur un modèle non Anthropic : GPT, Gemini ou Grok. Le classificateur est spécifique à Anthropic, donc le même contenu passe généralement ailleurs.
8. Attendre et réessayer
Le comportement du classificateur n'est pas parfaitement déterministe dans le temps. Une nouvelle tentative après une courte attente réussit parfois sans changement, même si vous ne devez pas compter sur cela comme correctif principal.
Ce qu'il ne faut pas faire
Tout aussi important est ce qu'il faut éviter, car ces schémas font perdre du temps et peuvent aggraver le blocage :
- Ne collez pas la même requête bloquée de manière répétée ; des entrées identiques ont tendance à échouer identiquement
- N'escaladez pas vers une requête de style « jailbreak » ; cela augmente la sensibilité au lieu de la réduire
- Ne collez pas plus de contenu brut en espérant clarifier ; le contexte ajouté n'ajoute que des signaux
- Ne supposez pas que le modèle fonctionne mal ; la requête n'a jamais atteint le modèle
- Ne réutilisez pas un fil après qu'il commence à échouer systématiquement ; son historique est le problème
- Ne modifiez pas un seul mot et renvoyez instantanément ; les petites modifications aident rarement, les reformulations plus larges si
Pour un blocage dur sur une tâche substantielle, changez d'abord vers un modèle non Anthropic, puis réessayez éventuellement plus tard sur Sonnet avec un contexte plus court et plus propre. Changer de modèle lève le blocage immédiatement et vous maintient en mouvement.
Prévention à long terme
Les blocages sont pénibles mais réductibles. L'objectif est de garder votre contexte ciblé et exempt de matériau brut signalé.
Gardez les règles ciblées et courtes
Un fichier .cursor/rules de plusieurs centaines de lignes est joint à de nombreuses requêtes et multiplie la probabilité d'un déclenchement accidentel. Gardez les règles limitées à ce dont le modèle a réellement besoin pour le travail en cours.
Ne collez jamais de secrets bruts
Ne collez pas de clés, de tokens ou de dumps. Si vous devez raisonner sur un format de secret, utilisez un placeholder et décrivez la forme. Cela évite entièrement le déclencheur identifiants-et-blobs.
Résumez la sortie de scan
Ne collez pas un dump de scanner de mille lignes. Extrayez les constats qui comptent, gardez les dix principaux et décrivez le reste en prose. Les résumés portent bien moins de tokens signalés.
Ne joignez que ce dont vous avez besoin
Utilisez les mentions @ pour joindre des fichiers précis plutôt que de faire glisser tout un répertoire. Un contexte étroit est à la fois moins cher et moins susceptible de faire trébucher un classificateur.
Gardez un projet à contexte sûr
Pour un travail sensible récurrent, gardez un projet dédié dont les fichiers contiennent du contenu assaini, de style documentation : analyses de cause racine, notes de remédiation et plans de test plutôt que des artefacts bruts. Pointez les questions sensibles vers ce projet.
Suivez quels fichiers sont risqués
Tenez une courte note des fichiers de votre projet qui tendent à déclencher des blocages, comme les exports de scan bruts ou les charges utiles de fixtures. Référencez-les par leur nom lorsque c'est nécessaire, et évitez de les joindre par défaut. Une liste de risques tenue à jour vaut mieux que redécouvrir le même déclencheur chaque semaine.
Préférez la structure au volume
Un contexte long et indifférencié invite à des signaux empilés. Décomposez une grande demande en une série de petites requêtes à objectif unique, chacune avec le minimum de contenu joint. Cela améliore aussi la qualité des réponses, donc le changement paie deux fois.
Une fois qu'une réponse signalée atterrit dans une conversation, les tours ultérieurs la renvoient comme historique. Si un chat a commencé à échouer de manière répétée, traitez-le comme compromis et démarrez-en un nouveau plutôt que de vous battre contre le blocage tour après tour.
Travailler avec du contenu de sécurité et de conformité
Certains domaines ont régulièrement besoin de contenu qui se lit comme sensible. Les schémas suivants font passer ces tâches sans blocages répétés.
Tests d'intrusion et red team
Présentez le travail comme une remédiation dès la première ligne, et gardez la cible abstraite.
- Posez des questions sur la classe de vulnérabilité et son correctif, pas sur un exploit étape par étape
- Remplacez les noms d'hôtes, tokens et charges utiles réels par des placeholders
- Décrivez les constats en prose, et ne joignez que le code précis en cours de revue
- Gardez un libellé de périmètre explicite, par exemple « évaluation autorisée, périmètre : environnement de test interne »
Analyse de malwares et forensic
Les chaînes d'échantillons et le désassemblage se lisent comme hostiles par défaut, donc un schéma isolé et documenté fonctionne le mieux.
- Déplacez l'échantillon brut dans un fichier séparé et référencez-le par son nom plutôt que de le coller
- Posez des questions sur les classes de comportement et les règles de détection plutôt que « que fait ceci »
- Résumez les indicateurs plutôt que de coller des logs complets
- Gardez un projet d'analyse dédié dont les fichiers indexés contiennent des artefacts assainis
Données médicales, juridiques et réglementées
Le contenu de domaines réglementés porte ses propres mots-clés qui peuvent faire trébucher le classificateur même lorsque la tâche est purement technique.
- Supprimez les identifiants de patients, clients ou dossiers et remplacez-les par des valeurs synthétiques
- Gardez la question technique séparée du récit du domaine
- Préférez les descriptions de schéma et de structure au contenu littéral des enregistrements
- Décrivez la forme des données et posez des questions sur la logique de traitement plutôt que de lire des enregistrements réels
Construire un ensemble de références assainies
Pour un travail récurrent, assemblez un petit ensemble de fichiers de style documentation qui décrivent le même matériau en termes neutres : analyses de cause racine, notes de remédiation, plans de test et descriptions de contrôles. Pointez les questions sensibles vers ces fichiers plutôt que vers des artefacts bruts. En quelques semaines, cela devient le chemin fiable, et le chemin des artefacts bruts s'estompe.
Remplacer les noms par des faux aide, mais une formulation clinique ou juridique dense peut encore déclencher le classificateur à elle seule. Si cela arrive, restreignez la requête à la question technique précise et abandonnez entièrement le récit environnant.
Choisir entre changer de modèle et réécrire la requête
Les deux correctifs fonctionnent, et le bon dépend de la place de Claude dans votre tâche.
| Situation | Meilleur premier geste | Pourquoi |
|---|---|---|
| Question ponctuelle bloquée | Réécrire la requête | Vous garde sur votre modèle préféré |
| Grand contexte déjà préparé | Changer de modèle | Évite de reconstruire les pièces jointes de zéro |
| La tâche nécessite spécifiquement Claude | Réécrire et expurger | Vous avez encore besoin du comportement de Claude |
| Blocages répétés sur un projet | Restructurer le projet | Attaquer la cause racine, pas le symptôme |
| Pression de délai | Changer de modèle maintenant, réessayer plus tard | Chemin le plus rapide pour se débloquer |
Quand réécrire la requête
Réécrivez lorsque le blocage concerne la formulation, le cadrage ou un seul extrait signalé. Ces changements sont peu coûteux, vous gardent sur Claude et produisent souvent une meilleure requête en prime, car un cadrage défensif est généralement aussi plus clair.
Quand changer de modèle
Changez lorsque le contenu est intrinsèquement signalé, lorsque le contexte est volumineux et coûteux à reconstruire, ou lorsque vous êtes sous pression de temps. GPT, Gemini et Grok n'appliquent pas le classificateur Anthropic, donc le même matériau passe généralement immédiatement.
Quand restructurer le projet
Si les blocages se répètent sur de nombreux tours d'un même travail, les fichiers du projet lui-même sont le déclencheur. Déplacez les artefacts bruts hors des chemins joints, gardez des résumés assainis dans les fichiers indexés et pointez les questions sensibles vers ces résumés. Cela retire le déclencheur à la source au lieu de rafistoler chaque requête.
Maintenez un modèle Anthropic et un modèle non Anthropic dans votre liste de modèles pour qu'un changement se fasse en un clic. Pouvoir déplacer une requête bloquée de côté en quelques secondes est ce qui transforme cette erreur d'un arrêt dur en un léger détour.
Signaler un faux positif à Anthropic via le support Cursor
Lorsqu'un blocage est manifestement injustifié et bloque un vrai travail, signalez-le. Cursor collecte ces signalements et transmet le schéma à Anthropic, et suffisamment de signalements sur le même thème changent effectivement le comportement du classificateur au fil du temps.
Ce qu'il faut inclure
Fournissez une description reproductible et minimale plutôt qu'un long récit :
Model: Claude Sonnet (or Opus)
Task: reviewing a security patch for CVE-XXXX-YYYY
Prompt (summarized): explain the root cause and write a regression test
Context attached: two files, both sanitized, no secrets
Result: sensitive prompt error, request never reached the model
Reproduced on: 3 attempts in the same chat, 1 attempt in a fresh chat
Notes: same prompt succeeded on GPT and Gemini. This reads as a false
positive on a defensive security workflow.
Incluez le nom du modèle, la requête assainie et le fait qu'elle se reproduit. Ne collez pas le contenu sensible brut lui-même dans le signalement ; une description de la forme suffit et évite de redéclencher les filtres dans l'outillage de support.
Où l'envoyer
Utilisez le formulaire de support dans l'application ou l'adresse de support publiée. Incluez le nom du modèle, la requête assainie, les étapes de reproduction et une description en une ligne de l'objectif défensif. Ne joignez rien de brut. Même si le support ne peut pas reproduire le blocage, il peut tout de même transmettre le schéma à Anthropic, et les signalements récurrents sur le même thème sont ce qui finit par faire évoluer le classificateur.
Un signalement avec une reproduction stable et un objectif défensif clair est bien plus utile qu'un signalement qui dit seulement « l'erreur continue d'arriver ». La précision est ce qui rend le schéma exploitable en amont.
Tableau de dépannage de référence
Utilisez ce tableau pour passer du symptôme au correctif sans relire tout le guide.
| Symptôme | Cause probable | Correctif |
|---|---|---|
| Erreur au premier envoi, modèle Anthropic | La requête ou le contexte a fait trébucher le classificateur | Reformulez, recadrez l'intention, expurgez ou changez de modèle |
| Fonctionne sur GPT/Gemini mais pas sur Opus/Sonnet | Classificateur spécifique à Anthropic | Basculez vers un modèle non Anthropic |
| Le chat s'arrête au milieu d'une réponse puis erreur | La sortie antérieure est désormais signalée dans l'historique | Démarrez un nouveau chat |
| Échoue à chaque tour dans un même fil | Historique de conversation empoisonné | Démarrez un nouveau chat ; ne réessayez pas sur place |
| Échoue après avoir joint un fichier | Le contenu joint porte des déclencheurs | Réduisez ou assainissez le contexte joint |
| Échoue sur un gros collage | Signaux mélangés d'un gros bloc | Scindez en requêtes plus petites et ciblées |
| Échoue sur une sortie de scan ou d'exploit | Se lit comme du matériau d'attaque | Résumez au lieu de coller la sortie brute |
| Intermittent, sans déclencheur clair | Comportement limite du classificateur | Réessayez une fois, puis changez de modèle si cela persiste |
Le schéma est le même dans tous ces cas : le classificateur lit la texture, donc vous gagnez en changeant la texture de ce que vous envoyez, en restreignant le contexte ou en déplaçant la requête vers un modèle qui n'applique pas ce classificateur.
Traitez l'erreur comme un signal sur votre contexte plutôt qu'un jugement sur votre travail. Ajuster la forme de ce que vous envoyez maintient les tâches légitimes de sécurité, de conformité et d'analyse en mouvement tout en laissant intacte la couche de sécurité pour les cas qu'elle a été conçue pour intercepter.
Tenez une courte note des contournements qui ont résolu chaque blocage rencontré. Au fil du temps, cette note devient un manuel personnel, et le prochain blocage se lève en quelques secondes au lieu de vous coûter une session de débogage.