Codex가 서브에이전트 프롬프트 암호화를 시작함

 (github.com/openai)
7P by GN⁺ | ★ favorite | 댓글 1개
  • Codex CLI의 MultiAgentV2가 spawn_agent, send_message, followup_task 메시지를 암호화하면서, 부모 롤아웃·이력·추적에서 위임 내용을 사람이 읽을 수 없게 되는 감사 추적 회귀가 발생함
  • 2026년 6월 5일 병합된 PR #26210 이후 InterAgentCommunication.content는 비워지고 페이로드가 encrypted_content에만 저장되며, 수신자 이력과 통신 로그도 암호문을 기록함
  • 문제는 구독·모델·플랫폼과 무관하고 MultiAgentV2가 활성화된 0.137.0 이후 빌드에 해당하며, 암호화 도구 스키마의 요청 검증 실패를 다루는 #26753과는 별개임
  • 제안된 수정은 수신 모델용 암호화 message와 로컬 감사용 필수 평문 필드를 함께 보관하되, 전달 식별에는 암호문이나 ID를 사용하고 평문 감사 데이터에는 동일한 크기 제한을 적용하는 방식임
  • spawn_agent용 프로토타입은 별도 스냅샷 커밋에 구현됐지만 send_message와 followup_task, 이력·재생·디버그 화면까지 같은 계약을 적용하는 작업은 남아 있으며, 이슈는 아직 Open 상태임

발생 범위와 회귀 조건

  • 암호화 변경 PR #26210은 2026년 6월 5일 병합됐으며, 이를 포함하고 MultiAgentV2를 활성화한 0.137.0 이후 빌드가 대상임
  • 영향받는 도구는 spawn_agent, send_message, followup_task이며 구독, 모델, 운영체제, 터미널 환경과는 무관함
  • 로컬 환경 상태가 아니라 병합된 코드 동작에서 확인되는 회귀이므로 Codex doctor 보고서는 해당하지 않음
  • 재현 절차는 다음과 같음
    1. PR #26210을 포함한 빌드에서 MultiAgentV2를 활성화함
    2. 모델이 spawn_agent, send_message, followup_task 중 하나를 호출하게 함
    3. 부모 롤아웃·이력·추적에서 서브에이전트 작업을 확인함
    4. 작업이나 메시지 본문 대신 암호문만 확인됨

사라진 로컬 감사 정보

  • 암호화된 전달 자체는 프라이버시 강화로 이해할 수 있지만, 현재 구현은 로컬 롤아웃 이력, 추적 축약, 부모 측 감사·디버그 화면에서도 사람이 읽을 수 있는 내용을 제거함
  • 그 결과 사후 롤아웃 검토에서 다음 질문에 답하기 어려움
    • spawn_agent가 자식 에이전트에 어떤 작업을 부여했는지
    • 서브에이전트에 어떤 메시지를 보냈는지
    • 특정 자식 스레드가 왜 생성됐는지
  • 이슈 #26753은 암호화 도구 스키마가 요청 검증 과정에서 400 오류를 반환하는 문제이며, 이번 이슈는 스키마가 승인된 뒤의 감사 가능성과 디버깅 가능성을 다룸
  • 목표는 암호화 전달을 반드시 되돌리는 것이 아니라, 암호화를 유지하면서 로컬에서 위임 내용을 읽을 수 있게 하는 것임

현재 코드의 데이터 흐름

  • InterAgentCommunication::new_encrypted()는 content를 빈 문자열로 초기화하고 페이로드를 encrypted_content에만 저장함
    • 일반 생성자 new()는 평문을 content에 저장하고 encrypted_content를 비워 둠
    • 암호화 생성자는 반대로 content를 비우고 encrypted_content에 값을 넣음
  • to_model_input_item()은 encrypted_content가 있으면 NEW_TASK 또는 MESSAGE 머리말과 암호화 페이로드만 ResponseItem::AgentMessage에 넣음
    • 따라서 런타임의 content만 채워도 읽을 수 있는 ResponseItem이 자동으로 영속화되지 않음
    • 별도의 로컬 감사 저장 경로가 필요함
  • communication_from_tool_message()는 도구의 message를 new_encrypted()에 직접 넘겨 평문 content가 없는 통신 객체를 만듦
  • send_message와 followup_task 인자 처리는 target과 암호화된 message만 역직렬화함
    • 빈 message는 거부하지만 별도의 평문 동반 필드가 없음
    • 공유 메시지 전달 경로는 이 값을 그대로 InterAgentCommunication 생성에 사용함

