Une citation de Simon Willison sur Anthropic met sous pression les affirmations d’Opus 5 sur l’injection de prompts

La couverture d’Anthropic par Simon Willison a fait émerger une affirmation marquante le 25 juillet : Claude Opus 5 serait le modèle d’Anthropic le plus résistant à l’injection de prompts à ce jour. Boris Cherny, créateur de Claude Code, a mis ce résultat davantage en avant que les scores d’évaluation phares du modèle.

Cette affirmation compte, car l’injection de prompts reste l’un des obstacles les plus difficiles à surmonter pour bâtir des agents IA dignes de confiance. Un modèle performant peut parcourir des sites web, lire des messages, modifier du code et appeler des outils. Ces mêmes capacités créent des occasions pour des contenus malveillants de rediriger l’agent.

La déclaration de Cherny recadre l’histoire d’Opus 5 autour de la sécurité plutôt que de la domination des benchmarks. Elle crée toutefois aussi une exigence élevée. Une meilleure résistance du modèle doit se traduire par des systèmes déployés plus sûrs, et pas seulement par de meilleurs scores dans l’environnement d’évaluation d’Anthropic.

Ce que Boris Cherny a dit à propos d’Opus 5

Cherny a présenté la résistance à l’injection de prompts comme le résultat d’Opus 5 qui importe davantage que les scores conventionnels de capacité.

Simon Willison a publié la citation de Boris Cherny peu après l’apparition des documents de lancement du modèle. Cherny a déclaré qu’Opus 5 était le modèle d’Anthropic « le moins vulnérable à l’injection de prompts à ce jour ».

Il a ajouté que les attaques réussies étaient difficiles à mener dans les évaluations d’injection de prompts et les exercices de red teaming. Le red teaming consiste à attaquer délibérément un système afin d’identifier ses faiblesses avant que des adversaires ne les découvrent en production.

Cherny a également reconnu que ce résultat était « quelque peu enfoui » dans la fiche système. Willison a orienté les lecteurs vers la page 73 de la fiche système d’Opus 5, où Anthropic décrit ses tests d’injection de prompts.

Cet emplacement est significatif. Les lancements de modèles mettent généralement en avant les benchmarks de code, de raisonnement ou d’agents, car ces chiffres sont faciles à comparer et à commercialiser. Une évaluation de sécurité enfouie au cœur d’un document technique reçoit rarement la même attention.

Cherny a inversé cette hiérarchie. Son message était, en substance, que la résistance aux instructions malveillantes mérite davantage d’attention qu’une nouvelle avance marginale dans les benchmarks.

Ce jugement reflète l’usage croissant de Claude. Claude Code peut inspecter des dépôts, exécuter des commandes approuvées et travailler sur des tâches de développement de longue durée. D’autres agents basés sur Claude peuvent parcourir des pages externes ou traiter des documents métier.

Chaque nouvelle source de contexte introduit une nouvelle frontière de confiance. Un modèle doit distinguer les instructions de l’utilisateur, les règles du développeur et le texte non fiable provenant de sources externes.

L’injection de prompts attaque cette distinction. Un attaquant place des instructions dans un contenu qu’un agent lira, comme une page web, un e-mail, un commentaire de code ou un document partagé.

L’agent pourrait traiter ces instructions comme des commandes. Un agent compromis pourrait divulguer des informations, modifier des fichiers, détourner des outils connectés ou changer discrètement sa réponse.

L’injection directe de prompts provient de l’entrée de l’utilisateur. L’injection indirecte arrive via du contenu récupéré lors de l’exécution d’une autre tâche. Cette forme indirecte constitue le défi le plus important pour les agents utilisant des outils.

Un agent de programmation pourrait rencontrer une instruction malveillante dans un fichier de dépendance. Un agent de recherche pourrait en trouver une intégrée dans une page web. Un assistant e-mail pourrait traiter un texte hostile dans un message d’apparence ordinaire.

Cela explique pourquoi la discussion autour d’Anthropic et Simon a attiré l’attention au-delà d’un simple lancement de modèle. Cherny ne décrivait pas une fonction de sécurité cosmétique. Il abordait une faiblesse qui limite l’autorité que les utilisateurs peuvent déléguer en toute sécurité.

