Codex 서브 에이전트 프롬프트가 암호화됨: 이것이 멀티 에이전트 디버깅을 방해하는 이유

**Codex 서브 에이전트 프롬프트 (Codex sub-agent prompts)**가 실제 디버깅 문제를 일으키고 있습니다. 만약 당신이 Codex 멀티 에이전트 디버깅 (Codex multi-agent debugging), 암호화된 프롬프트 (encrypted prompts), 또는 왜 서브 에이전트에게 전달된 내용을 볼 수 없는지에 대해 검색하고 있다면, 짧고 잔혹한 답변은 다음과 같습니다: 전달 경로(delivery path)는 암호문(ciphertext)을 보존할 수 있지만, 로컬 히스토리(local history)는 읽을 수 있는 작업 내용을 잃어버린다는 것입니다.

이것은 관찰 가능성 (observability)이 아닙니다. 그것은 진행 표시줄이 달린 블랙박스 (black box)일 뿐입니다.

현재 열려 있는 Codex 이슈 (Codex issue)에 따르면, MultiAgentV2는 spawn_agent, send_message, followup_task에 대한 페이로드 (payloads)를 암호화합니다. 해당 이슈는 읽을 수 있는 content 필드는 비어 있는 상태로 남겨두는 반면, encrypted_content가 메시지를 전달한다고 명시합니다. 그 결과: 롤아웃 (rollout)을 검토하는 사람은 위임이 발생했다는 것은 볼 수 있지만, 부모 에이전트가 실제로 무엇을 위임했는지는 반드시 알 수 있는 것은 아닙니다.

Codex 서브 에이전트 프롬프트에 무슨 일이 일어나고 있는가?

먼저, 오해의 소지가 있는 해석을 바로잡겠습니다: 이것은 동형 암호 (homomorphic encryption) 상에서의 추론 (inference)이 아닙니다. Hacker News의 토론에서는 에이전트 간 메시지의 암호화된 전송/저장 (encrypted transport/storage)과 암호문 상에서의 모델 추론 (model inference on ciphertext)을 정확히 구분하고 있습니다. 보고된 우려는 더 좁고 운영상 더 위험합니다:

1. 부모 에이전트가 작업을 위임합니다.
2. 위임된 메시지는 암호화된 콘텐츠로 표현됩니다.
3. 로컬 롤아웃 (local rollout), 재생 (replay), 그리고 감사 (audit) 인터페이스에는 더 이상 읽을 수 있는 작업 텍스트가 남아 있지 않습니다.
4. 엔지니어가 실패한 결과를 받았을 때, 첫 번째 사고 대응 질문에 답할 수 없게 됩니다: 에이전트에게 무엇을 하라고 요청했는가?

이 이슈는 해당 동작의 원인을 MultiAgentV2 프로토콜 및 핸들러 (handlers)로 추적하며, 영향을 받는 작업으로 spawn_agent, send_message, followup_task를 식별합니다. 이는 MultiAgentV2 암호화 작업 이후, MultiAgentV2가 활성화된 빌드에서 나타나는 변화라고 설명합니다.

왜 암호화된 프롬프트가 Codex 멀티 에이전트 디버깅을 방해하는가

암호화 자체가 버그는 아닙니다. 운영자가 볼 수 있는 감사 기록 (audit record)을 삭제하거나—지속시키지 못하는 것—이 바로 버그입니다.

멀티 에이전트 시스템 (multi-agent system)은 더 많은 무작위성 (randomness)과 더 열악한 사후 분석 (postmortems)을 동반하는 분산 시스템 (distributed system)입니다. 단순히 최종 노드 (final node)의 출력값뿐만 아니라, 위임 엣지 (delegation edge)를 검사해야 합니다. 그렇지 않으면 다음과 같은 일상적인 질문들이 추측의 영역으로 넘어가게 됩니다:

• 플래너 (planner)가 리뷰어 (reviewer)에게 올바른 저장소 (repository), 제약 조건 (constraints), 그리고 수락 기준 (acceptance criteria)을 전달했는가?
• 후속 작업 (follow-up)이 원래의 작업을 덮어썼거나 잘못된 에이전트 (agent)를 대상으로 했는가?
• 워커 (worker)가 도구 (tools), 컨텍스트 (context), 또는 잘못 형성된 작업 (malformed task) 때문에 실패했는가?
• 모델 (model), 도구 스키마 (tool schema), 또는 프롬프트 (prompt)가 변경된 후에도 실패를 재현할 수 있는가?

위임된 작업 (delegated task) 없이는 잘못된 계획 (bad plan)과 잘못된 실행 (bad execution)을 구분할 수 없습니다. 이는 텔레메트리 (telemetry) 모양만 갖춘 연극에 불과합니다.

이 보고서는 현재 모델 경로의 사용자들이 이를 비활성화하려는 설정에도 불구하고 v2 동작을 강제당할 수 있다고 언급합니다. 이는 보편적인 보증이 아닌, 검증되지 않은 환경 특정적 (environment-specific) 보고로 취급해야 합니다. 하지만 이는 실제 엔지니어링 리스크를 강조합니다. 워크플로 (workflow)가 위임 (delegation)에 의존할 때, 관측성 (observability)은 우연히 켜지는 기능 플래그 (feature flag)여서는 안 됩니다.

올바른 설계: 암호화된 전달, 읽기 가능한 로컬 감사

해결책은 "모든 것을 평문 (plaintext)으로 보내는 것"이 아닙니다. 그것은 이중 기록 계약 (dual-record contract)입니다:

