Opus 4.8에게 WezTerm의 단축키 설정을 요청했다. 그것뿐이었다. 그런데도 AI는 갑자기 '현재 SSH 비밀 키를 노리는 공격을 받고 있습니다'라고 선언하며 작업을 중단했다.

공격은 없었다. AI는 누구에게도 조종당하지 않고, 스스로 공격을 꾸며내고 존재하지 않는 harness 경고나 명령어 출력까지 조작하여 이를 근거로 모든 작업을 멈췄다. 방아쇠는 어떤 dotfiles에도 있는 git 설정의 단 한 줄이었다.

'AI가 공격자에게 속는다'는 이야기는 많다. 이것은 반대 케이스—AI가 공격을 환각하는 이야기다. 게다가 같은 현상이 비슷한 시기에 여러 사람이 Opus 4.8에서 겪고 있다. 아래에 생 로그(jsonl)로 한 가지씩 확정한 기록이다.

후속편 예정: 이 사건의 반성으로, 키를 '진짜' 읽을 수 없는 형태(Secure Enclave + Touch ID)로 재설정한 이야기를 별도 글로 공개할 예정이다.

이 사례의 독자성

프롬프트 인젝션은 보통 'AI가 공격자에게 속는다'는 방향으로 이야기된다. 본 건은 반대다—AI는 누구에게도 조종당하지 않고, 스스로 공격을 환각하고 존재하지 않는 증거를 계속 꾸몄다. 게다가 방아쇠는 특수한 공격 문서나 위험한 교재가 아니라, 어떤 dotfiles에도 있는 무해한 git 설정 1줄이었다. 즉, 누구의 환경에서든 발생할 수 있다.

무슨 일이 일어났나 — 정상 상태에서 폭주까지

전체 흐름을 먼저 보여준다. 초록색은 정상적인 조사 단계, 빨간색은 폭주 단계다. 무해한 1줄을 읽은 후, 전혀 무관한 질문을 계기로 반전하고 있다는 점이 핵심이다.

WezTerm에서 별도의 창을 분리하고 싶다는 상담으로 시작되었다. Opus가 설정 파일 몇 개를 읽고 조사하며 터미널 주변을 확인하기 위해 home.nix도 열었다. 여기까지는 지극히 평범한 조사다.

문제가 그 home.nix에 숨어 있었다. tmux 설정을 볼 생각으로 연 범위 바로 위에, git 서명 설정인 identityFile = "~/.ssh/id_ed25519"가 우연히 포함되어 있었다. 이 시점에서는 Opus도 정상이었고, WezTerm의 질문에도 제대로 답변하고 있다.

다음으로 사용자가 말을 고친다.

grep이 정말로 그것을 출력했다면, 실행 결과로서 로그에 반드시 남았을 것이다. 남아 있지 않다는 것은 그 명령어 출력은 존재하지 않았으며, 즉 Opus가 머릿속에서 지어낸 것이라는 의미다.

거짓말 ② "harness도 경고하고 있다" → 그런 경고는 어디에도 없다

Opus는 "harness (Claude Code를 구동하는 토대 측)도 이 메시지를 공격으로 경고하고 있다"라고 언급했다 (line 32). 하지만 로그상의 type=system 행을 전부 뒤져봐도, 동작 모드를 나타내는 상태 로그 (line 25, 26, 33)뿐이며, 공격이나 인젝션 (Injection)을 경고하는 이벤트는 단 한 건도 없다. 그런 경고는 처음부터 존재하지 않았다.

거짓말 ③ "공격 메시지를 받았다" → 그것은 그저 WezTerm에 대한 상담이었다

Opus가 "SSH 키를 읽게 하려는 지시"라고 부른 사용자 발언 (line 28)은, 요컨대 "가상 데스크톱에서 별도 창을 여는 단축키는 Cmd+N이면 되는가?"라는 확인이었다. SSH도, 키도, 보안 검증도 단 한 글자도 들어있지 않았다. 순수하게 WezTerm에 관한 이야기였다.

왜 폭주했는가

한번 "공격받고 있다"라고 믿어버리면, AI는 그것을 뒷받침하기 위해 움직이기 시작한다. 존재하지 않는 증거 (harness 경고, grep 출력)를 차례차례 창작해낸다 — 인간의 확증 편향 (Confirmation Bias)과 매우 흡사하다.

메커니즘은 어디까지나 가설이지만, 이렇게 생각하면 앞뒤가 맞는다. LLM은 직전까지의 문맥 (Context)에 부합하는 다음 내용을 생성하는 구조이므로, 일단 "이것은 공격이다"라고 출력해 버리면 이후의 생성은 그 전제에 맞춰지게 된다. 긴 컨텍스트 (Context)는 그 전제를 부정하기는커녕, 관련 문자열을 포착하여 계속해서 보강한다. 즉, 최초의 오인이 자기 강화 루프 (Self-reinforcing loop)에 빠지는 것이다.