Son formulation reste néanmoins celle d’une affirmation comparative de l’entreprise. « Le moins vulnérable à l’injection de prompts » signifie plus résistant que les modèles précédents d’Anthropic dans les tests de l’entreprise. Cela ne signifie pas qu’il est immunisé contre toutes les attaques ni sécurisé dans chaque configuration de produit.

Cette distinction pose la tension centrale. Opus 5 peut représenter un progrès important tandis que l’injection de prompts demeure un problème non résolu à l’échelle du système.

Pourquoi la couverture d’Anthropic par Simon change le récit autour du modèle

L’affirmation concernant Opus 5 fait passer la compétition de l’intelligence brute à un comportement fiable dans des conditions hostiles.

Les annonces de modèles de pointe se livrent souvent concurrence à travers des tableaux de benchmarks. Les fournisseurs comparent les performances en programmation, raisonnement, utilisation d’outils, recherche et tâches professionnelles. Ces mesures aident les acheteurs à estimer ce qu’un modèle peut accomplir.

Elles révèlent moins ce qui se produit lorsqu’un agent rencontre un contenu délibérément trompeur. Un agent qui résout des tâches difficiles mais suit des instructions cachées peut devenir plus dangereux à mesure que ses capacités progressent.

Cela crée une relation inconfortable entre capacité et risque. Une meilleure navigation élargit les informations auxquelles un agent peut accéder. Une meilleure utilisation des outils élargit les actions qu’il peut entreprendre.

Des sessions autonomes plus longues créent également davantage d’occasions de manipulation. Une injection réussie au début d’un flux de travail peut influencer les recherches, les fichiers, les résumés et les appels d’outils ultérieurs.

La résistance à l’injection de prompts modifie donc le sens pratique de la qualité d’un modèle. La fiabilité ne consiste pas seulement à produire la bonne réponse. Elle implique aussi de préserver l’intention de l’utilisateur lorsque du contenu externe tente de la remplacer.

Anthropic a traité cette question comme une priorité récurrente dans ses fiches système de modèles publiées. Des fiches antérieures décrivaient des instructions malveillantes cachées dans des sites web ou des messages que les agents traitent pour le compte d’un utilisateur.

L’évaluation d’Opus 4.5 expliquait pourquoi ces attaques peuvent passer à l’échelle. Une charge malveillante sur une page publique peut potentiellement atteindre chaque agent qui traite cette page.

Opus 5 arrive après que cette menace est devenue plus concrète. Les agents opèrent désormais dans des navigateurs, des terminaux, des environnements de développement et des connecteurs d’entreprise. Les conséquences potentielles dépassent une simple réponse trompeuse de chatbot.

Pour les développeurs, une résistance efficace peut réduire la fréquence à laquelle un agent suit des instructions trouvées dans des données non fiables. Elle peut aussi réduire la dépendance à des filtres fragiles qui recherchent des formulations suspectes.

Pour les entreprises, cette affirmation répond à une préoccupation centrale de déploiement. Les entreprises veulent que les agents récupèrent des connaissances internes et réalisent un travail utile sans permettre à des contenus arbitraires de les rediriger.

L’accès aux connaissances augmente encore les enjeux. Un assistant peut combiner des documents privés avec des résultats de recherche externes dans une même fenêtre de contexte. Le modèle doit utiliser ces deux sources tout en respectant des niveaux de confiance différents.

C’est pourquoi les organisations ont besoin d’une gestion des connaissances rigoureuse. Connecter davantage d’informations améliore l’utilité, mais exige aussi des autorisations claires et des frontières entre les sources.

L’accent mis par Cherny met également la pression sur les fournisseurs de modèles concurrents. Les acheteurs peuvent demander si les fiches système rivales comprennent des évaluations comparables de l’injection de prompts, des environnements d’agents réalistes et des résultats avec plusieurs défenses.

Un score de capacité en tête d’affiche ne suffit plus à trancher. Les équipes soucieuses de la sécurité ont besoin de preuves sur la résistance aux attaques, les refus erronés, les frontières des outils et la récupération après des tentatives de manipulation.

Obtenir des preuves comparables reste cependant difficile. Les fournisseurs peuvent utiliser des attaques, des hypothèses de menace, des outils, des règles de notation et des mesures d’atténuation différents. Deux pourcentages impressionnants peuvent décrire des expériences très différentes.

