Codex beginnt mit der Verschlüsselung von Subagent-Prompts

 (github.com/openai)
2 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bei MultiAgentV2 in der Codex CLI werden spawn_agent-, send_message- und followup_task-Nachrichten verschlüsselt, wodurch ein Regression bei der Audit-Trail-Nachvollziehbarkeit entsteht: Delegierungsinhalte sind in Eltern-Rollouts, Verlauf und Traces für Menschen nicht mehr lesbar
  • Seit PR #26210, die am 5. Juni 2026 gemergt wurde, wird InterAgentCommunication.content geleert und die Nutzlast nur noch in encrypted_content gespeichert; auch Empfängerverlauf und Kommunikationslogs zeichnen dadurch nur noch Chiffretext auf
  • Das Problem ist unabhängig von Abo, Modell und Plattform und betrifft Builds ab 0.137.0 mit aktiviertem MultiAgentV2; es ist getrennt von #26753, das fehlschlagende Request-Validierungen des Schemas für verschlüsselte Tools behandelt
  • Als Fix wird vorgeschlagen, die verschlüsselte message für das Empfängermodell zusammen mit einem verpflichtenden Klartextfeld für lokale Audits zu speichern, dabei für die Weitergabe Chiffretext oder IDs zu verwenden und auf die Klartext-Auditdaten dieselben Größenlimits anzuwenden
  • Ein Prototyp für spawn_agent wurde in einem separaten Snapshot-Commit umgesetzt, aber die Anwendung desselben Vertrags auf send_message, followup_task sowie auf Verlauf, Replays und Debug-Ansichten steht noch aus; das Issue ist weiterhin Open

Betroffener Bereich und Regressionsbedingungen

  • PR #26210 zur Verschlüsselungsänderung wurde am 5. Juni 2026 gemergt; betroffen sind Builds ab 0.137.0, die sie enthalten und MultiAgentV2 aktiviert haben
  • Betroffene Tools sind spawn_agent, send_message und followup_task; unabhängig von Abo, Modell, Betriebssystem und Terminal-Umgebung
  • Da es sich um eine Regression im gemergten Code und nicht um einen Zustand der lokalen Umgebung handelt, sind Codex-doctor-Berichte hier nicht relevant
  • Die Reproduktion erfolgt wie folgt
    1. MultiAgentV2 in einem Build aktivieren, der PR #26210 enthält
    2. Das Modell eines von spawn_agent, send_message oder followup_task aufrufen lassen
    3. Die Subagent-Aufgabe in Eltern-Rollout, Verlauf oder Trace prüfen
    4. Statt Aufgaben- oder Nachrichteninhalt ist nur Chiffretext sichtbar

Fehlende lokale Audit-Informationen

  • Die verschlüsselte Weitergabe selbst lässt sich als Verbesserung des Datenschutzes verstehen, aber die aktuelle Implementierung entfernt auch in lokalen Rollout-Verläufen, Trace-Zusammenfassungen sowie Audit- und Debug-Ansichten auf Elternseite alle menschenlesbaren Inhalte
  • Dadurch lassen sich bei der nachträglichen Rollout-Prüfung folgende Fragen nur schwer beantworten
    • Welche Aufgabe spawn_agent dem Kind-Agenten zugewiesen hat
    • Welche Nachricht an den Subagenten gesendet wurde
    • Warum ein bestimmter Child-Thread erzeugt wurde
  • Issue #26753 betrifft 400-Fehler, wenn das Schema für verschlüsselte Tools während der Request-Validierung scheitert; dieses Issue behandelt dagegen Auditierbarkeit und Debuggability nach Genehmigung des Schemas
  • Ziel ist nicht zwingend, die verschlüsselte Weitergabe rückgängig zu machen, sondern die Verschlüsselung beizubehalten und Delegierungsinhalte lokal lesbar zu machen

