GPT-5.3-Codex et les modèles plus récents, notamment GPT-5.4 et GPT-5.5, sont classés comme ayant des capacités élevées en cybersécurité selon notre cadre de préparation. Des mesures de protection automatisées supplémentaires s’appliquent donc lorsque ces modèles sont utilisés via l’API. Les mesures de protection appliquées dans l’API diffèrent de celles utilisées dans Codex. Pour en savoir plus sur les mesures de protection de Codex, consultez cette page.
Ces mesures de protection surveillent les signes d’activité potentiellement suspecte en matière de cybersécurité. Si certains seuils sont atteints, l’accès au modèle peut être temporairement limité pendant l’examen de l’activité. Ces systèmes étant encore en cours de calibrage, des travaux légitimes de recherche en sécurité ou de défense peuvent parfois être signalés. Nous prévoyons que seule une faible part du trafic sera touchée et nous continuons d’améliorer l’expérience globale de l’API.
Accès autorisés et workflows agentiques
Trusted Access for Cyber est un programme d’accès soumis à examen, et non le nom d’un modèle. L’approbation pour Daybreak Blue s’applique uniquement à la personne ou au service, à l’espace de travail ou à l’organisation API et au projet, au modèle et à l’interface produit autorisés. Daybreak Red nécessite une approbation et une mise à disposition distinctes ; déposer une demande, faire vérifier son identité ou obtenir l’accès à Daybreak Blue ne donne pas accès aux modèles spécialisés.
Pour les projets API approuvés, gpt-daybreak-blue-latest correspond à gpt-5.6-sol,
et gpt-daybreak-red-latest correspond à gpt-5.6-cyber. Utilisez l’alias Daybreak
ou, si votre projet dispose de l’approbation requise, l’identifiant
du modèle sous-jacent correspondant. L’accès et le comportement du modèle dépendent de l’organisation
et du projet approuvés ; l’identifiant du modèle ne suffit pas à lui seul à accorder l’accès.
Trusted Access ne donne pas automatiquement droit à la politique de non-conservation des données. Vérifiez les paramètres de conservation approuvés séparément pour l’organisation API précise et le point de terminaison concerné.
Trusted Access régit les accès approuvés aux modèles ; il ne configure ni vos outils, ni votre environnement, ni votre périmètre d’intervention.
Si un workflow utilisant l’API Responses ou Agents SDK peut effectuer des actions sensibles en matière de cybersécurité, examinez chaque appel d’outil proposé pour vérifier qu’il respecte le périmètre approuvé avant son exécution. Refusez les actions non autorisées et suspendez les modifications ambiguës ou à haut risque dans l’attente d’une approbation humaine. Appliquez des restrictions indépendantes au système de fichiers et au réseau, conservez des journaux d’audit et bloquez l’exécution si la révision est indisponible. Consultez Garde-fous et révision humaine.
La révision des appels d’outils au niveau de l’application et le bac à sable intégré à Codex sont distincts des mesures de protection de l’API en matière de cybersécurité décrites sur cette page.
Mesures de protection pour les organisations sans ZDR
Si nos systèmes détectent dans votre trafic une activité potentiellement suspecte en matière de cybersécurité qui dépasse les seuils définis, l’accès à ces modèles peut être temporairement révoqué. Dans ce cas, les requêtes API renverront une erreur avec le code d’erreur cyber_policy.
Si votre organisation n’a pas mis en place de safety_identifier par utilisateur, l’accès peut être temporairement révoqué pour l’ensemble de l’organisation. Si votre organisation fournit un safety_identifier unique par utilisateur final, l’accès peut être temporairement révoqué pour l’utilisateur concerné uniquement plutôt que pour l’ensemble de l’organisation (après révision humaine et avertissements). Fournir des identifiants de sécurité permet de limiter les perturbations pour les autres utilisateurs de votre plateforme.
Mesures de protection pour les organisations avec ZDR
Le processus est globalement similaire à celui décrit ci-dessus pour les organisations sans politique de non-conservation des données (ZDR) ; toutefois, pour les organisations utilisant la ZDR, des mesures d’atténuation supplémentaires sont appliquées à chaque requête.
Si une requête est classée comme potentiellement suspecte, vous pouvez recevoir une erreur API avec le code d’erreur cyber_policy. Pour les requêtes en streaming, ces erreurs peuvent être renvoyées au milieu d’autres événements de streaming.
Comme pour les organisations sans ZDR, si certains seuils d’activité suspecte en matière de cybersécurité sont atteints, l’accès peut être limité pour le safety_identifier concerné ou pour l’ensemble de l’organisation.
Recours
Si vous pensez que votre accès a été limité à tort et que vous avez besoin de le rétablir avant la fin de la période de 7 jours, contactez l’assistance.