Codex commence à chiffrer les prompts des sous-agents

 (github.com/openai)
2 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Avec le chiffrement par MultiAgentV2 de la CLI Codex des messages spawn_agent, send_message et followup_task, une régression de la piste d’audit se produit : le contenu délégué devient illisible pour un humain dans le rollout parent, l’historique et les traces
  • Depuis la PR #26210, fusionnée le 5 juin 2026, InterAgentCommunication.content est vidé et la charge utile n’est stockée que dans encrypted_content ; l’historique du destinataire et les journaux de communication enregistrent eux aussi du texte chiffré
  • Le problème est indépendant de l’abonnement, du modèle et de la plateforme, et concerne les builds postérieurs à 0.137.0 avec MultiAgentV2 activé ; il est distinct de #26753, qui traite d’un échec de validation de requête dans le schéma des outils de chiffrement
  • La correction proposée consiste à conserver à la fois le message chiffré destiné au modèle récepteur et un champ en clair obligatoire pour l’audit local, tout en utilisant le texte chiffré ou un ID pour identifier les transmissions et en appliquant les mêmes limites de taille aux données d’audit en clair
  • Un prototype pour spawn_agent a été implémenté dans un commit snapshot distinct, mais il reste à appliquer le même contrat à send_message et followup_task, ainsi qu’aux écrans d’historique, de relecture et de débogage ; l’issue est encore ouverte

Périmètre et conditions de régression

  • La PR de changement de chiffrement #26210 a été fusionnée le 5 juin 2026 ; les builds concernés sont les builds postérieurs à 0.137.0 qui l’incluent et activent MultiAgentV2
  • Les outils affectés sont spawn_agent, send_message et followup_task ; le problème est indépendant de l’abonnement, du modèle, du système d’exploitation et de l’environnement de terminal
  • Comme il s’agit d’une régression constatée dans le comportement du code fusionné, et non de l’état de l’environnement local, les rapports Codex doctor ne s’appliquent pas
  • Les étapes de reproduction sont les suivantes
    1. Activer MultiAgentV2 dans un build incluant la PR #26210
    2. Faire appeler par le modèle l’un des outils spawn_agent, send_message ou followup_task
    3. Vérifier la tâche du sous-agent dans le rollout parent, l’historique et les traces
    4. Constater qu’à la place de la tâche ou du corps du message, seul du texte chiffré est visible

Informations d’audit local disparues

  • La transmission chiffrée elle-même peut se comprendre comme un renforcement de la confidentialité, mais l’implémentation actuelle supprime aussi le contenu lisible par un humain de l’historique local du rollout, des résumés de traces et des vues d’audit et de débogage côté parent
  • En conséquence, il devient difficile de répondre aux questions suivantes lors d’un examen a posteriori du rollout
    • Quelle tâche spawn_agent a confiée à l’agent enfant
    • Quel message a été envoyé au sous-agent
    • Pourquoi un thread enfant donné a été créé
  • L’issue #26753 porte sur un problème où le schéma des outils de chiffrement renvoie une erreur 400 lors de la validation de la requête ; la présente issue concerne l’auditabilité et la capacité de débogage après validation du schéma
  • L’objectif n’est pas nécessairement d’annuler la transmission chiffrée, mais de permettre de lire localement le contenu délégué tout en conservant le chiffrement

Flux de données dans le code actuel

  • InterAgentCommunication::new_encrypted() initialise content avec une chaîne vide et stocke la charge utile uniquement dans encrypted_content
    • Le constructeur standard new() stocke le texte en clair dans content et laisse encrypted_content vide
    • Le constructeur chiffré fait l’inverse : il vide content et renseigne encrypted_content
  • to_model_input_item(), lorsqu’un encrypted_content est présent, place uniquement le préfixe NEW_TASK ou MESSAGE et la charge utile chiffrée dans ResponseItem::AgentMessage
    • Ainsi, remplir uniquement le content à l’exécution ne suffit pas à persister automatiquement un ResponseItem lisible
    • Un chemin de stockage d’audit local distinct est nécessaire
  • communication_from_tool_message() transmet directement le message de l’outil à new_encrypted(), créant un objet de communication sans content en clair
  • Le traitement des arguments de send_message et followup_task ne désérialise que target et le message chiffré

Pourquoi du texte chiffré reste dans l’historique et les logs

  • Le chemin d’enregistrement côté récepteur stocke dans l’historique de conversation et le rollout le ResponseItem destiné au modèle produit par to_model_input_item()
    • Dans une communication chiffrée, cet élément contient non pas une phrase d’audit lisible, mais la charge utile de transmission chiffrée
    • Le rollout persiste à la fois InterAgentCommunicationMetadata et le ResponseItem correspondant
  • Les logs de communication structurés remplacent eux aussi le content de l’événement par encrypted_content lorsque content est vide
  • Dans cette structure, même les champs affichés comme messages lisibles par un humain contiennent du texte chiffré ; les exigences consistant à conserver le chiffrement de la transmission et à préserver les données d’audit local ne sont donc pas séparées