Les tests sous-jacents peuvent également vieillir rapidement. Dès qu’une défense devient publique, les attaquants adaptent leur formulation et leurs méthodes de diffusion. Des jeux de tests statiques peuvent récompenser la reconnaissance sans mesurer la résistance généralisée.

L’affirmation d’Anthropic est donc précieuse en partie parce qu’elle invite à l’examen. La publication d’une fiche système fournit aux enquêteurs davantage de matière qu’une simple déclaration de lancement.

L’affirmation la plus solide exigera toutefois des tests reproductibles en dehors d’Anthropic. Des chercheurs indépendants ont besoin d’accéder à des systèmes représentatifs, à des jeux d’attaques et à des définitions claires du succès.

En attendant ces éléments, Opus 5 doit être considéré comme une amélioration de sécurité prometteuse. Il ne doit pas devenir une raison de supprimer les défenses autour du modèle.

Résistance du modèle contre sécurité des agents en couches

La principale confrontation n’oppose pas Opus 5 à un autre modèle ; elle oppose la résistance au niveau du modèle à la complexité d’un système d’agent complet.

Un modèle s’inscrit dans une architecture plus large. Cette architecture comprend des instructions système, du contenu récupéré, de la mémoire, des outils, des autorisations, du code applicatif, des filtres et des étapes de confirmation utilisateur.

Améliorer le modèle importe, car le modèle interprète toutes ces entrées. Il décide quelles informations sont pertinentes et quelles instructions apparentes méritent d’être suivies.

Le modèle ne peut toutefois pas déterminer de manière fiable la fiabilité de chaque source à partir du texte seul. Une instruction malveillante peut imiter un avis de politique, un message d’administrateur ou un résultat d’outil.

Le formatage offre une protection limitée. Les attaquants peuvent dissimuler des instructions dans du HTML, du texte encodé, des images, des métadonnées de documents ou du contenu qui semble sans importance pour un lecteur humain.

Un agent peut aussi transformer le contenu malveillant avant d’agir. Il pourrait résumer une page web, enregistrer ce résumé dans sa mémoire, puis le récupérer lors d’une autre tâche.

Cela crée un chemin d’attaque différé. L’action nuisible finale peut survenir longtemps après l’entrée du contenu initial dans le système.

Des recherches récentes ont commencé à examiner ce problème de persistance. L’étude Bad Memory a évalué les risques d’injection de prompts fondés sur la mémoire dans des systèmes agentiques, y compris des configurations de Claude Code et OpenAI Codex.

Sa leçon plus générale est importante, même lorsque les résultats individuels des modèles évoluent. La mémoire peut transformer une exposition temporaire en une influence persistante au fil des sessions ultérieures.

La résistance du modèle peut interrompre cette chaîne. Un modèle qui reconnaît de manière fiable les instructions non fiables est moins susceptible de les enregistrer, de les répéter ou de les utiliser comme orientations futures.

Les contrôles applicatifs restent nécessaires, car la détection peut échouer. L’architecture la plus sûre suppose qu’une partie du contenu hostile contournera chaque défense prise individuellement.

Une couche doit séparer les instructions des données. Une autre doit restreindre les outils que le modèle peut appeler. Les contrôles d’autorisation doivent limiter ce que ces outils peuvent consulter ou modifier.

Les actions à fort impact doivent nécessiter une confirmation. Envoyer des messages, modifier les paramètres d’un compte, exposer des données privées ou exécuter du code inconnu mérite une frontière plus forte que la lecture d’informations publiques.

Les développeurs doivent aussi contraindre les sorties des systèmes de récupération. Les documents récupérés peuvent porter des informations de provenance, des étiquettes de confiance et des périmètres limités au lieu d’entrer dans le prompt sous forme de texte indifférencié.

Les outils doivent disposer d’interfaces étroites. Un agent chargé de résumer des e-mails ne devrait pas recevoir automatiquement l’autorisation de transférer des messages, de supprimer des enregistrements ou d’inspecter des comptes sans rapport.

Les journaux constituent une autre couche essentielle. Les équipes doivent pouvoir reconstituer quel contenu le modèle a vu, quels signaux de raisonnement étaient disponibles, quels outils il a appelés et ce qui a changé ensuite.

