Codex 서브 에이전트 프롬프트가 암호화되었습니다—그렇다면 당신의 디버깅 흔적은 어디로 갔을까요?

Codex 서브 에이전트 프롬프트 (Codex sub-agent prompts), 암호화된 프롬프트 (encrypted prompts), 그리고 Codex MultiAgentV2가 이제 까다로운 엔지니어링 문제와 충돌하고 있습니다: 감사 추적 (audit trail)을 삭제하지 않으면서 어떻게 에이전트 메시지를 보호할 것인가? 그 답은 암호화를 끄는 것이 아닙니다. 암호화된 전달 방식을 유지하되, 제한된 범위 내의 사람이 읽을 수 있는 로컬 감사 기록을 별도로 저장하는 것입니다.

이러한 구분은 당연해 보입니다. 하지만 초기 구현 단계에서는 이 구분이 유지되지 않았습니다.

Codex가 서브 에이전트 프롬프트를 암호화한다는 내용의 Hacker News 기사가 오늘 빠르게 확산되었습니다 (확인 당시 218 포인트 및 138개 댓글). 근본적인 보고 내용은 헤드라인보다 더 정밀하며 더 유용합니다. 즉, Codex의 MultiAgentV2 경로에 적용된 암호화 변경 사항으로 인해 위임된 작업 및 메시지 내용이 히스토리와 트레이스 (traces)에서 불투명해질 수 있다는 것입니다. 이것은 디버깅 퇴보 (debugging regression)이지, 암호화된 에이전트 간 통신을 포기해야 할 이유는 아닙니다.

Codex 서브 에이전트 프롬프트에 무슨 일이 일어났나요?

Codex issue #28058에 따르면, 이 동작은 2026년 6월 5일에 병합된 MultiAgentV2 암호화 변경 사항이 포함된 빌드에서 MultiAgentV2가 활성화되었을 때 영향을 미칩니다 (보고서에는 0.137.0 이후 버전으로 설명됨).

보고된 흐름은 매우 단순합니다:

1. 부모 에이전트가 작업을 위임하거나 후속 조치를 보냅니다.
2. 모델을 향한 message 페이로드 (payload)가 암호화됩니다.
3. 암호화된 값이 encrypted_content로 저장됩니다.
4. 일반적인 content 필드는 비어 있는 상태로 남습니다.
5. 나중에 배포/히스토리/로그 경로에서 엔지니어가 위임된 명령어를 기대하는 위치에 암호문 (ciphertext)이 나타납니다.

암호화는 제 역할을 수행했습니다: 수신 모델 경로로 보호된 페이로드가 전달됩니다. 하지만 관찰 가능성 (observability)은 무력화되었습니다: _“우리가 이 서브 에이전트에게 정확히 무엇을 하라고 요청했는가?”_라는 질문에 답하려는 사람은 읽을 수 있는 답변을 얻지 못하게 됩니다.

암호화된 프롬프트가 버그가 아닌 이유

정확히 짚고 넘어갑시다. 에이전트 간 트래픽 (agent-to-agent traffic)을 암호화하는 것은 합리적인 프라이버시 경계 (privacy boundary)가 될 수 있습니다. 위임된 작업에는 저장소 컨텍스트 (repository context), 고객 데이터, 인시던트 노트 (incident notes), 또는 모든 모델 접점 (model-facing surface)을 통해 무분별하게 복제되기를 원치 않는 지침 등이 포함될 수 있기 때문입니다.

나쁜 설계는 전달용 표현 (delivery representation)을 유일한 표현 방식으로 취급하는 것입니다.

암호문 블롭 (ciphertext blob)은 운송 산출물 (transport artifact)로서는 괜찮습니다. 하지만 운영 기록 (operational record)으로서는 최악입니다.

에이전트 시스템이 실패했을 때, 당신은 다음과 같은 결정 체인 (chain of decisions)을 재구성해야 합니다:

• 어떤 에이전트에게 작업이 할당되었는가?
• 무엇을 조사하라고 지시받았는가?
• 후속 지침 (follow-up instruction)이 잘못 형성되었는가?
• 재시도 (retry) 후에 작업이 확장되었는가?
• 어떤 메시지가 잘못된 변경을 일으켰는가?

만약 당신의 트레이스 뷰어 (trace viewer)가 이 모든 질문에 대해 불투명한 페이로드 (opaque payloads)로 답한다면, 당신은 보안이 강화된 블랙박스를 만든 것입니다. 축하합니다. 공격자뿐만 아니라 당신의 온콜 엔지니어 (on-call engineer)에게도 조사하기가 똑같이 어려워졌군요.

암호화된 전달과 읽기 가능한 감사 추적 (audit trail)을 유지하는 방법

이 이슈는 올바른 아키텍처를 제안합니다. 메시지를 의도적으로 서로 다른 두 개의 필드로 분리하는 것입니다.

transport_message: 수신 모델을 위한 암호화된 암호문 (encrypted ciphertext)
message_text: 로컬 히스토리를 위한 제한된 평문 감사 메타데이터 (bounded plaintext audit metadata)

소스 리포트 (source report)는 전달을 위해 암호화된 message를 유지하되, spawn_agent를 위한 task_message나 send_message / followup_task를 위한 message_text와 같이 필수적인 평문 동반 항목을 추가할 것을 제안합니다.

이것이 모든 멀티 에이전트 프레임워크 (multi-agent framework)가 명시적으로 정의해야 할 계약 (contract)입니다:

