Anthropic verrouille son modèle le plus dangereux derrière des artefacts, pas des prompts

Le problème de contrôle d'accès que personne ne nomme correctement

La plupart des équipes qui shippent un agent doté d'une capacité vraiment dangereuse — une capacité qui ferait de vrais dégâts si un prompt l'orientait mal — le règlent avec une ligne dans le system prompt. « Ne fais pas X sauf si Y. » Ce n'est pas du contrôle d'accès. C'est une suggestion, et une suggestion, ça se négocie.

L'alternative a une forme qui mérite un nom : l'accès par artefact. Le modèle n'a aucune surface conversationnelle. Il a une signature de fonction — une entrée définie, une sortie définie — et l'utilisateur ne reçoit que l'artefact produit par cette fonction. Jamais le modèle.

L'annonce d'Anthropic cette semaine est l'exemple public le plus propre qu'on ait vu de ce pattern livré comme produit — et il vient de l'équipe qui détient la capacité dual-use la plus lourde de toutes : un modèle assez bon en cybersécurité offensive pour qu'y accéder directement soit le risque en soi. Le design se généralise bien au-delà de la sécurité.

Ce qui a été livré

Claude Mythos 5 — le modèle frontière qu'Anthropic réservait jusqu'ici, sous le nom de Claude Mythos Preview, à un petit groupe de défenseurs d'infrastructures critiques via Project Glasswing — devient accessible à plus de monde. Pas en ouvrant l'accès direct. Trois changements concrets :

Claude Security tourne désormais sur Mythos 5. Claude Security est le produit de scan de code d'Anthropic, en bêta publique pour les clients Claude Enterprise. On pointe un repo, il scanne les vulnérabilités et renvoie chaque finding avec une catégorie Common Weakness Enumeration, un niveau de confiance, un niveau de sévérité et un patch suggéré. Les scans avec Mythos 5 sont facturés en usage token standard — pas d'add-on séparé. Chaque patch doit être relu et approuvé par un humain avant d'être appliqué, et l'étape de correction tourne sur les modèles auxquels l'organisation a déjà accès : le scan n'étend l'accès Mythos à aucune autre surface.

Les outils de sécurité partenaires sont la prochaine étape — et leurs utilisateurs n'auront pas de champ de prompt. Anthropic dit Mythos 5 « coming soon » dans les outils de cyberdéfense de ses partenaires et travaille avec eux à l'intégration : à traiter comme annoncé, pas comme livré. L'illustration donnée est la partie intéressante : un produit de remédiation renvoie une liste de patchs suggérés générés par Mythos, sans que l'utilisateur ait « un moyen de demander au modèle de, disons, développer un exploit pour une vulnérabilité ». La frontière d'artefact écrite comme une exigence produit, pas comme un comportement espéré.

Un fonds Defender Advantage de 35M$ (0xDAF) — en crédits Claude, pas en cash — va aux organisations qui patchent des vulnérabilités dans des projets open-source, automatisent des workflows de scan-et-patch, ou expérimentent de nouvelles approches de sécurité. Il fait suite à 4M$ de dons directs déjà versés sous Project Glasswing. Anthropic annonce démarrer par un petit nombre de subventions pilotes plus importantes et nommer les premiers bénéficiaires « dans les prochaines semaines ».

Un élément de contexte fourni par l'annonce et facile à survoler : Anthropic présente Claude Fable 5 comme la première marche de cette stratégie — disponibilité large, travail cyber dual-use bloqué net. Mythos 5 est la deuxième marche, et c'est l'arbitrage inverse : garder la capacité, retirer la conversation. Deux réponses différentes à la même question, choisies selon le niveau de capacité en jeu.

Le principe, énoncé sans détour

Anthropic le pose en une phrase qui porte tout : « Le comportement le plus risqué survient quand un utilisateur a un accès direct à un modèle, où un acteur malveillant peut tenter de l'orienter vers des usages nuisibles. Mais si les utilisateurs ne peuvent recevoir que des sorties spécifiques, comme un patch pour une vulnérabilité ou une alerte de sécurité, ce risque est bien plus faible. »

C'est tout le pattern. Et c'est le même mouvement architectural qu'on a décrit pour un mode de défaillance totalement différent — le tool calling forcé pour empêcher un chatbot d'improviser sa prose face à l'utilisateur. Problème différent, correctif identique : n'essayez pas de contraindre par des instructions ce que le modèle accepte de dire. Contraignez ce que le système autour de lui est capable de renvoyer.

Appliqué à une capacité dual-use comme l'analyse de vulnérabilités de niveau offensif, ça donne : le modèle ne parle jamais à l'utilisateur final. Il parle à un wrapper limité à une tâche, qui l'appelle pour un seul job, jette tout sauf l'artefact que ce job produit, et transmet cet artefact — un patch, un finding tagué CWE, un score de sévérité — à un humain. Il n'y a pas de tour de conversation où un prompt habile ferait dévier le modèle, parce qu'il n'y a pas de tour de conversation du tout.

