Les modèles de défense cybernétique Daybreak d’OpenAI arrivent sur Amazon Bedrock

Les deux modèles de défense cybernétique d’OpenAI sont désormais disponibles pour les clients éligibles sur Amazon Bedrock, a annoncé AWS le 11 août 2026, un jour après que OpenAI ait étendu son initiative Daybreak avec de nouveaux niveaux d’accès et un modèle de sécurité formé à des fins spécifiques. Daybreak Red et Daybreak Blue s’exécutent dans la région US East (N. Virginia), et l’accès nécessite une inscription au programme de vérification de confiance pour la cybersécurité d’OpenAI.

Daybreak Red fournit l’accès à GPT-5.6 Cyber, un modèle que OpenAI a formé spécifiquement pour les tâches de cybersécurité telles que la recherche de vulnérabilités zero-day et le développement de chaînes d’exploitation. Daybreak Blue fournit GPT-5.6 Sol avec des garanties réajustées pour le travail de sécurité défensive : découverte de vulnérabilités, ingénierie de détection, réponse aux incidents et validation de correctifs. OpenAI recommande Blue comme point de départ pour la plupart des équipes de sécurité ; Red a un seuil de refus plus bas assorti d’une vérification d’identité, d’un suivi et de contrôles d’accès plus solides, et est destiné à la recherche de vulnérabilités autorisée, à la reproduction d’exploits et au développement d’atténuation.

“Les équipes de sécurité d’AWS utilisent actuellement les deux modèles pour analyser le code source, découvrir les vulnérabilités et mener des recherches de type red team”, a déclaré John Sheehan, vice-président de la sécurité d’AWS, dans l’annonce. “Sur Bedrock, ce travail s’exécute sous les mêmes contrôles d’infrastructure que ceux que AWS applique à toutes les autres charges de travail critiques.”

Deux niveaux, deux postures de refus

La division entre Red et Blue est un pari sur la façon de gouverner la capacité à usage dual. Une demande de reproduction d’une vulnérabilité ou de rétro-ingénierie d’une chaîne d’exploitation se lit de la même manière que si elle provenait d’un défenseur ou d’un attaquant, et les modèles polyvalents résolvent cette ambiguïté en refusant. Le billet d’expansion de Daybreak d’OpenAI fournit des chiffres sur la façon dont ce comportement de refus change au fil des niveaux, en utilisant une évaluation interne qui mesure à quelle fréquence les modèles complètent les demandes impliquant le développement de chaînes d’exploitation, le contournement d’authentification et l’élévation de privilèges. GPT-5.6 Cyber via Daybreak Red complète 95,0 % de ces demandes, rapporte l’entreprise, contre 2,0 % pour GPT-5.6 Sol sous l’accès Daybreak Blue et 1,5 % pour Sol avec ses garanties standard. Le modèle formé à des fins spécifiques précédent, GPT-5.5-Cyber, a complété 57,3 %.

Blue atteint sa posture en supprimant les garde-fous au niveau du système qui filtrent les demandes liées à la cybersécurité, que OpenAI déclare pouvoir bloquer un travail de défense légitime. Red va plus loin : GPT-5.6 Cyber est formé pour réduire les refus sur les tâches à plus haut risque, au sein d’un programme fermé plutôt que sur l’API ouverte. Ces chiffres de complétion sont les mesures propres d’OpenAI sur son évaluation, et non des résultats indépendants.

Ce que le modèle a trouvé jusqu’à présent

OpenAI déclare que ses chercheurs ont utilisé GPT-5.6 Cyber pour enquêter sur V8, le moteur JavaScript à l’intérieur de Chrome, et ont découvert deux vulnérabilités inconnues qui pourraient être enchaînées pour corrompre la mémoire et échapper au bac à sable V8. Google a corrigé la vulnérabilité initiale en tant que CVE-2026-15903, une faille de gravité élevée dans le compilateur d’optimisation V8 qui omettait une vérification de sécurité lors de la conversion de valeurs en entiers ; AWS la décrit comme l’une des quatre entrées réussies de zero-day au concours V8 CTF en 2026.