Datenfluss im aktuellen Code

  • InterAgentCommunication::new_encrypted() initialisiert content als leeren String und speichert die Nutzlast nur in encrypted_content
    • Der normale Konstruktor new() speichert Klartext in content und lässt encrypted_content leer
    • Der verschlüsselte Konstruktor macht das Gegenteil: content bleibt leer, encrypted_content wird gesetzt
  • to_model_input_item() schreibt bei vorhandenem encrypted_content nur die Präambel NEW_TASK oder MESSAGE plus die verschlüsselte Nutzlast in ResponseItem::AgentMessage
    • Selbst wenn zur Laufzeit nur content befüllt würde, würde ein lesbares ResponseItem dadurch nicht automatisch persistiert
    • Es braucht daher einen separaten lokalen Audit-Speicherpfad
  • communication_from_tool_message() übergibt die message des Tools direkt an new_encrypted() und erzeugt so ein Kommunikationsobjekt ohne Klartext in content
  • Die Argumentverarbeitung von send_message und followup_task deserialisiert nur target und die verschlüsselte message

Warum in Verlauf und Logs Chiffretext verbleibt

  • Der Empfänger-seitige Aufzeichnungspfad speichert das von to_model_input_item() erzeugte modellseitige ResponseItem in Gesprächsverlauf und Rollout
    • Bei verschlüsselter Kommunikation enthält dieser Eintrag keine lesbare Audit-Formulierung, sondern die verschlüsselte Weitergabe-Nutzlast
    • Im Rollout werden InterAgentCommunicationMetadata und das zugehörige ResponseItem gemeinsam persistiert
  • Das strukturierte Kommunikationslog ersetzt content ebenfalls durch encrypted_content als Event-content, wenn content leer ist
  • In dieser Struktur landet daher selbst in Feldern, die als menschenlesbare Nachricht angezeigt werden, Chiffretext; die Anforderungen „verschlüsselte Weitergabe beibehalten“ und „lokale Auditdaten erhalten“ sind also nicht getrennt

Vorgeschlagener Vertrag mit doppeltem Inhalt

  • Die bestehende verschlüsselte message bleibt als Nutzlast für die Weitergabe an das Empfängermodell erhalten
  • Jedes MultiAgentV2-Kommunikationstool erhält zusätzlich ein verpflichtendes Klartextfeld für Audits
    • spawn_agent: task_message
    • send_message, followup_task: ein konsistenter Name wie task_message oder message_text
  • Leere Klartext-Auditwerte werden an der Handler-Grenze abgewiesen
  • InterAgentCommunication speichert dann beide Werte zusammen
    • encrypted_content: die verschlüsselte message
    • content: eine menschenlesbare Audit-Kopie
  • to_model_input_item() bleibt unverändert, sodass an das Empfängermodell weiterhin nur Chiffretext und nicht die lokale Audit-Kopie weitergegeben wird
  • Eltern-Toolaufrufe und Rollouts persistieren das Klartextfeld, ebenso strukturierte Trace-Interaktionskanten und lokale Kommunikationslogs
  • Die Korrelation zwischen Toolaufruf und Child-Weitergabe erfolgt nicht über übereinstimmenden Klartext, sondern über Chiffretext oder ID
    • Das Klartextfeld ist Audit-Metadaten und ersetzt nicht die Kennung der verschlüsselten Weitergabe
  • Auf das neue Klartext-Auditfeld werden dieselben erzwungenen Größenlimits angewandt wie auf die zugehörige Delegierungsnachricht, damit Rollouts oder Kontexteinträge nicht unbegrenzt anwachsen

spawn_agent-Prototyp und verbleibende Arbeit

