Anthropic a annoncé le 21 août 2026, dans le cadre du Defender Advantage Fund doté de 35 millions de dollars en crédits Claude, un outil de scan de vulnérabilités propulsé par Claude Mythos 5, réservé pour l'instant aux clients Claude Enterprise en bêta publique. Le produit s'appelle Claude Security. Il scanne du code sans jamais donner accès direct au modèle. Si tu as déjà des agents Claude en production ou que tu t'apprêtes à construire des agents Claude autonomes, cet article te donne le vocabulaire pour trier ce que tu dois faire de cette annonce, et ce que tu peux ignorer.
Une clarification avant d'entrer dans le fond : les sources publiques concordent sur le fait que Claude Security scanne du code applicatif à la recherche de vulnérabilités (avec catégorie CWE, sévérité, confiance, correctif suggéré). Le brief interne évoque aussi une lecture élargie de l'outil comme scanner de configurations d'agents (prompts système, outils MCP, permissions). Cet article tient les deux fils, et distingue à chaque fois ce qui est documenté officiellement de ce qui reste une extrapolation raisonnable pour un déploiement Claude en entreprise. Si tu veux apprendre Claude de bout en bout avant d'attaquer la partie sécurité, c'est le point d'entrée.
Ce que Mythos 5 fait réellement
Claude Mythos 5, dans le contexte de Claude Security, est le moteur qui lit le code d'une organisation et remonte des findings. Chaque résultat porte quatre attributs : une catégorie CWE, un niveau de sévérité, un niveau de confiance, et un correctif suggéré à relire humainement avant d'appliquer quoi que ce soit. Le point produit important : l'utilisateur ne parle jamais à Mythos 5. Il voit les findings et les patchs proposés, pas le modèle. Anthropic protège l'accès direct au modèle cyber-capable, qui reste réservé aux défenseurs vérifiés du Cyber Verification Program lancé en avril 2026.
La facturation reprend le compteur de tokens du plan Enterprise existant, sans add-on. Pas de ligne séparée dans la facture, mais un scan consomme des tokens comme n'importe quelle tâche.
Le vocabulaire à poser tout de suite : posture scanning versus runtime testing. Le premier lit des artefacts au repos (code, config, prompts versionnés) et cherche des motifs connus. Le second envoie du trafic à un système vivant et observe ce qu'il fait. Claude Security fait du posture scanning avec un modèle IA au moteur, et non un moteur de règles statiques comme un SAST classique. C'est la même intention qu'un SAST, avec une capacité de raisonnement plus riche sur le code lu.
Pourquoi scanner sans accès direct au modèle
La décision produit d'Anthropic n'est pas anodine. Interroger un modèle en production pour tester ses limites coûte cher, laisse des traces dans les logs, et ne teste qu'un état ponctuel du système. Un scan de code, lui, est reproductible : même input, même findings à modèle constant. Il s'intègre en CI, on peut le rejouer sur une pull request, on peut versionner les résultats.
L'autre raison est plus politique. Mythos 5 a des capacités cyber-offensives suffisantes pour qu'Anthropic ait construit tout un programme de vérification autour de lui. Donner un accès brut à ce modèle à chaque client Enterprise multiplierait les vecteurs d'abus. Passer par un produit qui n'expose que les findings résout le problème d'accès : la puissance du modèle sert la défense, sans que le modèle soit lui-même une arme dans les mains du client.
Pour un dirigeant, ça a une conséquence directe. La sécurité des agents devient auditable comme du code, pas seulement observable comme un comportement runtime. Tu peux exiger un scan avant chaque merge, un ticket ouvert par finding critique, une traçabilité de la remédiation attachée à chaque correctif appliqué. Ce genre de discipline est difficile à imposer sur du red-teaming manuel, qui reste ponctuel par nature.
Ce qui est officiellement documenté, et ce qui ne l'est pas
Officiellement, Claude Security remonte des findings au format CWE (Common Weakness Enumeration), une nomenclature qui couvre des centaines de catégories de vulnérabilités de code, du SQL injection au buffer overflow. Aucune source officielle recoupée à ce stade ne documente si Claude Security scanne spécifiquement les configurations d'agents (prompts système, serveurs MCP, permissions) au-delà du code applicatif classique. Ne présente jamais cette extension comme une capacité confirmée du produit.
Ce que cet article te propose à la place, c'est une grille de lecture Ottho, indépendante du produit, pour préparer ta base de code d'agents à être auditable, que ce soit par Claude Security demain ou par n'importe quel autre outil de scan aujourd'hui. Quatre zones de risque reviennent régulièrement dans les déploiements d'agents IA :
| Zone de risque | Ce que ça veut dire | Comment la préparer pour un audit |
|---|---|---|
| Prompt injection | Un input utilisateur ou une donnée récupérée contient des instructions qui détournent l'agent | Séparer explicitement input et instruction dans le code, ne jamais concaténer du contenu externe directement dans le prompt |
| Permissions d'outil trop larges | Un outil MCP est configuré avec des permissions plus larges que son usage réel | Scopes explicites dans la config MCP, whitelist sur les chemins de fichiers ou domaines réseau |
| Fuite de prompt système | Le prompt système contient des secrets ou fuit dans les réponses | Aucune clé API ou identifiant en clair dans le prompt, filtre sur les réponses pour éviter la fuite du system prompt |
| Sur-permission d'agent | Un agent a accès à plus d'outils ou de données qu'il ne lui en faut | Configuration explicite et restreinte des outils MCP disponibles, plutôt qu'un accès par défaut à tout le catalogue |
Cette grille est une proposition de méthode Ottho, pas une description du fonctionnement interne de Claude Security. Sur ces quatre zones, seule la première relève clairement du code applicatif classique que la CWE couvre historiquement. Les trois autres relèvent de la façon dont tu configures les outils MCP de tes agents et dont tu structures leurs prompts : ta capacité à en tirer valeur d'un scanner, quel qu'il soit, dépend directement de la propreté de ta base (prompts versionnés dans un repo git, configs MCP cataloguées, permissions déclaratives).
Ce que ça change pour un déploiement Claude en entreprise
Si tes agents tournent aujourd'hui en production avec des prompts système collés dans une constante Python et des serveurs MCP configurés à la main sur chaque poste, un scanner ne servira à rien. Il faut d'abord une base scannable.
Le vrai livrable d'une démarche Claude Security, c'est la gouvernance qui l'entoure. Les questions à poser à ton équipe technique cette semaine :
- Qui possède la version canonique du prompt système de chaque agent en production ? Où est-elle stockée ? Quel processus pour la modifier ?
- Quel est le catalogue des outils MCP que nos agents peuvent invoquer ? Qui l'a écrit ? Qui review les ajouts ?
- Chaque agent a-t-il un scope de permissions minimal explicite, ou hérite-t-il par défaut de tout ce qui est disponible sur son environnement ?
- Quand un développeur modifie un prompt ou ajoute un outil, cette modification passe-t-elle par une pull request, ou est-elle poussée directement en prod ?
Ces questions n'exigent pas Claude Security pour être posées. Mais l'existence d'un scanner qui audite ce périmètre te donne une raison concrète, budgétisable, de mettre la gouvernance en place. C'est plus facile de faire adopter un process de review sur les prompts quand tu peux dire à ton équipe que le scan de sécurité en dépend.
Sur le plan technique, prévois deux points d'ancrage. Le premier : versionner les prompts et configs dans un repo dédié, avec des reviewers désignés. Le second : instrumenter tes appels avec l'API Anthropic pour tracer quel agent a fait quoi, quand, avec quel outil. Sans ces deux briques, aucun scanner ne pourra corréler un finding à un responsable.
Les limites à connaître avant d'y mettre du budget
Claude Security n'est pas un couteau suisse. Ce que l'outil ne fait pas, au vu des informations publiques disponibles :
- Il ne teste pas les comportements émergents du modèle en production. Un agent qui hallucine, qui se coordonne mal avec un autre agent, ou qui prend une décision inattendue sur un edge case ne sera pas détecté par un scan de code.
- Il ne remplace pas le red-teaming. Les campagnes de red-teaming d'Anthropic sur l'injection de prompt sont menées activement sur ses modèles, pas via un scanner statique : les deux approches sont complémentaires, pas interchangeables.
- Il ne couvre pas les vulnérabilités côté données. Si ton système RAG indexe des documents dont certains contiennent des instructions malveillantes, le scanner ne le verra pas : il ne lit pas ta base vectorielle.
- Il ne remplace pas les autres briques de sécurité Anthropic. Les inference hooks pour DLP disponibles côté Enterprise interceptent les prompts avant qu'ils n'atteignent le modèle. C'est du runtime, pas du scan. Les deux couvrent des angles différents.
À rapprocher aussi des travaux du Frontier Red Team sur les conflits multi-agents publiés en août 2026 : quand tu fais tourner plusieurs agents en parallèle sur une même base de code, des comportements émergents apparaissent qu'aucun scan statique ne prédira. Claude Security te dit si ton code est propre. Il ne te dit pas si tes agents coopèrent bien.
Par où commencer si vous déployez déjà Claude
Un plan d'action séquentiel, à dérouler avant même d'activer Claude Security si tu es sur Enterprise :
- Cartographie tes agents. Liste chaque agent en production ou en staging, son rôle, son prompt système, les outils MCP qu'il peut invoquer, les données auxquelles il accède. Cet inventaire est le prérequis de tout audit.
- Isole les prompts système dans un repo versionné. Un dossier
prompts/dans ton monorepo, un fichier par agent, revu comme du code. Fin des prompts collés dans du code applicatif. - Catalogue tes serveurs MCP. Un fichier de config déclaratif qui liste chaque serveur MCP autorisé, avec son scope explicite. Si un développeur veut en ajouter un, ça passe par une pull request.
- Définis un scope de permissions minimal par agent. Le principe du moindre privilège appliqué aux agents. Un agent commercial n'a pas besoin d'accès en écriture au filesystem.
- Ajoute un scan de sécurité en CI. Que ce soit Claude Security une fois disponible dans ton contexte, un SAST classique, ou une combinaison des deux. Le scan doit tourner sur chaque pull request qui touche aux prompts, aux configs MCP ou au code des agents.
Les étapes 1 à 4 ne dépendent pas d'Anthropic. Tu peux les lancer dès demain, quel que soit ton plan Claude. L'étape 5 dépend de ton accès à Claude Security si tu es Enterprise, ou d'un choix d'outillage tiers si tu ne l'es pas.
Si tu veux passer de la théorie à une mise en pratique encadrée sur ce genre de sujet (prompts versionnés, outils MCP scopés, agents auditables), c'est exactement ce qu'on couvre dans la formation dédiée pour piloter vos agents autonomes en production. Cinq semaines, dix sessions live, et cinq agents opérationnels à la sortie.