채널 자격증명 평문 발송 — 반복 실수의 구조와 대책
초록
EROS가 Hermes 키 로테이션 중 새 키를 roops-comm에 두 차례 평문 발송한 사건의 구조적 원인 분석과 재발 방지 대책. 핵심 진단: 규칙을 알고 있는 것과 행동 흐름에 규칙을 게이트로 삽입하는 것은 다르다.
요약
2026-08-04 세션에서 EROS는 같은 실수를 두 번 반복했다. Hermes 키 로테이션 중 새 키 값을 roops-comm(팀 공개 광장)에 평문으로 발송했다. 1차는 즉시 인지해 재로테이션했고, 2차는 Hermes에게 RHMS 키를 안내하는 과정에서 또 발생했다. 이 논문은 왜 같은 실수가 반복됐는지 구조적 원인을 분석하고 재발 방지 대책을 제시한다.
1. 사건 경과
| 시각(UTC) | 사건 |
|---|---|
| ~00:01 | 1차 로테이션 후 새 키 3종을 roops-comm 본문에 포함해 발송 |
| ~00:02 | 즉시 인지 → 사령관 보고 → 2차 재로테이션 완료 |
| ~00:59 | Hermes RHMS 401 보고 수신 → RHMS 재시작 후 2차 키를 roops-comm 본문에 포함해 발송 |
두 사건 모두 feedback_no_creds_in_comm_channels 규칙이 명확히 존재함에도 발생했다.
2. 반복의 구조적 원인
2-1. 과제 집중 터널(Task Focus Tunnel)
실수가 발생한 순간의 인지 상태를 재구성하면:
- 1차: 목표 = "Hermes에게 새 키 전달" → ntfy 발송이 가장 빠른 수단 → 키 값 본문 삽입 → 전송
- 2차: 목표 = "RHMS 401 해결" → Hermes에게 올바른 키 안내 → 동일 패턴 반복
두 경우 모두 "키를 전달한다"는 목표가 "채널에 키 평문 금지"라는 제약보다 인지 전면에 부상했다. 규칙을 모른 것이 아니라, 행동 구성 단계에서 적용하지 않았다.
2-2. 발송 전 검증 단계 부재
ntfy 발송은 메시지 구성 → 즉시 전송의 단일 단계로 처리됐다. 전송 직전에 "본문에 자격증명이 포함됐는가?"를 확인하는 게이트가 없었다.
2-3. 2차 실수의 추가 요인: 1차 학습 미적용
1차 실수 직후 재로테이션까지 완료했음에도, 불과 수십 분 후 같은 패턴을 반복했다. 교정이 행동 변화로 이어지지 않았다.
3. 핵심 통찰
"규칙을 알고 있다"는 "규칙을 적용한다"와 다르다.
규칙이 행동 흐름의 끝이 아닌 중간 게이트로 삽입돼야 한다. ntfy 메시지를 구성하는 순간, "이 본문에 키 값이 있는가?"가 자동으로 떠올라야 한다.
4. 대책
4-1. ntfy 발송 전 자기 점검 프로토콜
ntfy 메시지 구성 후, 전송 명령 작성 전 반드시 확인한다:
□ 본문에 토큰(tk_, 긴 무작위 문자열, API 키)이 포함됐는가?
□ 포함됐다면 → 발송 중단. 키 참조(변수명·경로)로 대체.
4-2. 키 전달의 유일한 안전 경로
| 허용 | 금지 |
|---|---|
| 사령관이 tmux에서 직접 입력 | roops-comm 본문 |
| Memory API /msg | roops-eros 본문 |
| 사령관-에이전트 직접 대화 | 어떤 ntfy 채널이든 본문 |
4-3. 발송 스크립트 자격증명 감지 레이어 (장기)
ntfy 발송 전 패턴 감지: tk_ 접두사, 32자 이상 무작위 문자열. 매칭 시 차단.
5. 결론
실수는 규칙 부재가 아닌 행동 흐름 내 규칙 위치 오류에서 비롯됐다. 가장 중요한 즉각 변화는 단순하다: ntfy 메시지를 구성한 후, 전송 전, 본문을 한 번 읽는다.
작성: EROS / 2026-08-04