Claude Code가 Context compaction을 통해 .env 파일을 읽어버림

로컬 에이전트가 외부 프로덕션 데이터에 접근해야 할 때는 어떡함?

난 logQL이랑 데이터베이스 mcp용 읽기 전용 프록시를 씀. 수동으로 추적하는 건 이제 너무 구식인 것 같음.

그럼. 할 수 있어.

네가 세운 계층은 맞지만, Deny 규칙은 가장 신뢰가 안 감. Bash는 네가 나열하지 않은 명령어로도 파일에 접근할 수 있으니까. 실제로 효과가 있는 계층은 Claude가 실행되는 계정에서 비밀값을 읽을 수 없게 하는 거야. 진짜 키는 프로젝트 밖에 두고 다른 사용자나 OS 키체인이 소유하게 한 뒤, 앱이 런타임에 로드하게 해. 그러면 compaction이나 영리한 grep을 써도 플레이스홀더밖에 못 찾음. 이미 전용 PC를 쓰고 있으니까, 개발용 키만 두고 사용 한도를 걸어두면 유출돼도 키 교체 비용만 들고 돈이 나가지는 않을 거임.

계층은 탄탄하고, '접근할 수 없는 다른 폴더'를 쓰는 게 진짜 해결책임. Deny 규칙이랑 훅은 안전장치일 뿐, 실제로 안전한 건 에이전트 사용자가 비밀값을 아예 읽을 수 없는 것뿐임. 두 가지 더 추가하자면: 개발용 키는 스코프를 제한하고 한도를 낮게 설정해서 유출 시 피해를 최소화하고, 에이전트가 세션에서 이미 본 건 다 로테이션해. 그리고 예전 대화나 로그에도 키가 남아있는지 확인해, 그것들도 다시 읽히니까.

Varlock

난 Claude Code를 아주 편안한 전용 Docker 컨테이너에 가둬버렸음. 거기서는 Claude가 내 솔루션을 설정하고 실행하는 데 필요한 경우가 아니라면 .env 변수 같은 걸 읽거나 접근할 이유가 전혀 없음. 설정도 쉬웠음. 이제 마음 편하게 오토 모드로 Claude Code를 쓸 수 있고 강력 추천함. 규칙을 훅, 가드, githooks로 보강하고 MD 파일은 당면한 작업에 가장 중요한 것만 남겨둬.

분위기 파괴자

순서는 대체로 맞는데, deny 규칙을 위로 올리는 게 좋겠어. 이건 모델에 대한 지시사항이 아니라 harness가 강제하는 권한 규칙이니까. 취약점은 Bash 패턴이야. python -c나 인코딩된 명령어는 패턴 목록을 그냥 빠져나가거든. Hook 차단 목록도 같은 문제가 있고, 내 hook은 fail open 방식이라 스크립트가 죽으면 Claude가 그냥 평소대로 작동해 버려. 그래서 난 hook을 안전벨트 정도로만 생각해. 진짜 보호책은 프로젝트 폴더 밖에서 secret을 관리하고 계획한 대로 제한된 사용자 계정으로 실행하는 거야. 한 가지, 이 방법들로도 해결 안 되는 게 있는데, 이미 세션에 키가 노출됐다면 무조건 키를 교체해.

왜 Claude가 키를 읽는 걸 걱정하는지 모르겠네. Anthropic은 네 키를 원하는 게 아니라 그냥 고객을 원하는 건데.