La détection doit se poursuivre après le déploiement. Les schémas d’attaque évoluent, et les utilisateurs réels exposent les systèmes à des combinaisons que les tests avant lancement ne peuvent pas reproduire entièrement.

La même logique s’applique aux flux de travail d’IA personnels. Un second cerveau interrogeable devient plus utile à mesure qu’il collecte des documents locaux et des notes de réunion. Il a également besoin de limites prévisibles autour des contenus externes et des actions automatisées.

Une base de connaissances interrogeable peut réduire l’exposition inutile en maintenant le travail pertinent ancré dans des sources contrôlées. Cette conception n’élimine pas l’injection, mais elle réduit la surface d’attaque.

Les équipes de sécurité appellent couramment cela une défense en profondeur. Le principe veut qu’un contrôle défaillant ne conduise pas immédiatement à une compromission.

Opus 5 pourrait devenir une couche particulièrement précieuse, car le comportement du modèle affecte chaque étape d’une boucle agentique. Une meilleure résistance peut réduire la charge imposée aux filtres, aux politiques et aux réviseurs humains.

Elle peut aussi améliorer l’utilisabilité. Les filtres externes agressifs bloquent souvent des demandes inoffensives faute du contexte nécessaire pour distinguer les instructions légitimes des instructions malveillantes.

Un modèle plus discriminant pourrait rejeter les attaques sans refuser des documents ordinaires. Cet équilibre compte, car une défense qui interrompt le travail courant subira des pressions pour être affaiblie ou désactivée.

Anthropic doit donc démontrer davantage qu’un taux de réussite des attaques plus faible. Les acheteurs doivent comprendre si Opus 5 évite aussi une méfiance excessive envers les contenus légitimes.

Un modèle qui qualifie toute instruction inhabituelle d’hostile semblerait sûr selon certaines évaluations. Il serait frustrant dans de véritables flux de travail de programmation, de recherche et de support.

L’objectif utile est une résistance sélective. Opus 5 doit préserver la tâche autorisée, utiliser les informations externes pertinentes et rejeter uniquement les tentatives de redirection du contrôle.

C’est plus difficile que de bloquer une liste de phrases malveillantes. Cela exige du modèle qu’il raisonne sur l’autorité, la provenance, les autorisations et l’objectif initial de l’utilisateur.

L’affirmation de Cherny suggère des progrès sur ce problème. Les preuves au niveau système détermineront si l’amélioration résiste au contact d’applications complexes.

Ce que la fiche système d’Opus 5 ne peut pas établir à elle seule

L’évaluation d’Anthropic étaye une affirmation directionnelle, mais elle ne peut pas établir de manière indépendante une résistance universelle ou la sécurité en production.

Les fiches système sont des documents produits par les fournisseurs. Elles apportent une transparence utile, mais le développeur du modèle choisit les évaluations, les ensembles d’attaques, les hypothèses de déploiement et la présentation.

Cela ne rend pas les conclusions indignes de confiance. Cela signifie que les lecteurs doivent les interpréter comme des preuves rapportées par Anthropic, et non comme une certification indépendante.

L’expression « très difficile à injecter avec succès par prompt » nécessite également une condition de réussite définie. Une légère déviation par rapport aux instructions diffère d’un vol de données ou d’une action non autorisée via un outil.

La gravité de l’attaque compte. Le nombre de tentatives dont dispose un attaquant compte également. Un faible taux de réussite peut néanmoins créer un risque important lorsqu’une charge utile atteint de nombreux agents.

La citation d’Anthropic Simon ne fournit pas, à elle seule, ces détails. Les lecteurs doivent examiner la méthodologie, les limites et les paramètres de chaque évaluation dans la fiche système.

La couverture des red teams présente une autre incertitude. Des testeurs expérimentés peuvent découvrir des attaques inhabituelles, mais aucune équipe ne peut représenter chaque adversaire, langue, format de document ou intégration produit.

Les attaques automatisées offrent de l’échelle, mais elles peuvent surajuster des schémas connus. Les attaquants humains s’adaptent aux défenses, combinent des techniques et exploitent le comportement de l’application au-delà du modèle.

