저자는 파일 접근 제한, 특히 Claude Code의 PreToolUse 훅과 deny 규칙이 어떻게 작동하는지 조사했습니다. 모델의 컨텍스트에서 파일을 제외하도록 설계된 저자의 PreToolUse 훅은 Read 도구 대신 cat 명령이 사용되었을 때 예상치 못하게 우회되었습니다. 그러나 한 줄의 deny 규칙은 cat 명령을 성공적으로 차단했습니다. 이를 통해 다양한 조건과 Claude Code 버전에서 이러한 제한의 도달 범위를 측정하기 위한 일련의 테스트가 수행되었습니다.테스트 결과, Read에 등록된 PreToolUse 훅은 Bash에서 cat을 통한 파일 접근에 대해 트리거되지 않았지만, Read 도구 자체는 차단되었습니다. 반대로, 권한 deny 규칙은 cat 명령을 차단하는 데 성공했습니다. 두 가지 통제 실험은 중요한 뉘앙스를 드러냈습니다. 단일 파일에 대해 명시된 deny 규칙이 시스템 메시지에서 전체 디렉토리에 적용되는 것으로 잘못 해석되었고, 처음에는 deny 규칙에 의해 차단된 것으로 보였던 Python 스크립트 실행은 실제로 자동 모드 분류기에 의해 중지되었습니다.문서는 deny 규칙이 Claude의 내장 도구 및 인식된 Bash 명령에 적용되지만, 파일을 직접 여는 Python 스크립트와 같은 임의의 서브프로세스에는 적용되지 않는다고 명확히 합니다. 포괄적인 OS 수준 강제를 위해서는 샌드박스가 권장됩니다. Edit 훅을 사용한 유사한 실험에서 sed -i에 의해 우회되었지만 deny 규칙은 이를 차단했습니다.그러나 deny 규칙 자체에도 한계가 있었으며, 쉘 리다이렉션을 통한 파일 수정은 차단하지 못했지만 특정 리다이렉션 하나는 잡아냈습니다. 파일에 쓰는 다른 명령은 차단되지 않고 통과되었습니다. 이는 deny 규칙이 훅보다 더 광범위하지만 완전하지는 않으며, 완전한 파일 접근 제어를 위해서는 OS 계층이 가장 강력한 솔루션임을 시사합니다. 저자는 잠재적인 격차를 식별하기 위해 자신의 설정을 테스트할 것을 강조합니다.