recipient delivery record
  encrypted_message: ciphertext

...

자식 (child)은 암호화된 전달 페이로드 (encrypted delivery payload)를 받습니다. 운영자 (operator)는 로컬 롤아웃 (local rollout) 및 트레이스 (trace)에서 별도의 제한된 평문 감사 사본 (plaintext audit copy)을 받습니다. 메시지 상관관계 (message correlation)를 위해 평문 일치 (plaintext equality)를 사용하지 마십시오. 메시지 ID (message ID) 또는 암호문 유도 식별자 (ciphertext-derived identity)를 사용하십시오. 읽기 가능한 콘텐츠로 표시된 UI 필드에 암호문 (ciphertext)을 조용히 대체하여 넣지 마십시오.

이 패턴은 중요한 두 가지 속성을 모두 제공합니다:

• 기밀성 경계 (Confidentiality boundary): 수신자 대상 경로는 암호화된 상태를 유지합니다.
• 운영 책임성 (Operational accountability): 워크플로의 소유자는 자신의 시스템이 무엇을 위임했는지 검사할 수 있습니다.

이 이슈는 정확히 이러한 형태를 제안합니다: 암호화된 전달 방식은 유지하되, 평문(plaintext) 감사 동반자(audit companion)를 추가하고, 이것이 비어 있지 않음을 검증하며, 롤아웃(rollout)/이력(history)/추적(trace) 인터페이스를 통해 이를 유지하는 것입니다. 또한 이는 변경 사항의 spawn_agent 측면에 대한 프로토타입과도 연결됩니다.

오늘날 관찰 가능한 멀티 에이전트 시스템을 실행하는 방법

여러분의 프레임워크가 감사 동작을 입증하기 전까지는, 직접 감사 경계(audit edge)를 구축하십시오.

1. 발송 전 위임 사항을 기록하십시오

작업이 에이전트 경계를 넘기 전에 불변(immutable) 이벤트를 작성하십시오:

{
  "event": "agent.delegated",
  "run_id": "run_8f2c",
...

비밀 정보는 삭제(Redact)하십시오. 페이로드(payload)의 범위를 제한하십시오. 기록을 나머지 실행 데이터와 동일한 보존 및 액세스 제어 도메인에 유지하십시오. 하지만 반드시 기록하십시오.

2. 작업 ID(task IDs)를 일급 객체(first-class)로 만드십시오

모든 서브 에이전트 결과는 정확히 위임된 작업 ID를 가리켜야 합니다. "검토자 완료"는 쓸모가 없습니다. "검토자가 task_184를 완료했으며, 커밋 abc123을 생성했고, 도구 호출(tool calls) X/Y/Z를 소비함"은 디버깅이 가능합니다.

3. 정답뿐만 아니라 추적(trace)을 테스트하십시오

통합 테스트(integration test)는 다음 사항을 모두 단언(assert)해야 합니다:

• 자식 에이전트가 의도된 작업을 수신했는가.
• 부모 추적(parent trace)에 읽을 수 있고 권한이 부여된 감사 기록이 포함되어 있는가.
• 수신자 대상 이력(recipient-facing history)에서 감사 기록이 유출되어서는 안 되는 곳에 노출되지 않는가.
• 재현(Replay) 시 작업/결과 관계가 보존되는가.

만약 유일한 단언이 "모델이 그럴듯한 최종 답변을 생성했다"뿐이라면, 당신은 시스템이 아니라 데모를 테스트하고 있는 것입니다.

4. 숨겨진 위임을 릴리스 차단 요소로 취급하십시오

운영 장애가 발생했을 때 "작업자가 어떤 지침을 받았는지 알 수 없다"로 끝날 수 있는 워크플로를 배포하지 마십시오. 이는 릴리스를 차단해야 하는 관찰성(observability) 결함입니다. 특히 저장소를 수정하거나, 마이그레이션(migrations)을 실행하거나, 배포(deploys)를 트리거할 수 있는 코딩 에이전트의 경우 더욱 그렇습니다.

더 날카로운 지점

에이전트 벤더(Agent vendors)들은 당신이 위임(delegation)을 하나의 제품 기능으로 생각하기를 원합니다. 즉, 더 많은 작업자(workers)를 생성하여 더 높은 처리량(throughput)을 얻는 것으로 말이죠. 하지만 엔지니어들은 이를 트레이스 토폴로지(trace topology) 문제로 취급해야 합니다. 모든 위임은 인과 관계의 엣지(causality edge)입니다. 만약 그 엣지를 모호하게 만든다면, 시스템을 디버깅(debug), 평가(evaluate)하고 신뢰(trust)하는 데 필요한 증거를 지워버리는 셈입니다.

Codex는 서브 에이전트(sub-agent) 전달 내용을 암호화하면서도 적절한 로컬 감사 추적(local audit trail)을 제공할 수 있습니다. 이 둘은 상충하는 목표가 아닙니다. 해당 이슈(issue)에서 보고된 구현 방식은 이미 그 계약(contract)의 초안을 보여주고 있습니다. 즉, 암호화된 전달(encrypted delivery)과 제한된 평문 감사 메타데이터(bounded plaintext audit metadata)를 분리하는 것입니다.

그 미만은 프라이버시 엔지니어링(privacy engineering)이 아닙니다. 그것은 관측 가능성(observability)을 외주 준 것에 불과합니다.

Sources

• GitHub issue #28058: encrypted MultiAgentV2 messages remove readable task audit trail
• Hacker News discussion: “Codex starts encrypting sub-agent prompts”
• Referenced Codex encryption change #26210