매일 기록한 AI 기록

Claude Code 훅이 등록돼 있는데 왜 로컬 명령을 못 막을까? 등록 여부, matcher, 스크립트의 조기 종료 조건을 따로 봐야 한다. 이 글은 직접 만든 원격 전용 훅이 로컬에서는 검사를 건너뛴 사례다. Claude Code 전체가 삭제 명령을 허용한다는 뜻도, 모든 deny 규칙이 무효라는 뜻도 아니다. 작성자: 닥터조지. 측정 시점: 2026-08-02 로컬 세션 / 편집 보완: 2026-09-23. 당시 CLI 버전은 이 글에 기록되어 있지 않다. 새 버전에서 재실행한 결과가 아니며, 아래 절차는 독자의 환경을 따로 확인하기 위한 점검 순서다. 훅 미작동을 구분하는 점검 순서 CLI 버전, 로컬·원격 여부, 실제로 읽힌 설정 파일을 기록한다. 사용자 설정과 프로젝트 설정을 혼동하지 않는다. PreToolUse 의 matcher가 검사하려는 도구와 일치하는지, 실행할 스크립트 경로가 맞는지 확인한다. 스크립트의 앞부분과 모든 조기 종료 조건을 읽는다. 원격 전용 환경변수가 없을 때 exit 0 이면 등록돼 있어도 해당 경로를 검사하지 않는다. 삭제·외부 전송·실제 비밀 읽기를 하지 않는 확인 명령을 골라, 평소 사용하는 Claude Code 세션에서 한 건만 요청한다. 일반 터미널에서 명령만 실행하는 것은 Claude Code 권한 검사 시험이 아니다. 요청한 도구·명령, 훅 로그, 차단 메시지, 종료 상태를 함께 남긴다. 훅 단독 호출 결과와 Claude Code 전체 경로의 결과를 다른 칸에 기록한다. 차단 주체를 구분할 수 없으면 미확인으로 남긴다. 기대 결과는 단순히 “막힘”이 아니라 어느 설정·어느 훅이 그 요청을 처리했는지 추적 가능한 기록 이다. xargs --version 지원 여부는 운영체제의 구현에 따라 다르다. 옵션 오류가 나더라도 권한 차단과 실행 후 오류를 구분해야 한다. 과거 시험의 chmod 777 을 실제 작업 파일에 따라 하지 않는다. 현재 설정 형식의 기준은 Claude Code 공식 Ho...

AI 코딩 에이전트는 .env를 읽는다 — OpenAI도 10개월째 못 막은 문제 AI 코딩 에이전트한테 저장소를 통째로 맡기는 사람이 늘었다. 그런데 그 저장소 안에는 보통 .env 가 같이 들어 있다. 내 경우엔 시크릿이 새는 걸 막는 보안 훅이 오타 하나로 몇 달간 돌지 않고 있었다. 그동안 에이전트가 키 파일을 읽어도 걸러낼 장치가 없었다는 뜻이다. 결론부터 적으면, .gitignore 로는 에이전트한테 시크릿을 숨기지 못한다. 막아야 할 지점은 파일이 아니라 도구 호출이다. 이 글은 그 이유를 OpenAI Codex의 공개 이슈 하나로 짚고, 내 설정에서 .env 가 읽히는지 확인하는 법까지 정리한다. AI 코딩 에이전트 보안에서 가장 자주 새는 구멍이 여기다. 다음 중 하나라도 해당되나 .env 를 .gitignore 에 넣었으니 안전하다고 생각한 적이 있다. 에이전트한테 “이 디렉터리 전체를 분석해줘”라고 시켜 본 적이 있다. API 키나 토큰을 프로젝트 루트의 설정 파일에 그대로 둔 적이 있다. 셋 중 하나라도 해당되면 이 글이 짚는 위험에 노출돼 있다. 왜 그런지는 에이전트가 파일을 읽는 방식을 보면 바로 드러난다. 에이전트가 파일을 읽는 방식 깃과 에이전트는 파일을 보는 길이 다르다. .gitignore 는 git add 단계에서만 작동한다. 깃이 추적하지 않을 파일을 지정할 뿐이다. 반면 코딩 에이전트는 깃을 거치지 않는다. rg (ripgrep)나 grep , cat 같은 도구를 직접 호출해서 파일 시스템을 읽는다. 에이전트 입장에서 .env 는 그냥 텍스트 파일 하나일 뿐이고, 깃이 무시하든 말든 상관이 없다. 그래서 “민감 파일을 .gitignore 에 넣어 뒀으니 에이전트도 안 읽겠지”라는 가정이 깨진다. 에이전트가 코드 검색을 하다가 .env 안의 문자열이 검색어에 걸리면, 그 내용은 도구 출력으로 모델에 전달된다. 모델에 전달된다는 건 외부 서버로 전송된다는 뜻이다. 핵심은 차단 지점이다. 파일에...

같은 달, 같은 Mozilla — 두 문서 숫자가 90배 다르다 “Mythos가 Firefox에서 취약점 271개를 찾아 고쳤다”는 Mozilla 공식 블로그 문장과, “Firefox 150 보안 어드바이저리에 CVE 40개, 그중 Anthropic 크레딧은 3개”라는 같은 Mozilla의 공식 집계가 같은 4월에 나왔다. 둘 다 공개돼 있다. 271을 먼저 들으면 놀랍다. 같은 릴리즈 어드바이저리의 CVE 40개는 이상하다. 그 40개 중 Anthropic 크레딧 3개라는 사실은 두 문서가 서로 다른 것을 세고 있다는 감을 준다. 세 문장 전부 Mozilla가 직접 올린 공식 자료다. 이 글은 AI 보안 리포트를 읽는 독자를 위해, 왜 숫자가 벌어지는지를 공식 자료만으로 대조하고 제시된 설명 가설을 짚는다. 층 1 — Mozilla 블로그의 271이라는 숫자 Mozilla는 2026년 4월 공식 블로그 “The zero-days are numbered”(blog.mozilla.org/en/privacy-security/ai-security-zero-day-vulnerabilities/)에서 Firefox 150이 Claude Mythos Preview로 평가한 뒤 271개 취약점을 수정했다고 적었다. 같은 달 Anthropic이 red.anthropic.com/2026/mythos-preview/에 올린 Mythos 공식 소개는 능력 수치를 제공한다. Firefox 147 JavaScript 엔진 테스트에서, 이전 모델 Opus 4.6은 수백 시도 중 실제 익스플로잇을 2번 만들었다. Mythos는 같은 조건에서 181번, 레지스터 제어(익스플로잇이 실제 실행 제어권을 잡는 단계)까지 간 경우가 29번이었다. 능력 자체는 공식 측정으로 실재한다. 이 수치가 뒤에 있으니 Mozilla의 “271 발견”이 단독으로 나왔을 때 독자 입장에서 반박할 근거가 없어 보인다. 층 2 — 보안 어드바이저리의 40과 3, 그리고 2월의 정합 Firefox ...