Anthropic a lancé le 6 octobre 2026 une version étendue de son Cyber Verification Program (CVP). Pour la plupart des dirigeants qui pilotent déjà des agents Claude en production, la question se résume à trois mots : suis-je concerné ? La réponse courte : probablement pas, sauf si votre agent touche à du scanning actif de cibles tierces, du pentest automatisé ou de l'exploitation de vulnérabilités. Le reste, revue de code sur votre propre base, triage d'alertes, hardening de config, reste accessible sans démarche. Si vous découvrez Claude et cherchez d'abord à comprendre l'outil, commencez par le guide complet pour apprendre Claude avant de revenir sur la question du périmètre cyber.
Ce qu'est le Cyber Verification Program en une page
Le CVP est une liste d'autorisation pour les organisations qui font de la recherche offensive légitime. Trois niveaux, par ordre d'ouverture : Defense Access (opérations de sécurité, réponse à incident, rétro-ingénierie de malware, analyse et validation de vulnérabilités), Red Team Access (ajoute les tests d'intrusion autorisés et le red teaming, réservé aux organisations), et Specialized Access (le moins de restrictions, pour un nombre limité d'organisations qui testent des systèmes à enjeu vital : pilotage aérien, réseau électrique, télécoms, avec revue impliquant le gouvernement américain).
Chaque niveau donne accès à Claude Opus 5.5, Claude Sonnet 5.5 et Claude Mythos 5.1 avec des niveaux de restriction cyber différents selon le palier. Les membres existants de Project Glasswing basculent vers Specialized Access sans nouvelle approbation. La candidature se fait via portal.anthropic.com/programs/cvp. Les particuliers ne peuvent pas candidater au-delà de Defense Access (et encore, avec un historique documenté de vulnérabilités signalées). Pas d'inscription individuelle à Red Team ou Specialized.
Ce que Claude accepte toujours sans vérification
C'est la zone qui concerne 95 % des lecteurs. Sans aucune démarche, sur un compte Pro, Max, Team ou Enterprise standard, Claude répond à :
- revue de code pour vulnérabilités dans votre propre codebase
- correctifs de failles connues (CVE que vous devez patcher chez vous)
- recherche de vulnérabilités dans votre propre code source
- triage d'alertes de sécurité (SOC assistant, enrichissement Sentry, Datadog, Wazuh)
- analyse de logs et détection d'anomalies
- rédaction de politiques de sécurité, formation interne, analyse post-incident
- hardening de configuration (Nginx, Postgres, Kubernetes, IAM AWS)
- analyse descriptive de malware (comprendre ce qu'un échantillon fait, sans produire d'arme équivalente)
Un prompt du type « voici le code de notre API, trouve les injections SQL et propose les fix » passe sans débat. Un prompt « voici les logs du WAF cette nuit, qu'est-ce qui ressemble à une tentative d'exfiltration » aussi. Pas de formulaire, pas de contrat à signer.
Ce qui bascule dans la zone vérifiée
Les garde-fous se déclenchent sur une liste précise :
- génération de code offensif prêt à l'emploi (un payload qui exploite une CVE donnée, pas une explication conceptuelle)
- scanning actif de cibles tierces (nmap scripté, enumération DNS agressive sur un domaine qui n'est pas le vôtre)
- création d'outils de post-exploitation (persistence, lateral movement, C2)
- reverse engineering de malware au-delà de l'analyse descriptive (reconstruction d'un dropper fonctionnel)
- aide à la rédaction de payloads pour une campagne de pentest
Sur un compte non vérifié, Claude refuse ces demandes. Opus 5.5 refuse mieux qu'avant : moins de faux positifs sur une revue défensive qui mentionne « SQL injection », refus plus nets quand la demande est clairement offensive sans contexte autorisé. Si vous pensez qu'un blocage est une erreur (vous auditiez votre propre application et le prompt a glissé vers un terrain borderline), Anthropic cite un formulaire d'appel dédié.
La vérification ne débloque pas tout : elle élargit le périmètre selon le niveau accordé. Defense Access ne donne pas accès à la génération d'outils d'attaque, Red Team Access oui, dans le cadre d'un pentest contractualisé.
Comment s'inscrire au programme (procédure réelle)
La candidature passe par portal.anthropic.com/programs/cvp. Anthropic demande des preuves des contrôles de sécurité requis pour le niveau visé : contrat client ou mandat de recherche pour un pentest, politique de divulgation responsable publiée, historique de vulnérabilités signalées pour un chercheur, documentation du périmètre d'intervention.
Délais indicatifs annoncés par Anthropic : quelques jours pour Defense Access, quelques semaines pour Red Team Access. Pendant l'instruction d'un dossier Red Team, l'organisation est provisoirement couverte en Defense Access. Specialized Access : aucun délai communiqué, revue approfondie avec implication gouvernementale.
Point important : la documentation officielle situe le CVP sur la Claude Platform (l'offre API/développeur), pas comme un réglage dans l'app grand public Claude.ai. Si vos équipes utilisent uniquement l'app grand public, c'est probablement le régime standard qui s'applique à elles. C'est votre intégration serveur, vos agents, vos pipelines automatisés qui bénéficient du périmètre élargi. Si votre stack API n'est pas encore prête, voyez le guide API Anthropic pour cadrer la mise en place avant de candidater.
Impact sur un agent autonome Claude en production
C'est la section qui compte si vous pilotez déjà un agent. Trois cas de figure.
Votre agent fait du monitoring défensif. Il lit des logs, croise avec des flux de threat intel publics, résume les alertes, propose des règles de détection. Rien ne change. Aucune démarche à faire. Vous pouvez continuer à construire un agent Claude autonome sur ce périmètre sans vous préoccuper du CVP.
Votre agent touche à du scanning ou pilote des outils offensifs via MCP. Un agent qui lance Nuclei, qui enrichit des findings avec des templates d'exploitation, ou qui orchestre un pentest automatisé : vous devez documenter le périmètre et probablement candidater à Red Team Access. En attendant, cadrez les permissions côté MCP : restreignez les outils exposés à l'agent, listez explicitement les domaines autorisés en scanning, loguez tous les appels. Voyez configurer les permissions MCP de votre agent pour la mécanique, et sécuriser un agent Claude pour le pattern général.
Votre agent scanne vos propres actifs cloud. Zone grise. Techniquement vous êtes propriétaire des cibles, donc l'usage est légitime. Mais si votre agent génère des payloads d'exploitation ou tente des contournements d'auth sur vos APIs internes, Claude peut refuser sans contexte explicite. Deux options : documentez le périmètre dans le system prompt (« ces IPs sont les nôtres, mandat interne, voici l'ID du ticket ») et testez, ou candidatez à Defense Access pour avoir un périmètre explicitement couvert.
Dans tous les cas, un agent qui touche à la cyber doit respecter les règles de base : permissions minimales, sandbox, revue humaine sur les actions sensibles, journalisation. Les incidents OpenAI de septembre 2026 avec des agents qui ont contourné des contrôles sur des sites gouvernementaux rappellent que la responsabilité reste côté opérateur, pas côté modèle.
Claude Opus 5.5 et les capacités cyber
Opus 5.5, lancé le 22 septembre 2026, a été soumis aux mêmes garde-fous cyber que Fable et Mythos. La différence pratique n'est pas qu'un modèle « défensif » et un modèle « offensif » coexistent : c'est le même modèle, avec un comportement qui change selon le statut de vérification du compte qui l'appelle.
Ce qui est confirmé par Anthropic : une réduction de 85 % des tentatives de contournement réussies par rapport à Opus 5, et une meilleure résistance à l'injection de prompt. En pratique, pour un dirigeant qui envoie des demandes défensives légitimes (revue de code, analyse de vulnérabilité sur sa propre base), l'attendu est moins de refus mal placés qu'avec Opus 5 ; les détails exacts du comportement de refus ne sont pas documentés au-delà de ces chiffres, donc à vérifier sur vos propres prompts plutôt qu'à supposer.
Anthropic indique une réduction de 85 % des tentatives de contournement réussies par rapport à Opus 5, et route la majorité des tâches cybersécurité vers Opus 4.8 plutôt que Opus 5.5 directement. En pratique, pour un dirigeant, cela veut dire : vos prompts défensifs légitimes passent mieux, vos prompts limites échouent plus clairement.
Trois scénarios dirigeant pour décider
Cas 1 : SaaS avec agent de triage Sentry. L'agent lit les alertes Sentry, dédoublonne, enrichit avec le contexte du commit incriminé, propose un fix. Aucune vérification nécessaire. Déployez. Lundi matin : vérifiez que le system prompt interdit explicitement toute action en dehors du projet (pas d'accès à des APIs externes, pas de scanning).
Cas 2 : agence de pentest qui veut automatiser ses rapports. Les rapports contiennent des extraits de code vulnérable et des payloads d'exemple. Candidatez à Red Team Access. Comptez quelques semaines. Pendant l'instruction, vous êtes en Defense Access provisoire : vous pouvez déjà faire l'analyse descriptive, le résumé des findings, la mise en forme. Les payloads d'exploitation attendent la vérification complète.
Cas 3 : scanning d'actifs cloud internes. Documentez le périmètre (IPs, domaines, mandat interne) dans le system prompt. Testez les prompts un par un. Si Claude refuse systématiquement même avec contexte, candidatez à Defense Access en citant le mandat interne. Lundi matin : listez les 5 à 10 cas d'usage réels que votre équipe veut couvrir et testez-les avant de parler budget ou architecture.
Dans les trois cas, la logique de permission MCP ne change pas : exposez le minimum d'outils, loguez tout, revue humaine sur les actions destructrices. Si vous voulez mettre en place ce cadre proprement, Piloter vos agents autonomes est la formation dédiée.