L’injection de prompt diffère aussi selon les environnements. Une interface de chat simple offre moins de chemins d’attaque qu’un agent navigateur doté d’authentification, de mémoire et d’accès aux fichiers.

La conception des outils peut changer le résultat, même lorsque le modèle sous-jacent reste constant. Des autorisations étendues peuvent transformer un petit échec de suivi des instructions en incident grave.

À l’inverse, des autorisations limitées peuvent empêcher les dommages après le même échec du modèle. Cela rend la configuration du produit indissociable de la sécurité du modèle.

Les tests indépendants devraient donc inclure des flux de travail complets. Les chercheurs devraient mesurer si les attaques modifient la planification, déclenchent des outils, exposent des informations, modifient la mémoire ou survivent dans des sessions ultérieures.

Ils devraient également signaler les faux positifs. Le contenu légitime peut contenir des commandes, des exemples de code, des avertissements de sécurité ou du texte d’attaque cité.

Un agent de programmation doit souvent examiner précisément le matériel qui ressemble à une attaque. Rejeter chaque fichier suspect compromettrait sa raison d’être.

Les benchmarks publics ont leurs propres limites. Une fois que des exemples entrent dans les données d’entraînement, de bonnes performances peuvent refléter la familiarité plutôt qu’une protection générale.

Les évaluateurs ont besoin d’attaques continuellement renouvelées et d’ensembles de tests cachés. Ils ont également besoin d’une notation transparente afin que les acheteurs comprennent ce que représente réellement une amélioration annoncée.

La taxonomie des menaces maintenue par le projet OWASP GenAI traite l’injection de prompt comme un risque applicatif, et non simplement comme un benchmark de modèle. Ce cadrage soutient des contrôles de déploiement en couches.

Il existe également un risque de communication. « Le moins injectable par prompt » peut devenir « l’injection de prompt est résolue » à mesure que la déclaration circule dans les publications sociales et le marketing produit.

Cherny n’a pas formulé cette affirmation plus large. Ses termes sont restés comparatifs et faisaient référence aux évaluations et au red teaming d’Anthropic.

Une couverture responsable doit préserver cette limite. Opus 5 peut être nettement meilleur tout en échouant encore face à des attaques absentes de l’évaluation.

L’interprétation la plus solide est que l’entraînement des modèles a fait progresser le niveau de référence défensif. Les applications construites sur Opus 5 peuvent partir d’une meilleure résistance que celles utilisant des modèles Claude antérieurs.

L’interprétation la plus faible est qu’une suite de tests a favorisé le modèle plus récent. La réplication externe aidera à distinguer ces possibilités.

Les entreprises devraient demander des preuves détaillées avant d’étendre les autorisations des agents. Des questions utiles portent notamment sur les canaux d’injection testés et sur l’accès éventuel du modèle à des outils sensibles.

Les acheteurs devraient aussi demander quelles protections étaient actives. Un résultat obtenu uniquement par le modèle diffère d’un résultat produit par des classifieurs, des transformations de prompt, l’isolation du navigateur et des contrôles de politique.

Anthropic peut renforcer cette affirmation en publiant des composants d’évaluation reproductibles. Même des artefacts de test partiels aideraient les chercheurs à comparer les modèles dans des conditions cohérentes.

Les concurrents peuvent renforcer le marché dans son ensemble en publiant des résultats comparables. Des pratiques d’évaluation communes faciliteraient l’évaluation de la résistance à l’injection de prompt lors des achats.

D’ici là, les équipes devraient éviter de classer les produits à partir d’une seule déclaration de sécurité. La question pertinente est de savoir comment chaque système complet se comporte face au modèle de menace réel de l’organisation.

Les trois signaux qui mettront à l’épreuve l’affirmation d’Anthropic

L’histoire d’Opus 5 sera tranchée par la réplication indépendante, le comportement en production et la réponse des concurrents.

Le premier signal est un test indépendant face à de nouvelles attaques. Les chercheurs doivent évaluer Opus 5 avec des prompts et des méthodes de livraison qu’Anthropic n’a pas sélectionnés.

Ces tests devraient inclure des sites web, des messages, des dépôts de code source, des documents, des images, des réponses d’outils et une mémoire persistante. Ils devraient distinguer les déviations inoffensives des actions aux conséquences réelles.

