For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Theme

Contrôles de cybersécurité

Comprenez les mesures de protection en matière de cybersécurité et leurs effets sur l’accès à l’API.

Selon notre cadre de préparation, nous classons GPT-5.6 Cyber au niveau « Élevé » et GPT-6 Cyber au niveau « Critique » en matière de cybersécurité. Des mesures de protection automatisées supplémentaires s’appliquent aux modèles de l’API classés au niveau « Élevé » ou « Critique » en cybersécurité. Les mesures de protection de l’API diffèrent de celles de Codex. Pour en savoir plus, consultez la documentation sur les mesures de protection de Codex.

Ces dispositifs recherchent des 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é. Comme nous ajustons encore ces systèmes, il arrive qu’ils signalent des travaux légitimes de recherche en sécurité ou de défense. Nous estimons que ces mesures ne toucheront qu’une faible part du trafic et nous continuons d’améliorer l’expérience d’utilisation de l’API.

Accès autorisé et workflows d’agents

Trusted Access for Cyber est un programme d’accès sur examen des demandes. Ce nom ne désigne pas un modèle. L’approbation pour Daybreak Blue vaut uniquement pour la personne ou le service autorisé, pour l’espace de travail ou l’organisation API et son projet, ainsi que pour le modèle et l’interface produit concernés. Daybreak Red nécessite une approbation et une activation distinctes. Ni le dépôt d’une demande, ni la vérification de l’identité, ni l’obtention de l’accès à Daybreak Blue ne donnent accès aux modèles spécialisés.

Pour les projets API approuvés, utilisez le modèle de cybersécurité le plus performant auquel vous avez accès. Le modèle auquel renvoie un alias peut changer et dépend de vos autorisations d’accès. Consultez le guide Utiliser Daybreak dans l’API Responses pour choisir un modèle et une valeur pour access_programs.cyber, comprendre le comportement par défaut et gérer les erreurs. 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 à y donner accès.

Trusted Access ne donne pas automatiquement droit à la politique de non-conservation des données. Vérifiez quelles règles de conservation ont fait l’objet d’une approbation distincte pour l’organisation API et le point de terminaison concernés.

Trusted Access régit l’accès aux modèles pour lesquels vous avez obtenu une autorisation. Le programme ne configure pas vos outils ni votre environnement et ne définit pas le périmètre de votre intervention.

Si un workflow utilisant l’API Responses ou le SDK Agents peut effectuer des opérations sensibles en matière de cybersécurité, vérifiez avant l’exécution que chaque appel d’outil proposé respecte le périmètre autorisé. Refusez les actions non autorisées. Suspendez les modifications ambiguës ou à haut risque dans l’attente d’une approbation humaine. Imposez des restrictions indépendantes pour le système de fichiers et le réseau, conservez des journaux d’audit et bloquez l’exécution si la vérification est impossible. Consultez le guide sur les garde-fous et la vérification humaine.

La vérification des appels d’outils par l’application et l’exécution en bac à sable dans Codex sont distinctes des mesures de protection de l’API décrites sur cette page.

Pour GPT-6-Cyber, configurez votre projet et votre liste d’adresses IP autorisées avant d’envoyer des requêtes.

Mesures de protection pour les organisations sans ZDR

Si nos systèmes détectent dans votre trafic une activité de cybersécurité potentiellement suspecte 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 renvoient une erreur portant le code 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 pour chaque utilisateur final, la révocation temporaire de l’accès peut se limiter à l’utilisateur concerné au lieu de s’étendre à toute l’organisation, après examen par une personne et émission d’avertissements. Fournir ces identifiants de sécurité permet de limiter les perturbations pour les autres utilisateurs de votre plateforme.

Mesures de protection pour les organisations avec ZDR

La procédure est en grande partie la même que celle décrite ci-dessus pour les organisations sans politique de non-conservation des données (ZDR). Pour les organisations qui appliquent cette politique, des mesures de protection supplémentaires s’appliquent à chaque requête.

Si une requête est jugée potentiellement suspecte, l’API peut vous renvoyer une erreur portant le code cyber_policy. Pour les requêtes en streaming, cette erreur peut survenir au milieu des autres événements du flux.

Comme pour les organisations sans ZDR, si l’activité de cybersécurité suspecte atteint certains seuils, la restriction d’accès peut s’appliquer au safety_identifier concerné ou à toute l’organisation.

Recours

Si vous estimez que votre accès a été limité par erreur et que vous avez besoin de le rétablir avant la fin du délai de 7 jours, contactez l’assistance.