Contrat à double contenu proposé

  • Le message chiffré existant est conservé comme charge utile destinée au modèle récepteur
  • Un champ d’audit en clair obligatoire est ajouté à chaque outil de communication MultiAgentV2
    • spawn_agent : task_message
    • send_message, followup_task : un nom cohérent comme task_message ou message_text
  • Les valeurs d’audit en clair vides sont refusées à la frontière des handlers
  • InterAgentCommunication stocke les deux valeurs ensemble
    • encrypted_content : le message chiffré
    • content : une copie d’audit lisible par un humain
  • to_model_input_item() n’est pas modifié, afin que seul le texte chiffré soit transmis au modèle récepteur, et non la copie d’audit locale
  • Les appels d’outils parents et les rollouts persistent le champ en clair, et les arêtes d’interaction des traces structurées ainsi que les logs de communication locaux le conservent aussi
  • La corrélation entre les appels d’outils et les éléments transmis aux enfants est déterminée non par une correspondance du texte en clair, mais par le texte chiffré ou un ID
    • Le champ en clair est une métadonnée d’audit et ne remplace pas l’identifiant de la transmission chiffrée
  • Le nouveau champ d’audit en clair reçoit la même limite de taille forcée que le message de délégation correspondant, afin d’éviter que les rollouts ou éléments de contexte ne grossissent sans limite

Prototype spawn_agent et travaux restants