Si Opus 5 maintient un faible taux de réussite des attaques dans ces configurations, l’affirmation de Cherny gagnera un poids substantiel. Si les performances s’effondrent en dehors de la suite d’Anthropic, l’affirmation deviendra plus limitée.

Les chercheurs devraient publier une méthodologie suffisante pour permettre la comparaison. Les rapports doivent préciser la configuration de l’agent, les outils disponibles, le modèle d’autorisations, le budget d’attaque, les défenses et les critères de notation.

Le deuxième signal est l’expérience en production. Les utilisateurs de Claude Code et les équipes d’entreprise exposeront Opus 5 à des environnements désordonnés que les évaluations en laboratoire ne peuvent pas entièrement simuler.

Surveillez les rapports portant sur de faux avertissements d’injection, des instructions légitimes ignorées, des dépôts empoisonnés, des appels d’outils inattendus ou une mémoire compromise. Les anecdotes individuelles ne régleront pas la question.

Les schémas observés dans plusieurs déploiements comptent davantage. Le processus de réponse d’Anthropic comptera également, notamment la rapidité avec laquelle l’entreprise enquête sur les échecs et met à jour les mesures d’atténuation.

Un solide bilan en production étayerait l’idée qu’une résistance au niveau du modèle améliore la sécurité quotidienne des agents. Des échecs répétés par des canaux similaires identifieraient des angles morts.

Le troisième signal est la réponse des concurrents. OpenAI, Google et d’autres fournisseurs de modèles peuvent répondre avec leurs propres évaluations de l’injection de prompt et défenses au niveau système.

Des divulgations comparables transformeraient l’affirmation d’un seul fournisseur en catégorie concurrentielle de sécurité. Cette évolution aiderait les acheteurs à exiger une résistance mesurable plutôt que des assurances générales.

Le silence communiquerait aussi quelque chose. Si des fournisseurs rivaux mettent l’accent sur les capacités des agents sans publier de tests sur les contenus hostiles, les équipes de sécurité pourraient considérer cette absence de preuves comme un risque d’approvisionnement.

Ces signaux devraient apparaître avant que les organisations n’accordent aux agents une autorité plus large. La bonne question de déploiement n’est pas de savoir si Opus 5 semble plus sûr que son prédécesseur.

Elle est de savoir si le taux d’échec restant correspond aux conséquences d’un échec. Un assistant qui rédige un résumé crée un risque différent d’un agent qui contrôle une infrastructure.

Les équipes peuvent avancer plus rapidement dans des flux de travail à faible impact tout en maintenant des limites strictes autour des systèmes sensibles. Elles peuvent étendre les autorisations uniquement après avoir observé un comportement stable et une récupération fiable.

La discussion autour d’Anthropic Simon identifie en définitive la bonne norme. L’intelligence du modèle compte, mais un contrôle fiable détermine la quantité de travail que les utilisateurs peuvent déléguer en toute sécurité.

L’enthousiasme de Cherny est compréhensible, car l’injection de prompt a résisté aux solutions simples. Une véritable amélioration à la couche du modèle renforcerait chaque application construite par-dessus.

L’affirmation doit encore subir des tests de résistance externes. Les fiches système fournissent des preuves, pas une immunité, et les red teams ne peuvent anticiper chaque environnement de production.

Au cours des trois prochains mois, surveillez d’abord les résultats d’attaques indépendantes, ensuite les tendances de déploiement, puis les divulgations des rivaux. Ensemble, ces signaux montreront si Opus 5 transforme la sécurité des agents ou seulement son récit de benchmark.

Pour les développeurs, l’action immédiate est simple : testez Opus 5 avec du contenu issu de vos propres flux de travail. Incluez les dépôts, les messages, les documents, la mémoire et chaque outil activé.

Pour les acheteurs, demandez aux fournisseurs d’expliquer à la fois la résistance du modèle et les contrôles applicatifs. Exigez des limites d’autorisation claires, des journaux d’audit, des étapes de confirmation et des procédures d’incident.

Pour les utilisateurs quotidiens de l’IA, gardez les actions sensibles vérifiables. Une meilleure résistance mérite de l’attention, mais une confiance réelle découle de contrôles visibles et de preuves recueillies en dehors du cycle de lancement.