이력과 로그에 암호문이 남는 이유

  • 수신 측 기록 경로는 to_model_input_item()이 만든 모델용 ResponseItem을 대화 이력과 롤아웃에 저장함
    • 암호화 통신에서는 이 항목에 읽을 수 있는 감사 문구가 아니라 암호화 전달 페이로드가 포함됨
    • 롤아웃에는 InterAgentCommunicationMetadata와 해당 ResponseItem이 함께 영속화됨
  • 구조화 통신 로그도 content가 비어 있으면 encrypted_content를 이벤트의 content로 대체함
  • 이 구조에서는 사람이 읽는 메시지로 표시되는 필드에도 암호문이 들어가므로, 단순히 전달 암호화를 유지하는 것과 로컬 감사 데이터를 보존하는 요구가 분리되지 않음

제안된 이중 콘텐츠 계약

  • 기존 암호화 message는 수신 모델 전달용 페이로드로 유지함
  • 각 MultiAgentV2 통신 도구에 필수 평문 감사 필드를 추가함
    • spawn_agent: task_message
    • send_message, followup_task: task_message 또는 message_text처럼 일관된 이름
  • 핸들러 경계에서 빈 평문 감사 값을 거부함
  • InterAgentCommunication에는 두 값을 함께 저장함
    • encrypted_content: 암호화된 message
    • content: 사람이 읽을 수 있는 감사 사본
  • to_model_input_item()은 변경하지 않아 수신 모델에는 로컬 감사 사본이 아닌 암호문만 전달함
  • 부모 도구 호출과 롤아웃에는 평문 필드를 영속화하고, 구조화 추적의 상호작용 간선과 로컬 통신 로그에도 이를 유지함
  • 도구 호출과 자식 전달 항목의 상관관계는 평문 일치가 아니라 암호문 또는 ID로 판별함
    • 평문 필드는 감사 메타데이터이며 암호화 전달의 식별자를 대체하지 않음
  • 새 평문 감사 필드에는 대응하는 위임 메시지와 동일한 강제 크기 제한을 적용해 롤아웃이나 컨텍스트 항목이 무제한으로 커지지 않게 함

spawn_agent 프로토타입과 남은 작업