Critères d’achèvement et état actuel

  • Le texte en clair des outils v2 spawn_agent, send_message et followup_task doit être lisible dans le rollout parent et l’historique
  • Même lorsque le chiffrement est activé, le modèle enfant ne doit recevoir que la charge utile de transmission chiffrée
  • Les arêtes de trace de rollout structurées doivent contenir un message_content en clair à taille limitée
  • Les logs de communication doivent utiliser le contenu d’audit en clair lorsqu’il existe, et ne pas remplacer le champ de message lisible par du texte chiffré
  • La reprise et la relecture doivent préserver la copie d’audit sans l’injecter dans le contexte du modèle enfant
  • Le comportement existant des communications v1 en clair ne doit pas changer
  • Des tests de régression sont nécessaires pour les trois outils v2, afin de vérifier à la fois les données d’audit local lisibles et l’entrée chiffrée destinée au modèle récepteur
  • Sur la page fournie, l’issue est ouverte, et aucun résultat n’indique qu’un correctif a été fusionné dans le dépôt amont

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Réactions sur Hacker News

  • Ce titre prête facilement à confusion. Plus précisément, cela signifie que Codex a commencé à chiffrer les prompts des sous-agents pour les cacher aux utilisateurs
    Le titre d’origine était « Codex starts encrypting prompts, uses ciphertext for inference instead »

    • Il est probable que cela ait été introduit parce que le mode ultra de GPT-5.6 répartit le travail entre plusieurs sous-agents. Auparavant, ce mode n’était disponible que dans l’interface web, et correspondait sans doute à l’ancien mode pro
      Si l’entraînement a été fait avec des rollouts complets de reinforcement learning où les agents interagissent entre eux, OpenAI semble traiter ces prompts comme des traces de raisonnement brutes afin d’empêcher d’autres acteurs de les exploiter directement pour l’entraînement
      Le blob compressé opaque renvoyé par l’endpoint de compression dédié pourrait lui aussi être non pas du texte, mais une représentation dans l’espace latent de la conversation, et le fait que la fidélité de compression d’OpenAI soit bien supérieure à celle des autres entreprises va dans le sens de cette hypothèse. Une technique similaire a peut-être été appliquée aux prompts des sous-agents, et je me demande si des blobs chiffrés sont aussi utilisés lors de la création de sous-agents de types de modèles différents
    • Le fait que des dizaines, voire des centaines d’agents probabilistes s’exécutent sur un ordinateur local, et qu’on ne puisse même pas inspecter les instructions qu’ils ont reçues, est absurde
      En examinant les sous-agents et workflows de Claude, il m’est déjà arrivé de conclure : « ça n’aurait jamais dû être exécuté ». Les utilisateurs de Codex doivent donc dépenser des tokens à l’aveugle pour des consignes de transfert chiffrées et des tâches shell que l’orchestrateur transmet aux sous-agents
    • Une grande partie de la propriété intellectuelle de Codex réside probablement moins dans la base de code que dans la construction, l’ordre et l’orchestration des prompts
      Nous aussi, nous avions essayé de laisser les entreprises choisir leur fournisseur d’IA préféré ou imposé ainsi que leurs propres clés API, tout en proposant une tarification simple, mais nous avons vite compris que les prompts backend pouvaient fuiter vers les clients. Avec des traces d’exécution détaillées, il devient relativement facile de faire de la rétro-ingénierie sur ce que nous faisons, donc nous avons abandonné cette idée
    • Au début, je pensais à une technologie comme le chiffrement homomorphe, mais au final cela ressemble à de la cupidité ordinaire
    • Ce n’est pas la première fois que Codex chiffre quelque chose. Son excellent endpoint de compression renvoie depuis au moins cinq mois d’énormes blobs chiffrés

  • Je comprends maintenant pourquoi mon outil local d’inspection des sessions d’agents de code a cessé de fonctionner dans certains cas
    C’est un choix de conception intéressant : je me demande combien de personnes accepteront des commandes de chiffrement externes exécutées sur l’ordinateur de l’utilisateur

    • Les incitations d’OpenAI ne semblent pas parfaitement alignées avec celles des utilisateurs, y compris les clients entreprises. Les déclarations récentes d’Alex Karp et de Satya Nadella méritent aussi d’être regardées
      Chiffrer le contenu pour le cacher à l’utilisateur rappelle la manière dont la RIAA utilisait le DRM par crainte de la violation du droit d’auteur ; on peut se demander s’il ne s’agit pas là aussi d’un choix hostile envers l’utilisateur
    • Si l’on utilise le mode YOLO, on a déjà accepté ce risque, et l’essentiel reste les appels d’outils. Les appels d’outils eux-mêmes ne peuvent pas être chiffrés

  • C’est à cause de ce genre de comportement que je continue d’utiliser l’endpoint Chat Completions. OpenAI pousse subtilement les utilisateurs à quitter Chat Completions pour aller vers l’API Responses, où l’obfuscation est plus facile
    Avec Chat Completions, on peut contrôler directement la procédure de raisonnement ; en activant des fonctionnalités expérimentales et en réglant certaines options un peu confuses, il est actuellement possible de construire un agent MCTS personnalisé avec les modèles GPT-5.6
    Dans VS Copilot, on peut utiliser jusqu’à gpt5.5 avec son propre token API et ses paramètres de modèle, mais la famille gpt5.6 ne fonctionne pas pour l’instant. J’imagine que c’est parce qu’il ne force pas reasoning_effort à none, comme l’exige ce nouveau durcissement de la barrière d’entrée

    • Je me demande précisément en quoi consiste la technique MCTS mentionnée ici. De toute façon, le processus de pensée fourni est résumé de manière trop abstraite pour être vraiment utile, donc je doute qu’on puisse réellement contrôler complètement la procédure de raisonnement
    • MCTS signifie Monte Carlo Tree Search
    • J’aimerais qu’on n’abuse pas de MCTS comme d’un mot à la mode ici. Ce qui est décrit n’est pas du MCTS au sens strict
    • L’API Responses offre de nombreux avantages par rapport à Chat Completions : https://developers.openai.com/api/docs/guides/migrate-to-res...
      Tous les nouveaux modèles qui sortent actuellement sont des modèles de raisonnement, donc il faut utiliser l’API Responses conformément aux recommandations

  • Je me demande aussi s’ils vont empêcher l’utilisation d’un abonnement GPT dans des outils d’exécution alternatifs. Si ce n’est pas le cas, ce n’est pas un gros problème, et codex cli lui-même est un outil d’exécution étonnamment ordinaire

    • Cela semble peu probable. Toute l’architecture app-server existe justement pour prendre en charge ce type d’intégration, donc le retirer de Codex exigerait de démonter une énorme partie du système
      Moi aussi, je peux très facilement m’intégrer via l’API RPC de app-server, donc c’est avec Codex que je travaille le plus, et désormais j’utilise presque tout via mon intégration maison plutôt que via le Codex TUI désormais public
      Mais s’ils chiffrent les prompts et autres éléments qui constituent les véritables entrées d’inférence sur le disque local, de sorte que seul le backend d’OpenAI puisse les voir, alors même si l’intégration reste simple, on ne peut plus comprendre ce qui se passe. J’ai du mal à comprendre pourquoi l’équipe a considéré cela comme une bonne décision
    • Anthropic et Google facturent déjà un supplément quand on utilise leurs propres outils d’exécution, et c’est justement toute la raison d’utiliser OpenAI
      Si OpenAI prend la même voie, je reviendrai sans doute à Claude ou j’achèterai un Spark de plus pour l’exécuter en local
    • Ils ne bloqueront probablement pas cela tant qu’Anthropic gardera une avance dans l’adoption en entreprise. Si OpenAI prend une large tête, difficile de dire ce qui changera, mais d’ici là j’espère que les modèles ouverts seront meilleurs que gpt-5.6 sol
    • Comme Codex lui-même a commencé à fournir un proxy qui enveloppe l’abonnement, il semble peu probable qu’ils bloquent cela
      https://github.com/openai/codex/blob/main/codex-rs/responses...
    • Récemment, Tibo d’OpenAI a demandé sur Twitter qu’on lui partage comment exécuter GPT avec Claude Code, donc ils ne semblent pas opposés à l’usage d’outils d’exécution alternatifs

  • L’ancien titre sur HN laissait fortement penser qu’il s’agissait d’inférer directement sur du texte chiffré, ce qui a provoqué beaucoup de confusion. Pour cela, il faudrait un chiffrement homomorphe bien plus avancé que tout ce qui est connu aujourd’hui

    • En réalité, ils ont chiffré ce que l’agent envoie au sous-agent afin que seul le backend d’OpenAI puisse voir le texte en clair
      Avant, l’agent envoyait des prompts en clair au sous-agent, et ils restaient aussi tels quels dans les logs et les données de session, ce qui permettait d’ouvrir les données et d’inspecter le fonctionnement interne même lors de l’utilisation de la fonctionnalité expérimentale de sous-agents
      Désormais, avec Sol ou Terra, le texte chiffré généré par le backend est transmis au sous-agent, qui l’utilise ensuite pour l’inférence à nouveau via le backend d’OpenAI. Luna ne semble pas concerné, et ce sont uniquement les messages entre agents délégués, pas toute la session, qui sont chiffrés
      L’inférence interne d’OpenAI ne s’effectue pas sur du texte chiffré, mais pour l’utilisateur local, seul le texte chiffré est visible à la place du texte en clair. Pour clarifier cela, j’ai modifié le titre en « Codex starts encrypting sub-agent prompts »
    • Comme le titre contenait « inferencing », j’ai moi aussi immédiatement pensé au chiffrement homomorphe ou au calcul sur données chiffrées

  • Un signalement a circulé récemment sur Twitter selon lequel un sous-agent GPT-5.6 avait supprimé par erreur le répertoire home de l’utilisateur
    Je me demande si, en ne pouvant plus voir ce que le sous-agent essayait de faire, les garde-fous n’ont pas eux aussi échoué
    https://x.com/mattshumer_/status/2076794038456385546?s=20

  • Il s’agit d’une méthode qui fait passer une clé de cache via le client afin de réduire l’usage de tokens. Comme il est facile de contourner cela en utilisant d’autres outils de sous-tâches, il est peu probable qu’il s’agisse d’une mesure de défense contre la distillation de modèles

  • Je me demande exactement où a lieu le chiffrement. Je pensais que l’agent principal appelait le sous-agent en local, mais je me demande si Codex n’est pas conçu de façon à appeler le sous-agent depuis les serveurs d’OpenAI avant même d’atteindre le local

    • Auparavant, l’agent envoyait des prompts en clair au sous-agent, et ils restaient aussi tels quels dans les logs et les données de session, ce qui permettait d’examiner facilement le fonctionnement interne
      Avec Sol ou Terra, le texte chiffré généré par le backend d’OpenAI est transmis à la place du prompt, et le sous-agent l’utilise ensuite à nouveau pour l’inférence côté backend. Luna ne semble pas concerné, et comme seuls les messages entre agents délégués sont chiffrés, et non la session entière, ce contenu ne peut désormais être déchiffré que par le backend d’OpenAI

  • Je me demandais pourquoi les services chinois de revente sur marché noir ne fonctionnaient plus depuis hier ; c’est probablement à cause de ce changement

    • Ces marchés noirs ne se contentent pas d’agréger des abonnements pour les revendre, ils stockent aussi les données avant de les vendre à des endroits qui entraînent ensuite des modèles. Le chiffrement est utile au moins pour empêcher cette seconde pratique ; l’objectif est le même que dans d’autres méthodes révélées auparavant, mais l’implémentation est bien plus propre

  • Le but principal semble être d’entraver les tentatives de proxy de grandes quantités de requêtes et de réponses utilisateur afin de les exploiter pour entraîner des modèles concurrents

    • Il semble clairement y avoir aussi la volonté d’empêcher d’autres fournisseurs d’observer la manière dont OpenAI orchestre le multi-agent
      Mais pour les utilisateurs payants, c’est une implémentation médiocre : s’il y a un problème, ils n’ont absolument aucun moyen d’en identifier la cause, ce qui rend les fonctionnalités multi-agents difficiles à utiliser correctement