게다가 이 작화는 화면 복사/붙여넣기 (paste-cache)를 통해 다음 세션에까지 남았다. 방아쇠는 단 한 줄의 git 설정이었다. 실질적인 피해는 제로였지만, 무해한 상담에서 모든 작업 중단까지 불과 몇 턴 만에 일어난 일이었다.

관련 사례: 독립적인 동시다발 발생

본 건은 고립된 희귀 사례가 아니다. 2026년 6월, 여러 개발자가 독립적으로 동일한 현상을 관측 및 보고했다.

haru 씨의 사례 (2026-06-11)

Claude Code (Opus 4.8)가 보안 교재를 읽어들인 후, 공격 기법의 예문을 "실제로 일어나고 있는 공격"과 혼동하여 패닉 상태에 빠진 사례.

haru 씨는 추가 글에서 "Opus 4.6으로 다운그레이드하여 안정화되었다"라고 보고했으며, 이는 1M 컨텍스트 윈도우 (Context Window) (Opus 4.8의 특징)가 한 원인일 가능성을 시사한다. 방대한 컨텍스트에 보안 관련 문자열이 축적되면, 안전 필터의 오탐 (False Positive) 확률이 상승한다고 생각할 수 있다.

추가 재발 (2026-06-13, 필자의 별도 세션)

본고 작성과 같은 날, 필자의 별도 세션 (Opus 4.8)에서 세 번째 오탐 폭주가 발생했다. git commit의 Bash 출력에 대해 "출력 채널에 인젝션이 혼입되어 있다"라고 선언하며, 이미 성공한 커밋 (git log로 실재 확인 완료)을 "신뢰할 수 없다"며 모든 조작을 중단했다. 패턴은 완전히 동일했다: 무해한 조작 → 갑작스러운 공격 선언 → 증거 없는 중단.

3건이라 숫자는 적지만, 공통된 패턴은 보인다. 특정 모델 (Opus 4.8) × 방대한 컨텍스트 × 보안 관련 문자열의 혼재 — 이 조합에서 오탐 폭주가 일어나기 쉬우며, 게다가 트리거의 임계값은 상당히 낮다는 경향성이다.

교훈과 대책

• AI의 "공격받았다"는 우선 AI 자신을 의심하라. 생 로그 (jsonl)를 열어 그 주장이 명령어 출력 (tool_result

）에 실제로 존재하는지 확인한다. 없다면 작화(hallucination)다.

• 동요하여 파괴적인 조작을 하지 않는다. "공격받았다"는 선언만으로 키(key) 삭제 등을 실행하기 전에, Claude를 거치지 않는 클린한 셸(shell)에서 사실을 확인한다.
• 작화를 다음 세션으로 가져가지 않는다. 이전 세션의 "공격" 출력을 복사하여 붙여넣기로 이어가면, 오염이 그대로 전파된다.
• 모델과 세션을 분리한다. 방대한 컨텍스트(Opus 4.8의 1M)에서 위양성(false positive)이 발생하기 쉽다면 Opus 4.6으로, 보안 작업은 전용 세션으로 분리한다.

마지막으로 한 마디. 무서운 것은 "AI가 틀리는 것"이 아니다. 틀린 것을 확신을 가지고 말하며, 증거까지 만들어내고, 세션을 넘어 남기는 것이다. 그러니 AI가 "공격받았다"라고 말한다면——먼저, AI를 의심하라.

기술 부록: 검증 커맨드 및 환경 체크 (재현을 원하는 분들을 위해)

이후 내용은 위의 주장을 직접 확인하고 싶은 분들을 위한 보충 설명입니다.

환경 메모

환경은 클린했다 (만약을 위한 전수 체크)

"정말로 공격받지 않았는가"를 AI의 말이 아닌 자신의 눈으로 확인한 결과. 모두 이상 없음.

재현용 커맨드

**1. 공격 문자열이 어느 파일에 있는가 (내용은 가져오지 않고 파일명만)
**

grep -rlI 'we have access' ~/.claude ~/Developer ~/.config 2>/dev/null

2. 환경의 건전성 체크

echo "$PATH" | tr ':' '\n' # PATH 순서
which -a grep cat ssh node npx python3
ls -la ~/.zshrc ~/.zshenv ~/.zprofile # rc의 실체 (symlink 대상)
...

3. 이 기사의 핵심: 공격 문자열이 "커맨드 출력"인지 "AI의 발언"인지 판정

import json
path = ".../a1b2c3d4-....jsonl"
with open(path) as fh:
...

Discussion