완료 조건과 현재 상태

  • 부모 롤아웃과 이력에서 v2 spawn_agent, send_message, followup_task의 평문을 읽을 수 있어야 함
  • 암호화가 활성화된 경우에도 자식 모델은 암호화된 전달 페이로드만 받아야 함
  • 구조화된 롤아웃 추적 간선에는 크기가 제한된 평문 message_content가 들어가야 함
  • 통신 로그는 평문 감사 콘텐츠가 있으면 이를 사용하고, 읽을 수 있는 메시지 필드에 암호문을 대신 넣지 않아야 함
  • 재개·재생은 감사 사본을 보존하되 이를 자식 모델 컨텍스트에 주입하지 않아야 함
  • 기존 평문 v1 통신 동작은 바뀌지 않아야 함
  • 세 가지 v2 도구 모두에 대해 읽을 수 있는 로컬 감사 데이터와 암호화된 수신 모델 입력을 함께 검증하는 회귀 테스트가 필요함
  • 제공된 페이지에서는 이슈가 Open 상태이며, 상위 저장소에 수정이 병합됐다는 결과는 없음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 제목은 오해하기 쉬움. 정확히는 Codex가 하위 에이전트 프롬프트를 암호화해 사용자에게 숨기기 시작했다는 뜻임
    원래 제목은 “Codex starts encrypting prompts, uses ciphertext for inference instead”였음

    • GPT-5.6의 ultra 모드가 여러 하위 에이전트로 작업을 분산하기 때문에 도입됐을 가능성이 커 보임. 이전에는 이 모드가 웹 UI에서만 제공됐고, 아마 예전의 pro 모드에 해당함
      에이전트끼리 상호작용하는 전체 강화학습 롤아웃으로 훈련했다면, OpenAI는 이 프롬프트를 원시 추론 흔적처럼 취급해 다른 이들이 직접 학습에 활용하지 못하게 하려는 듯함
      전용 압축 엔드포인트가 반환하는 불투명한 압축 블롭도 텍스트가 아니라 대화의 잠재 공간 표현일 수 있다는 징후가 있으며, OpenAI의 압축 충실도가 다른 업체보다 훨씬 높다는 점도 이 추측을 뒷받침함. 하위 에이전트 프롬프트에도 비슷한 기법을 적용했을 수 있고, 서로 다른 모델 유형의 하위 에이전트를 생성할 때도 암호화된 블롭을 쓰는지 궁금함
    • 로컬 컴퓨터에서 수십~수백 개의 확률적 에이전트가 실행되는데, 그 에이전트들이 받은 명령조차 검사할 수 없다는 건 황당함
      Claude의 하위 에이전트와 작업 흐름을 살펴보다가 “이건 애초에 실행하면 안 됐다”고 판단한 적이 있는데, Codex 사용자는 오케스트레이터가 하위 에이전트에 전달하는 암호화된 전달 지시와 셸 작업에 토큰을 무작정 써야 하는 셈임
    • Codex의 지식재산 중 상당 부분은 코드베이스보다 프롬프트 구성·순서·오케스트레이션에 있을 가능성이 큼
      우리도 기업이 선호하거나 의무 지정한 AI 공급자와 자체 API 키를 선택하게 하고 단순한 요금제를 제공하려 했지만, 백엔드 프롬프트가 고객에게 유출될 수 있다는 사실을 금방 깨달았음. 상세한 실행 흔적을 확보하면 우리가 하는 일을 비교적 쉽게 역공학할 수 있어 결국 그 구상을 접었음
    • 처음에는 동형 암호 같은 기술인가 했지만, 결국 평범한 탐욕으로 보임
    • Codex가 무언가를 암호화한 것은 처음이 아님. 뛰어난 압축 엔드포인트는 적어도 5개월 전부터 거대한 암호화 블롭을 반환해 왔음

  • 코딩 에이전트 세션을 검사하는 내 로컬 도구가 일부 상황에서 왜 작동을 멈췄는지 이제 알겠음
    사용자의 컴퓨터에서 실행될 외부 암호화 명령을 얼마나 많은 사람이 받아들일지 궁금한 흥미로운 설계 결정임

    • OpenAI의 유인은 기업 고객을 포함한 사용자와 정확히 일치하지 않는 듯함. Alex Karp와 Satya Nadella 등의 최근 발언도 살펴볼 만함
      사용자에게 내용을 암호화해 숨기는 건 RIAA가 저작권 침해를 걱정하며 DRM에 쓰던 방식인데, 이 역시 사용자 적대적인 선택인지 의문임
    • YOLO 모드를 쓴다면 이미 그런 위험을 감수한 셈이고, 중요한 것은 도구 호출임. 도구 호출 자체는 암호화할 수 없음

  • 이런 동작 때문에 계속 Chat Completions 엔드포인트를 쓰고 있음. OpenAI는 사용자를 Chat Completions에서 벗어나 난독화하기 쉬운 Responses API 쪽으로 미묘하게 유도해 왔음
    Chat Completions에서는 추론 절차를 직접 통제할 수 있어, 실험 기능을 켜고 다소 혼란스러운 옵션을 설정하면 현재 GPT-5.6 모델로 사용자 정의 몬테카를로 트리 탐색(MCTS) 에이전트도 만들 수 있음
    VS Copilot에서는 사용자 API 토큰과 모델 설정으로 gpt5.5까지 쓸 수 있지만 gpt5.6 계열은 현재 작동하지 않음. 새로운 진입장벽 확대 동작을 만족하도록 reasoning_effort를 none으로 강제하지 않기 때문으로 추정함

    • 여기서 말한 MCTS 기법이 정확히 무엇인지 궁금함. 어차피 제공되는 사고 과정은 지나치게 추상적으로 요약돼 별 쓸모가 없는데, 정말 추론 절차를 완전히 통제할 수 있는지도 의문임
    • MCTS는 몬테카를로 트리 탐색(Monte Carlo Tree Search)의 약자임
    • 여기서 MCTS를 유행어처럼 남용하지 않았으면 함. 가리키는 방식은 엄밀한 의미에서 MCTS가 아님
    • Responses API는 Chat Completions보다 많은 이점을 제공함: https://developers.openai.com/api/docs/guides/migrate-to-res...
      요즘 나오는 신규 모델은 모두 추론 모델이므로 권장 사항에 따라 Responses API를 사용해야 함

  • GPT 구독을 대체 실행 도구에서 사용하지 못하게 막을지도 궁금함. 그러지 않는다면 큰 문제는 아니며, codex cli 자체는 놀랄 만큼 평범한 실행 도구임

    • 그럴 가능성은 작아 보임. 전체 app-server 구조가 바로 그런 연동을 지원하려고 존재하므로 Codex에서 제거하려면 엄청난 부분을 뜯어내야 함
      나도 app-server의 RPC API로 매우 쉽게 연동할 수 있어서 Codex를 가장 많이 쓰며, 이제는 공개된 Codex TUI보다 직접 만든 연동을 통해 거의 전부 사용함
      하지만 로컬 디스크의 실제 추론 입력인 프롬프트 등을 암호화해 OpenAI 백엔드만 볼 수 있게 한다면, 연동이 쉬워도 무슨 일이 벌어지는지 파악할 수 없게 됨. 팀이 왜 이를 좋은 선택이라 여겼는지 이해하기 어려움
    • Anthropic과 Google은 자체 실행 도구를 쓰면 이미 추가 요금을 받으며, 이것이 OpenAI를 쓰는 이유의 전부임
      OpenAI도 같은 길을 택하면 다시 Claude로 돌아가거나 Spark를 하나 더 사서 로컬에서 실행할 생각임
    • Anthropic이 기업 도입에서 앞서는 동안에는 막지 않을 듯함. OpenAI가 큰 격차로 선두에 서면 어떻게 바뀔지 모르지만, 그때쯤에는 공개 모델이 gpt-5.6 sol보다 더 좋아지길 바람
    • Codex 자체가 구독을 감싸는 프록시를 제공하기 시작했으므로 막을 가능성은 작아 보임
      https://github.com/openai/codex/blob/main/codex-rs/responses...
    • 최근 OpenAI의 Tibo가 Twitter에서 Claude Code로 GPT를 실행하는 방법을 공유해 달라고 요청했으므로, 대체 실행 도구 사용에 반대하는 것 같지는 않음

  • 이전 HN 제목은 암호문을 대상으로 직접 추론하는 것처럼 들려 매우 오해를 불렀음. 그러려면 현재 알려진 수준보다 훨씬 발전한 동형 암호가 필요함

    • 실제로는 에이전트가 하위 에이전트에 보내는 내용을 암호화해 OpenAI 백엔드만 평문을 볼 수 있게 한 것임
      예전에는 에이전트가 하위 에이전트에 평문 프롬프트를 보내고 로그와 세션 데이터에도 그대로 남았기 때문에, 실험적 하위 에이전트 기능을 쓸 때도 데이터를 열어 내부 동작을 확인할 수 있었음
      이제 Sol이나 Terra를 사용하면 백엔드가 만든 암호문을 하위 에이전트에 전달하고, 하위 에이전트는 이를 다시 OpenAI 백엔드의 추론에 사용함. Luna는 영향받지 않는 듯하며, 전체 세션이 아니라 위임된 에이전트 간 메시지만 암호화됨
      OpenAI 내부 추론이 암호문 위에서 이뤄지는 것은 아니지만 로컬 사용자에게는 평문 대신 암호문만 보임. 이를 명확히 하려고 제목을 “Codex starts encrypting sub-agent prompts”로 바꿨음
    • 제목에 “inferencing”가 들어가 있어 나도 즉시 동형 암호나 암호문 연산을 떠올렸음

  • 최근 GPT-5.6 하위 에이전트가 실수로 사용자의 홈 디렉터리를 삭제했다는 보고가 Twitter에 있었음
    하위 에이전트가 무엇을 하려는지 볼 수 없게 되면서 안전장치까지 실패한 것은 아닌지 궁금함
    https://x.com/mattshumer_/status/2076794038456385546?s=20

  • 이는 토큰 사용량을 줄이려고 클라이언트를 거쳐 캐시 키를 전달하는 방식임. 다른 하위 작업 도구를 쓰면 쉽게 우회할 수 있으므로 모델 증류 방어책일 리는 없음

  • 정확히 어디에서 암호화가 이뤄지는지 궁금함. 주 에이전트가 로컬에서 하위 에이전트를 호출한다고 생각했는데, Codex는 로컬에 도달하기 전에 OpenAI 서버에서 하위 에이전트를 호출하는 구조인지 의문임

    • 기존에는 에이전트가 하위 에이전트에 평문 프롬프트를 보냈고 로그와 세션 데이터에도 그대로 남아 내부 동작을 쉽게 살펴볼 수 있었음
      Sol이나 Terra에서는 OpenAI 백엔드가 생성한 암호문을 프롬프트 대신 전달하고, 하위 에이전트가 이를 다시 백엔드 추론에 사용함. Luna는 영향받지 않는 듯하며 전체 세션이 아니라 위임된 에이전트 간 메시지만 암호화되므로, 이제 해당 내용은 OpenAI 백엔드만 복호화할 수 있음

  • 중국 암시장 재판매 서비스가 어제부터 왜 작동하지 않았는지 궁금했는데, 아마 이 변화 때문인 듯함

    • 이런 암시장은 구독을 모아 재판매할 뿐 아니라 데이터를 저장했다가 모델을 훈련하는 곳에도 판매함. 암호화는 후자의 행위만이라도 막는 데 유용하며, 앞서 드러난 다른 수법과 목적은 같지만 구현은 훨씬 깔끔함

  • 대량의 사용자 요청과 응답을 프록시해 경쟁 모델 훈련에 활용하려는 시도를 방해하는 것이 주된 목적으로 보임

    • 다른 공급자가 OpenAI의 다중 에이전트 관리 방식을 들여다보는 것을 막으려는 의도가 분명해 보임
      하지만 유료 사용자는 문제가 생겨도 원인을 알아낼 방법이 전혀 없어 다중 에이전트 기능을 제대로 쓰기 어려운 형편없는 구현임
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.