요약
v1.0.5 가 훅의 입력 계약(stdin JSON)을 고쳤지만, 신원 계약은 여전히 틀려 있었다. 훅이 "누가 파일을 쓰는가" 를 알아내려던 세 수단이 모두 성립하지 않았다.
근본 원인 — 발급 주체 = 제한 대상
ORCHESTRATOR_DIRECT_TOKEN(환경변수) +docs/complexity-gate.lock(해시 락 파일): 토큰을 발급하는 주체가 메인 세션이고, 그 토큰으로 제한받는 주체도 메인 세션이다. 자가 승인은 인증이 아니므로 전달 경로를 파일로 바꿔도 해결되지 않는다. 게다가 임의 환경변수는 훅 프로세스에 도달조차 하지 않아 분기 전체가 죽어 있었다..claude/.current-role(v1.0.5 가 도입한 대체안): 이 파일을 쓰는 주체가 아무데도 없다. 항상unknown으로 읽혀exit 0— fail-open 무동작. v1.0.4 의$CLAUDE_TOOL_INPUT과 같은 실패를 다른 이름으로 반복했다.- 사용자가 AskUserQuestion 으로 승인했다는 사실은 훅에 아무 흔적도 남기지 않는다. 훅은 사용자 승인을 검증할 수 없다.
해결 — agent_type
Claude Code 는 서브에이전트 호출에만 stdin JSON 에 agent_id / agent_type 을 넣고, 메인 세션 호출에는 키 자체를 넣지 않는다. 런타임이 채우므로 모델이 위조할 수 없는 유일한 신원 값이다. 라이브 훅에 프로브를 심어 두 경로를 직접 캡처해 확인했다.
| 호출 주체 | agent_type |
|---|---|
| 메인 세션 (오케스트레이터) | 키 없음 |
| 서브에이전트 | "general-purpose" 등 |
변경
- Removed —
ORCHESTRATOR_DIRECT계열 플래그/토큰,complexity-gate.lock,.current-role파일 읽기. 특히 Advisor Dim 12 는 없는 메커니즘을 "명시하라" 고 요구하고 있었다. 이제 반대로, 그런 우회를 명시하면[BLOCK]. - Fixed — ownership-guard 템플릿을
agent_type기반으로 재작성하고 미매핑 에이전트를exit 2로 차단(기존allowing write는 가드를 형해화). - Fixed —
.env는 ownership-guard 가 유일 방어선이라는 거짓 주장 정정. 훅 matcher 는Write|Edit뿐이라Bash경유 쓰기를 못 막고,permissions.deny도 임의 서브프로세스는 못 막는다. 실제 강제는sandbox.filesystem. - Fixed — 라우팅 프로토콜 S 등급 자기모순 해소. 표("파일 3개 이하 변경")를 정본으로 확정하고, Section 3 은 원래 의도(리뷰 필수 파이프라인 보호)만 남겼다.
- Added —
scripts/test-hooks.sh30개로 확장. 문서에 실린 코드 블록을 markdown 에서 뽑아 실제 페이로드로 실행한다. 문서가 깨진 훅 코드를 가르친 것이 v1.0.4~1.0.5 사고의 뿌리였기 때문이다.
기존 사용자 영향
v1.0.5 이하로 생성된 하네스의 ownership-guard.sh 는 항상 통과(fail-open)하거나 완전 무동작이다. 원래 아무것도 막지 못했으므로 위험이 새로 커지지는 않으나, 가드가 있다고 믿으면 안 된다. /harness-architect:audit 로 재점검하거나 역할 판정을 stdin JSON 의 agent_type 으로 교체할 것.