Le même billet énumère les découvertes supplémentaires que OpenAI attribue au modèle, toutes en cours de divulgation coordonnée : au moins cinq vulnérabilités dans un système d’exploitation mobile populaire, dont une chaîne allant d’une application non fiable à une élévation de privilèges locales ; trois vulnérabilités critiques dans une base de données populaire, dont un chemin distant vers l’exécution de code ; et plus de 400 vulnérabilités d’élévation de privilèges dans un noyau de système d’exploitation populaire. Aucune de ces cibles n’est nommée, et aucune n’est corrigée pour le moment, donc les allégations restent avec OpenAI jusqu’à ce que les divulgations soient effectuées.

Comment les données sont traitées sur Bedrock

Une charge de travail de défense de ce type alimente un modèle avec exactement ce que une organisation ne veut pas laisser fuiter : code source propriétaire, détails de vulnérabilités non corrigées, télémétrie de production en direct. La réponse d’AWS est l’histoire d’isolement. Les deux modèles s’exécutent sur le moteur d’inférence de nouvelle génération de Bedrock avec un accès à zéro opérateur appliqué au niveau du circuit, ce qui signifie qu’aucun opérateur AWS ne peut lire les invites ou les complétions pendant l’inférence. Le trafic est chiffré avec des clés KMS gérées par le client, régies par des politiques IAM, consignées dans CloudTrail et acheminées via des points de terminaison VPC, avec des politiques de périmètre de données au niveau de l’organisation pour bloquer l’exfiltration entre les limites de compte.

Les données d’inférence ne sont pas utilisées pour la formation de modèles, et aucun des deux modèles n’exige de s’inscrire au partage de données avec OpenAI. Pour la détection automatique d’abus, le trafic signalé par le classificateur est conservé par AWS pendant une période allant jusqu’à 30 jours et traité de manière programmatique ; les clients peuvent demander une rétention de données nulle via leur équipe de compte AWS, conformément à la documentation d’AWS.

La porte de contrôle

Pour accéder à l’un ou l’autre modèle, il faut passer par Trusted Access for Cyber, le cadre d’identité et de confiance introduit par OpenAI le 5 février 2026 aux côtés d’un engagement de 10 millions de crédits d’API pour un travail de défense. L’accès est contrôlé via la vérification d’identité, la sécurité du compte, la surveillance, les restrictions d’utilisation approuvées et les attestations légales ; à compter du 1er septembre 2026, tous les comptes Daybreak individuels doivent adopter des clés de sécurité matérielles. Une fois approuvés par OpenAI, les clients travaillent avec leur équipe de compte AWS pour demander l’accès au modèle sur Bedrock.

L’arrivée sur Bedrock prolonge une ligne de distribution ouverte le 24 juillet 2026, lorsque la famille GPT-5.6 générale est devenue disponible sur la plate-forme, accessible via l’API de réponses OpenAI sur le point de terminaison bedrock-mantle. Cela atterrit également alors qu’OpenAI gère la politique de sécurité des modèles à refus réduit : le billet Daybreak indique explicitement que GPT-5.6 Cyber n’a pas été impliqué dans l’exploitation de Hugging Face, ajoutant qu’aucun modèle impliqué dans cette exploitation n’est prévu pour une version à venir, et déclare que le modèle a été évalué comme élevé mais en dessous du seuil critique dans son cadre de préparation. Nous avons couvert la structure de niveau et le nouveau modèle lorsque OpenAI a étendu Daybreak le 10 août 2026.

Pour les défenseurs, le changement pratique est là où cette capacité se situe maintenant. Une équipe de sécurité vérifiée qui exécute déjà des charges de travail sur AWS peut pointer GPT-5.6 Cyber sur ses propres bases de code à l’intérieur du même périmètre de gouvernance que le reste de son infrastructure, plutôt que de router le travail de vulnérabilité sensible via une relation de fournisseur distincte. Les modèles sont en direct dans une région, derrière un formulaire d’inscription, à compter du 11 août 2026.