Abnahmekriterien und aktueller Status

  • In Eltern-Rollouts und Verläufen muss der Klartext von v2 spawn_agent, send_message und followup_task lesbar sein
  • Auch bei aktivierter Verschlüsselung darf das Child-Modell nur die verschlüsselte Weitergabe-Nutzlast erhalten
  • Strukturierte Rollout-Trace-Kanten müssen ein größenbeschränktes Klartext-message_content enthalten
  • Kommunikationslogs sollen den Klartext-Auditinhalt verwenden, wenn vorhanden, und nicht Chiffretext in lesbare Nachrichtenfelder einsetzen
  • Resume und Replay müssen die Audit-Kopie erhalten, dürfen sie aber nicht in den Kontext des Child-Modells injizieren
  • Das bisherige Verhalten der unverschlüsselten v1-Kommunikation darf sich nicht ändern
  • Für alle drei v2-Tools sind Regressionstests erforderlich, die sowohl lesbare lokale Auditdaten als auch verschlüsselte Eingaben für das Empfängermodell verifizieren
  • Auf der bereitgestellten Seite steht das Issue weiterhin auf Open; ein Merge eines Fixes ins Haupt-Repository ist nicht ersichtlich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Dieser Titel ist leicht missverständlich. Gemeint ist genau genommen, dass Codex damit begonnen hat, Sub-Agent-Prompts zu verschlüsseln und sie vor den Nutzern zu verbergen.
    Der ursprüngliche Titel lautete: „Codex starts encrypting prompts, uses ciphertext for inference instead“.

    • Es wirkt sehr wahrscheinlich, dass dies eingeführt wurde, weil der ultra-Modus von GPT-5.6 Arbeit auf mehrere Sub-Agents verteilt. Zuvor war dieser Modus nur im Web-UI verfügbar und entspricht vermutlich dem früheren Pro-Modus.
      Wenn das System mit vollständigen Reinforcement-Learning-Rollouts trainiert wurde, in denen Agents miteinander interagieren, scheint OpenAI diese Prompts wie rohe Reasoning-Spuren zu behandeln und verhindern zu wollen, dass andere sie direkt zum Training nutzen.
      Es gibt auch Hinweise darauf, dass die undurchsichtigen Kompressions-Blobs, die ein dedizierter Kompressions-Endpunkt zurückgibt, keine Texte sind, sondern Latent-Space-Repräsentationen der Unterhaltung; auch die deutlich höhere Kompressionstreue von OpenAI im Vergleich zu anderen Anbietern stützt diese Vermutung. Möglicherweise wurde eine ähnliche Technik auch auf Sub-Agent-Prompts angewendet, und ich frage mich, ob beim Erzeugen von Sub-Agents unterschiedlicher Modelltypen ebenfalls verschlüsselte Blobs verwendet werden.
    • Dass auf dem lokalen Computer Dutzende bis Hunderte stochastische Agents laufen und man nicht einmal die Anweisungen prüfen kann, die diese Agents erhalten haben, ist absurd.
      Beim Durchsehen von Claudes Sub-Agents und Workflows kam ich schon einmal zu dem Schluss: „Das hätte von Anfang an nicht ausgeführt werden dürfen.“ Codex-Nutzer müssen dagegen Tokens blind für verschlüsselte Übergabeanweisungen und Shell-Aufgaben ausgeben, die der Orchestrator an Sub-Agents weitergibt.
    • Ein erheblicher Teil des geistigen Eigentums von Codex liegt vermutlich weniger in der Codebasis als in Prompt-Struktur, Reihenfolge und Orchestrierung.
      Auch wir wollten Unternehmen erlauben, den von ihnen bevorzugten oder vorgeschriebenen AI-Anbieter samt eigenem API-Key zu wählen und dazu einfache Tarife anbieten, haben aber schnell erkannt, dass Backend-Prompts an Kunden durchsickern könnten. Mit detaillierten Ausführungsspuren ließe sich relativ leicht reverse engineeren, was wir tun, also haben wir diese Idee letztlich verworfen.
    • Zuerst dachte ich, es handle sich um eine Technik wie homomorphe Verschlüsselung, aber am Ende sieht es nach gewöhnlicher Gier aus.
    • Es ist nicht das erste Mal, dass Codex etwas verschlüsselt. Der hervorragende Kompressions-Endpunkt gibt schon seit mindestens fünf Monaten riesige verschlüsselte Blobs zurück.

  • Jetzt weiß ich, warum mein lokales Tool zum Inspizieren von Coding-Agent-Sessions in manchen Situationen nicht mehr funktionierte.
    Eine interessante Designentscheidung; ich frage mich, wie viele Menschen extern verschlüsselte Befehle, die auf ihrem Computer ausgeführt werden sollen, akzeptieren werden.

    • Die Anreize von OpenAI scheinen nicht exakt mit denen der Nutzer, einschließlich Unternehmenskunden, übereinzustimmen. Auch aktuelle Aussagen von Alex Karp und Satya Nadella sind einen Blick wert.
      Inhalte vor Nutzern zu verschlüsseln und zu verbergen ist der Ansatz, den die RIAA bei DRM nutzte, weil sie Urheberrechtsverletzungen befürchtete; ich frage mich, ob auch das hier eine nutzerfeindliche Entscheidung ist.
    • Wenn man den YOLO-Modus nutzt, nimmt man dieses Risiko ohnehin schon in Kauf; entscheidend sind die Tool Calls. Die Tool Calls selbst lassen sich nicht verschlüsseln.

  • Wegen dieses Verhaltens nutze ich weiterhin den Chat-Completions-Endpunkt. OpenAI hat Nutzer subtil von Chat Completions weg und hin zur leichter zu verschleiernden Responses API gedrängt.
    Bei Chat Completions kann man den Reasoning-Prozess direkt kontrollieren; wenn man experimentelle Funktionen aktiviert und einige recht verwirrende Optionen setzt, kann man mit dem aktuellen GPT-5.6-Modell sogar einen eigenen Monte-Carlo-Tree-Search-(MCTS)-Agent bauen.
    In VS Copilot kann man mit eigenem API-Token und Modelleinstellungen bis gpt5.5 verwenden, aber die gpt5.6-Familie funktioniert derzeit nicht. Ich vermute, weil dort reasoning_effort nicht auf none erzwungen wird, um das neue Verhalten zur Ausweitung der Eintrittsbarrieren zu erfüllen.

    • Ich frage mich, was genau mit der hier erwähnten MCTS-Technik gemeint ist. Der bereitgestellte Gedankengang ist ohnehin so stark abstrahiert zusammengefasst, dass er kaum nützlich ist, und ich bezweifle, dass man den Reasoning-Prozess wirklich vollständig kontrollieren kann.
    • MCTS steht für Monte Carlo Tree Search.
    • Ich würde mir wünschen, dass MCTS hier nicht wie ein Buzzword missbraucht wird. Die beschriebene Methode ist im strengen Sinn kein MCTS.
    • Die Responses API bietet gegenüber Chat Completions viele Vorteile: https://developers.openai.com/api/docs/guides/migrate-to-res...
      Alle neuen Modelle, die derzeit erscheinen, sind Reasoning-Modelle; daher sollte man gemäß den Empfehlungen die Responses API verwenden.

  • Ich frage mich auch, ob GPT-Abos vielleicht daran gehindert werden, in alternativen Ausführungs-Tools verwendet zu werden. Wenn nicht, wäre es kein großes Problem; codex cli selbst ist ein erstaunlich gewöhnliches Ausführungs-Tool.

    • Das scheint eher unwahrscheinlich. Die gesamte app-server-Architektur existiert gerade, um solche Integrationen zu unterstützen; um das aus Codex zu entfernen, müsste man riesige Teile herausreißen.
      Auch ich kann mich über die RPC-API des app-server sehr leicht anbinden, weshalb ich Codex am meisten nutze; inzwischen verwende ich es fast vollständig über meine eigene Integration statt über die öffentliche Codex-TUI.
      Wenn aber Prompts und Ähnliches, also die tatsächlichen Inferenz-Eingaben auf der lokalen Festplatte, verschlüsselt werden, sodass nur das OpenAI-Backend sie sehen kann, dann kann man trotz einfacher Integration nicht mehr nachvollziehen, was passiert. Es ist schwer zu verstehen, warum das Team dies für eine gute Entscheidung hielt.
    • Anthropic und Google verlangen bereits Aufpreise, wenn man ihre eigenen Ausführungs-Tools nutzt, und genau das ist der ganze Grund, OpenAI zu verwenden.
      Wenn OpenAI denselben Weg einschlägt, gehe ich wieder zu Claude zurück oder kaufe noch einen Spark, um lokal auszuführen.
    • Solange Anthropic bei der Einführung in Unternehmen vorn liegt, werden sie es wohl nicht blockieren. Wenn OpenAI mit großem Abstand in Führung geht, weiß ich nicht, wie sich das ändern wird; aber bis dahin hoffe ich, dass offene Modelle besser sind als gpt-5.6 sol.
    • Da Codex selbst begonnen hat, einen Proxy bereitzustellen, der das Abo kapselt, scheint eine Sperre unwahrscheinlich.
      https://github.com/openai/codex/blob/main/codex-rs/responses...
    • Kürzlich hat Tibo von OpenAI auf Twitter darum gebeten, zu teilen, wie man GPT mit Claude Code ausführt; es wirkt also nicht so, als wären sie gegen die Nutzung alternativer Ausführungs-Tools.

  • Der frühere HN-Titel klang so, als würde direkt auf Chiffrat inferiert, was sehr irreführend war. Dafür bräuchte man homomorphe Verschlüsselung, die weit über dem derzeit bekannten Stand liegt.

    • Tatsächlich wird der Inhalt verschlüsselt, den der Agent an einen Sub-Agenten sendet, sodass nur das OpenAI-Backend den Klartext sehen kann.
      Früher schickte der Agent dem Sub-Agenten Klartext-Prompts, und sie blieben auch in Logs und Sitzungsdaten unverändert erhalten; selbst bei Nutzung der experimentellen Sub-Agent-Funktion konnte man daher die Daten öffnen und die internen Abläufe nachvollziehen.
      Wenn man jetzt Sol oder Terra verwendet, übergibt das Backend erzeugtes Chiffrat an den Sub-Agenten, und der Sub-Agent nutzt es wiederum für die Inferenz im OpenAI-Backend. Luna scheint nicht betroffen zu sein; verschlüsselt werden nicht ganze Sitzungen, sondern nur delegierte Nachrichten zwischen Agenten.
      Die interne Inferenz von OpenAI findet nicht auf Chiffrat statt, aber lokale Nutzer sehen nur noch Chiffrat statt Klartext. Um das klarzustellen, wurde der Titel in „Codex starts encrypting sub-agent prompts“ geändert.
    • Weil im Titel „inferencing“ stand, dachte auch ich sofort an homomorphe Verschlüsselung oder Rechnen auf Chiffrat.

  • Kürzlich gab es auf Twitter einen Bericht, dass ein GPT-5.6-Sub-Agent versehentlich das Home-Verzeichnis eines Nutzers gelöscht habe.
    Ich frage mich, ob dadurch, dass man nicht mehr sehen kann, was der Sub-Agent vorhat, sogar die Sicherheitsvorkehrungen versagt haben.
    https://x.com/mattshumer_/status/2076794038456385546?s=20

  • Dabei geht es darum, zur Verringerung der Token-Nutzung Cache-Keys über den Client weiterzureichen. Da man das mit anderen Subtask-Tools leicht umgehen kann, kann es keine Abwehrmaßnahme gegen Model Distillation sein.

  • Ich frage mich, wo genau die Verschlüsselung stattfindet. Ich dachte, der Haupt-Agent ruft den Sub-Agenten lokal auf; daher frage ich mich, ob Codex so aufgebaut ist, dass Sub-Agenten auf OpenAI-Servern aufgerufen werden, bevor etwas lokal ankommt.

    • Bisher schickte der Agent dem Sub-Agenten Klartext-Prompts, und sie blieben auch in Logs und Sitzungsdaten unverändert erhalten, sodass man interne Abläufe leicht untersuchen konnte.
      Bei Sol oder Terra wird statt des Prompts vom OpenAI-Backend erzeugtes Chiffrat übergeben, und der Sub-Agent nutzt es wiederum für die Backend-Inferenz. Luna scheint nicht betroffen zu sein; da nicht die gesamte Sitzung, sondern nur delegierte Nachrichten zwischen Agenten verschlüsselt werden, kann nun nur noch das OpenAI-Backend diesen Inhalt entschlüsseln.

  • Ich hatte mich gefragt, warum chinesische Schwarzmarkt-Weiterverkaufsdienste seit gestern nicht mehr funktionierten; vermutlich liegt es an dieser Änderung.

    • Solche Schwarzmärkte bündeln nicht nur Abos und verkaufen sie weiter, sondern speichern auch Daten und verkaufen sie an Stellen, die damit Modelle trainieren. Die Verschlüsselung ist nützlich, um zumindest Letzteres zu verhindern; sie verfolgt denselben Zweck wie andere zuvor aufgedeckte Methoden, ist aber deutlich sauberer implementiert.

  • Der Hauptzweck scheint zu sein, Versuche zu erschweren, massenhaft Nutzeranfragen und Antworten zu proxyen und zum Training konkurrierender Modelle zu verwenden.

    • Es wirkt eindeutig so, als wolle man verhindern, dass andere Anbieter OpenAIs Art der Multi-Agenten-Steuerung einsehen.
      Für zahlende Nutzer ist das jedoch eine schlechte Implementierung, weil sie bei Problemen keinerlei Möglichkeit haben, die Ursache herauszufinden, und die Multi-Agenten-Funktion dadurch kaum sinnvoll nutzen können.