Des chercheurs en cybersécurité offensive expliquent que les garde-fous imposés par OpenAI et Anthropic compliquent leur travail sur les vulnérabilités inconnues et les preuves de concept. Ils décrivent des refus de réponse, des sorties trop génériques et des limites sur l’assistance au code, y compris pour des usages défensifs. Le débat porte sur l’équilibre entre réduction des abus et maintien d’outils utiles aux professionnels.
Dans les laboratoires comme dans les programmes de bug bounty, l’IA est devenue un accélérateur de lecture de code, de triage et de documentation. Mais quand l’assistant bloque, la friction se transforme en coût, et parfois en angle mort.
OpenAI et Anthropic durcissent les garde-fous sur l’aide à l’exploitation
Les chercheurs interrogés décrivent un changement de posture des grands modèles de langage, avec des politiques de sûreté plus strictes sur tout ce qui ressemble à de l’exploitation ou à de la création d’outils offensifs. Dans les faits, la frontière entre assistance légitime et facilitation d’abus est délicate, car une même explication peut servir à corriger une faille ou à l’exploiter. Les garde-fous se traduisent par des refus explicites, des réponses abrégées, ou des reformulations qui évitent des détails opérationnels.
Plusieurs profils sont concernés, du chasseur de failles indépendant au chercheur salarié. Leur point commun, travailler sur des cas où l’information est incomplète, un crash non expliqué, un comportement anormal, un binaire obfusqué. Ils cherchent une compréhension fine, des hypothèses testables, une aide à structurer une preuve de concept. Or, selon eux, les modèles deviennent plus prudents dès qu’apparaissent des termes comme RCE, buffer overflow, payload ou même des API courantes d’instrumentation.
Les entreprises d’IA défendent une logique de réduction du risque. Un assistant capable de proposer un enchaînement d’étapes peut aussi servir à des acteurs malveillants, y compris peu expérimentés. Dans cette optique, les politiques visent à empêcher la génération de code offensif prêt à l’emploi et de procédures détaillées. Mais sur le terrain, les chercheurs affirment que l’effet est parfois plus large que prévu, bloquant aussi des demandes de contextualisation, de compréhension de primitives mémoire ou de comparaison entre techniques.
Un autre point revient souvent, l’incohérence. À requêtes proches, les réponses varient selon la formulation, la session, ou le modèle. Des chercheurs disent passer du temps à reformuler pour obtenir une explication générale acceptable, sans entrer dans des détails interdits. Ce temps de contournement n’est pas neutre, surtout dans des fenêtres de divulgation coordonnée, où il faut documenter vite, reproduire, puis fournir aux éditeurs des éléments fiables.
La conséquence la plus citée n’est pas l’impossibilité de travailler, mais une baisse de productivité sur des tâches intermédiaires. Les chercheurs gardent leurs débogueurs et leurs environnements de test, mais perdent un assistant capable de condenser une analyse, de proposer des pistes, de relire une description de vulnérabilité, ou de transformer des notes en rapport exploitable pour un correctif. Pour eux, les garde-fous de OpenAI et Anthropic modifient l’ergonomie de la recherche plus qu’ils ne l’arrêtent, avec un coût concentré sur les petites équipes.
La recherche de vulnérabilités dépend de détails techniques souvent filtrés
La découverte de failles repose sur une accumulation de détails, comportements de fonctions, contraintes de compilation, particularités d’un parseur, conditions d’un dépassement, ou logique d’authentification. Les chercheurs expliquent que les assistants IA étaient utiles pour accélérer la lecture de code et la compréhension d’un composant complexe, en proposant une cartographie des flux, des points d’entrée et des hypothèses. Les garde-fous, eux, tendent à supprimer précisément ce qui est le plus utile, les étapes concrètes et les exemples proches de la réalité.
Un exemple fréquent concerne les preuves de concept. Une PoC sert à démontrer un impact, pour convaincre un éditeur, prioriser un correctif, ou alimenter un avis de sécurité. Or, la génération d’un squelette de PoC, même minimal, peut être interprétée comme une aide à l’exploitation. Les chercheurs disent se retrouver avec des explications générales sur la sécurité, sans l’artefact qui permet de reproduire de manière contrôlée. Ils soulignent que la reproductibilité est centrale, sans reproduction, la discussion se transforme en débat d’opinions.
Le filtrage touche aussi la phase de triage, quand un crash apparaît dans un fuzzer. L’IA pouvait aider à lire une trace, à distinguer un bug bénin d’une condition exploitable, à suggérer des tests supplémentaires. Désormais, certains affirment que la trace ou le contexte suffit à déclencher un refus. Même quand le modèle répond, il reste parfois au niveau de recommandations génériques, mettre à jour, activer l’ASLR, utiliser des compilations renforcées. Ces conseils sont pertinents, mais ils ne répondent pas à la question du chercheur, comprendre la cause exacte et la surface d’attaque.
Les chercheurs mentionnent aussi les environnements où la nuance est essentielle, comme l’analyse de sandbox, de conteneurs, ou de chaînes CI/CD. Une demande sur un contournement de politique peut être bloquée, même si l’objectif est de valider la robustesse d’un produit avant déploiement. Dans les grandes organisations, cette validation relève du contrôle interne, et l’IA était utilisée comme aide à la documentation et à la préparation de tests. Le filtrage peut alors déplacer la charge vers des ressources humaines plus rares.
Un enjeu sous-jacent concerne la standardisation du langage. Les modèles ont tendance à associer certains mots-clés à des usages malveillants. Les chercheurs expliquent devoir éviter des termes techniques pourtant normaux dans leur domaine, ou remplacer par des périphrases, ce qui augmente le risque de malentendu. Cette friction linguistique pénalise la précision, alors que la recherche de vulnérabilités se joue souvent sur une condition de bord ou une hypothèse mal formulée.
À l’inverse, certains reconnaissent que ces limites peuvent réduire la diffusion de scripts offensifs de bas niveau. Mais ils estiment que la majorité des abus sérieux ne dépend pas d’un assistant grand public. Selon eux, la valeur ajoutée est surtout pour les équipes défensives et les chercheurs responsables, qui utilisent l’IA comme accélérateur de compréhension plutôt que comme générateur d’armes numériques.
Les chercheurs contournent via modèles locaux et outils spécialisés
Face aux refus, une partie de la communauté se tourne vers des solutions alternatives. Les chercheurs évoquent l’usage de modèles open source exécutés localement, de configurations auto-hébergées, ou d’assistants intégrés à des environnements de développement sans filtrage centralisé. L’intérêt est double, réduire les blocages et garder le contrôle sur les données, traces de crash, extraits de code propriétaires, éléments parfois sensibles dans un cadre de divulgation.
Cette bascule a un coût. Exécuter un modèle local performant nécessite du matériel, des GPU, une maintenance, et une sélection attentive des modèles et des poids. Les petites structures n’ont pas toujours les moyens. De plus, les modèles locaux ne rattrapent pas systématiquement les meilleurs modèles commerciaux en qualité de raisonnement, de synthèse, ou de rédaction. Les chercheurs décrivent un arbitrage, plus de liberté, mais parfois moins de finesse.
Les outils spécialisés reprennent aussi de l’importance. Débogueurs, désassembleurs, frameworks de fuzzing, instrumentation, analyseurs statiques. L’IA n’a jamais remplacé ces briques, mais elle réduisait le temps entre un signal et une hypothèse. Quand l’IA se retire, la méthode redevient plus artisanale, lecture ligne par ligne, tests manuels, documentation interne. Pour des équipes expérimentées, cela reste possible, mais l’industrialisation est plus lente.
Certains chercheurs expliquent également segmenter leurs demandes, en posant des questions plus abstraites, sur des principes, des patterns, des classes de vulnérabilités, sans inclure de détails exploitables. Ils obtiennent alors des réponses utiles pour cadrer une analyse, puis appliquent eux-mêmes aux cas concrets hors assistant. Cette stratégie réduit la valeur immédiate de l’IA, mais conserve un apport pédagogique et méthodologique.
Un autre contournement consiste à utiliser l’IA pour des tâches périphériques, rédaction d’un avis de sécurité, reformulation d’un rapport, clarification d’un impact, préparation d’un message de divulgation responsable. Sur ces volets, les garde-fous sont moins pénalisants. Les chercheurs disent gagner du temps sur la communication, même si le cur technique reste contraint.
Cette évolution crée une fracture entre acteurs. Les grandes entreprises peuvent financer des solutions internes, des modèles privés, des politiques adaptées. Les indépendants et petites équipes dépendent davantage des services publics, et subissent plus directement les limites. Pour eux, la question devient aussi économique, qui peut se payer l’assistant utile, et qui doit bricoler.
Un arbitrage entre prévention des abus et soutien au bug bounty
Les politiques de sûreté répondent à un risque réel, la possibilité de démocratiser des capacités offensives. Les fournisseurs d’IA cherchent à limiter la génération de contenus qui facilitent des intrusions, des vols de données ou des attaques. Sur le principe, peu de chercheurs contestent l’objectif. Le désaccord porte sur la granularité, et sur la capacité à distinguer une demande de recherche responsable d’une demande malveillante.
Dans l’écosystème de la divulgation, le temps est un facteur critique. Les programmes de bug bounty imposent souvent des délais, des règles de preuve, et une documentation claire. Un assistant IA qui refuse de produire un exemple reproductible peut ralentir la validation par l’éditeur. Les chercheurs expliquent que ce ralentissement peut décourager la divulgation responsable, surtout quand la rémunération est incertaine et que l’effort augmente.
Les garde-fous peuvent aussi avoir un effet paradoxal, pousser des chercheurs vers des outils moins encadrés. Les modèles locaux, ou des services moins stricts, peuvent devenir la norme pour les usages offensifs, y compris légitimes. Du point de vue des fournisseurs, cela déplace le risque hors de leur périmètre. Du point de vue collectif, cela fragmente les pratiques et réduit les opportunités de créer des canaux sécurisés entre l’industrie de l’IA et la recherche en sécurité.
Des pistes sont discutées dans la communauté, accès gradué, vérification d’identité, programmes pour chercheurs, environnements isolés, ou politiques adaptées aux professionnels certifiés. Mais ces mécanismes posent des questions de gouvernance, qui décide, sur quels critères, et comment éviter d’exclure des chercheurs compétents hors des circuits institutionnels. Les bug bounties reposent souvent sur des autodidactes, et une barrière administrative peut réduire la diversité des contributions.
À court terme, la tendance décrite par les chercheurs est une utilisation plus prudente des assistants grand public, et un retour vers des workflows hybrides. L’IA reste utile pour comprendre, rédiger et organiser, mais moins pour accélérer des étapes proches de l’exploit. À mesure que les attaques assistées par IA deviennent un sujet public, les fournisseurs devraient continuer à ajuster leurs politiques, avec une tension persistante entre sécurité d’usage et utilité pour la recherche.