Pourquoi c'est plus strict qu'une couche de sécurité

Le réflexe habituel consiste à mettre quelque chose devant le modèle : un classifieur, une passe de modération, un system prompt entraîné au refus. Les trois sont des filtres sur un canal qui reste ouvert. L'accès par artefact supprime le canal.

La différence compte sous pression adverse. Un classifieur se fait avoir par un prompt que personne n'a encore vu, et on l'apprend après coup. Une fonction qui n'accepte qu'une URL de repo et ne renvoie qu'une liste de findings n'a rien à tromper — la propriété de sécurité vient de la forme de l'interface, pas du jugement du modèle sur le moment.

Ça la rend aussi auditable comme un filtre ne le sera jamais. On peut lire une signature de fonction et savoir ce qui peut en sortir. On ne peut pas lire l'ensemble des prompts qui cassent un classifieur.

Où ça se généralise au-delà de la sécurité

Pas besoin d'un modèle capable d'écrire des exploits pour avoir ce problème. Tout agent branché sur une action à conséquences — déplacer de l'argent, modifier une infrastructure, formuler un engagement à valeur légale, changer une config de production — présente exactement la même forme de risque. C'est acceptable tant que l'action est cadrée et relisable. Ça devient un risque dès qu'un utilisateur, un prompt injecté ou un outil amont compromis peut orienter le modèle vers un territoire ouvert.

D'où l'inversion de l'ordre de conception : décidez quel artefact l'agent a le droit de produire avant de décider ce qu'il a le droit de voir.

• Un agent de remédiation renvoie un patch, pas un shell.
• Un agent finance renvoie une transaction proposée pour validation, pas un accès au wallet.
• Un agent infra renvoie un diff, pas des credentials kubectl.
• Un agent support renvoie une macro sélectionnée ou une mise à jour de ticket structurée, pas de la prose libre dans votre voix de marque.

Le test à passer sur votre propre design est binaire : un utilisateur — ou un prompt injecté quelque part en amont — peut-il demander à l'agent de faire directement l'action dangereuse ? Si la réponse est oui, vous avez un system prompt qui fait le travail qu'une frontière d'interface devrait faire.

Ce que le pattern coûte

On le vendrait mal en s'arrêtant là. L'accès par artefact a trois coûts bien réels, et c'est le troisième qu'on oublie.

Il faut connaître le schéma de l'artefact à l'avance. Le chat ouvert séduit précisément parce qu'on n'a pas à le faire. Resserrer la sortie, c'est perdre les cas qu'on n'avait pas anticipés ; l'élargir plus tard, c'est un redéploiement, parfois une refonte. Bon arbitrage pour une capacité dangereuse, mauvais pour du travail exploratoire.

La débogabilité s'effondre. Quand l'artefact est faux, personne côté utilisateur ne peut demander pourquoi. Si vous ne loguez pas le raisonnement intermédiaire de votre côté de la frontière, vous déboguez à l'aveugle — le même mur que face à tout système qui ne rend que sa conclusion.

Ça contraint la surface de sortie, pas la confiance dans l'entrée. Pas de champ de prompt ne veut pas dire pas d'input non fiable. Le repo scanné est une entrée, et son contenu peut plausiblement influencer ce qui revient. L'accès par artefact réduit le rayon d'explosion d'une compromission ; il n'empêche pas un modèle d'être orienté par les données qu'il lit. Traitez l'artefact comme une sortie non fiable dans tous les cas — c'est exactement pourquoi la relecture humaine obligatoire avant merge d'un patch fait partie du design d'Anthropic, et devrait faire partie du vôtre.

Ce dernier point est là où on pousserait contre quiconque lit l'actu de la semaine comme un « problème réglé ». La frontière d'interface est le meilleur mouvement isolé disponible. Ce n'est pas le seul dont vous avez besoin.

Ce qu'on surveille

Deux suites à cette annonce. D'abord l'extension du Cyber Verification Program : Anthropic annonce des capacités dual-use élargies pour les défenseurs vérifiés sur Opus et Sonnet « dans les prochaines semaines », avec un accès Mythos « à suivre » — et les calendriers annoncés sont précisément l'endroit où les programmes d'accès contrôlé glissent. Ensuite les premiers bénéficiaires du 0xDAF. Qu'Anthropic nomme des bénéficiaires sur un fonds de 35M$, c'est la différence entre un communiqué de presse et un programme réel ; on y reviendra une fois que ce sera fait.

Si vous construisez un agent avec une capacité trop dangereuse pour la mettre derrière un champ de prompt, la question de l'interface est la première à trancher — discutons.