운영 트레이스 (production traces)를 복호화하여 나중에 감사 기록을 도출하지 마십시오. 그렇게 하면 모든 트레이스 뷰어가 복호화 클라이언트 (decryption client)로 변하게 되고 폭발 반경 (blast radius)이 확장됩니다. 평문이 여전히 존재하는 핸들러 경계 (handler boundary)에서 감사 메타데이터를 작성하십시오. 그리고 그 저장, 액세스 제어 (access controls), 보존 (retention), 그리고 비식별화 (redaction)를 최우선 보안 고려 사항 (first-class security concerns)으로 보호하십시오.

Codex MultiAgentV2를 안전하게 디버깅하는 방법

만약 귀하의 Codex 실행이 MultiAgentV2를 사용한다면, 계약(contract)의 양측을 모두 테스트하십시오. 에이전트 실행이 통과되었다는 사실만으로는 충분하지 않습니다.

1. 위임된 작업 캡처 (Capture a delegated task)

다음 세 가지 작업을 모두 수행하는 실행(run)을 생성하십시오:

spawn_agent("inspect the auth retry bug")
send_message(child, "focus on the token refresh branch")
followup_task(child, "add a regression test")

2. 수신자 경로가 암호화되었는지 확인 (Assert the recipient path is encrypted)

수신자 모델 입력(recipient model input)에는 감사 사본(audit copy)이 아닌 암호화된 전송 값(encrypted transport value)이 포함되어야 합니다. 만약 로컬 감사 필드(local audit field)가 모델 입력으로 유출된다면, 귀하가 방금 구축했다고 주장한 경계(boundary)를 스스로 무너뜨린 것입니다.

3. 기록이 읽기 가능한 상태로 유지되는지 확인 (Assert history stays readable)

귀하의 롤아웃 UI(rollout UI)와 구조화된 로그(structured logs)는 각 작업에 대해 간결한 평문 감사 기록(plaintext audit record)을 보여주어야 합니다. 보고서에 따르면, 변환/지속성 경로(conversion/persistence path)가 여전히 암호화된 버전을 방출한다면, 단순히 런타임 content를 채우는 것만으로는 충분하지 않습니다.

4. 감사 텍스트에 엄격한 제한 설정 (Put a hard cap on audit text)

감사 필드(Audit fields)는 무제한의 컨텍스트 윈도우(context window)를 로그로 복사하기 위한 변명이 될 수 없습니다. 해당 위임된 메시지(delegated message)와 동일하거나 더 엄격한 크기 제한을 적용하십시오. 지속성(persistence) 단계 이전에 알려진 비밀 정보(secrets)를 삭제(Redact)하십시오.

5. 실패 사례 테스트 (Test the failure case)

회귀 테스트(regression test)는 다음 두 가지 속성을 동시에 증명해야 합니다:

assert recipient_input.message == encrypted_payload
assert rollout_event.message_content == readable_audit_text
assert rollout_event.message_content != encrypted_payload

세 번째 단언(assertion)이 중요합니다. 그렇지 않으면 누군가는 안심할 수 있는 이름을 가진 필드에 암호문(ciphertext)을 쏟아부음으로써 관찰 가능성(observability)을 "수정"해 버릴 것입니다.

엔지니어링 규칙: 보안 경계에는 관찰 가능성 경계가 필요하다

업계는 에이전트가 더 많은 작업을 위임하도록 서두르고 있습니다. 이는 에이전트 간 메시지(inter-agent messages)를 구현 세부 사항(implementation detail)이 아닌 인프라(infrastructure)로 만듭니다. 인프라는 다음 두 가지를 동시에 필요로 합니다:

• 전송 및 모델 입력을 위한 기밀성 모델 (confidentiality model);
• 시스템을 디버깅해야 하는 운영자를 위한 관찰 가능성 모델 (observability model).

하나가 다른 하나의 우연한 부작용(accidental side effect)이 되어서는 안 됩니다.

이 설계의 건전한 버전은 별도의 보존(retention) 및 액세스 정책(access policies)을 가집니다. 수신 모델(recipient model)은 수명이 짧은 작업을 위해 암호문 페이로드(ciphertext payload)가 필요할 수 있습니다. 감사자(auditor)는 더 긴 기간 동안 편집된 요약본(redacted summary)이 필요할 수 있습니다. 사고 대응자(incident responder)는 더 완전한 로컬 메타데이터에 대한 특권 액세스(privileged access)가 필요할 수 있습니다. 이들은 서로 다른 요구사항을 가진 서로 다른 행위자들입니다. 이들을 하나의 message 필드로 통합하는 것이 바로 시스템을 추론 불가능하게 만드는 방식입니다.

결론 (Bottom line)

"Codex가 서브 에이전트 프롬프트를 암호화한다"는 클릭을 유도하는 헤드라인일 뿐입니다. 지속 가능한 교훈은 더 날카롭습니다: 전송 보안(transport-security) 업그레이드가 시스템 운영에 필요한 증거를 조용히 삭제하도록 절대 내버려 두지 마십시오.

전송 페이로드(delivery payload)는 암호화된 상태로 유지하십시오. 제한된 범위 내에서 액세스 제어가 가능하고 사람이 읽을 수 있는 감사 사본(audit copy)을 로컬에 영구 저장하십시오. 두 경로를 모두 테스트하십시오. 그 미만은 그저 느낌(vibes)에 의존하는 에이전트 오케스트레이션(agent orchestration)일 뿐입니다.

출처 (Sources)

• Hacker News: “Codex starts encrypting sub-agent prompts”
• OpenAI Codex issue #28058: Regression: encrypted MultiAgentV2 messages remove readable task audit trail
• Encryption change referenced by the report: Codex PR #26210