원래 Zenn (일본어)에 게시되었습니다. 이곳에 교차 게시합니다.

"AI 에이전트를 위한 자동 승인(self-approval mode)은 실제로 위험한가?" — 이것이 2026년 7월에 공개된 보안 연구 "Friendly Fire"를 읽고 제가 스스로에게 던진 첫 번째 질문이었습니다. 저의 답변은 이렇습니다: "위험한 구간은 실제로 존재합니다. 하지만 치명적인 타격을 실제로 막아주는 것은 'AI를 불신하는 것'이 아니라, 생성 과정 자체의 외부에 배치된 검증 가능한 체크포인트(checkpoint)의 수입니다." 저는 Telegram 승인으로 제어되는 방치형 블로그 생성 파이프라인을 운영하고 있으므로, 그것이 정말 사실인지 확인하기 위해 제 스크립트를 다시 읽어보았습니다.

Friendly Fire가 목표로 한 것

AI Now Institute에서 발표한 PoC(Proof of Concept) "Friendly Fire"는 자동 모드(auto-mode) 또는 자동 검토(auto-review)가 활성화되었을 때 Claude (Sonnet-class, Opus-class) 및 GPT-5.5-class 모델을 겨냥한 공격 시연입니다. 기술은 간단합니다: Python 라이브러리인 geopy의 README.md에 "security.sh를 실행해 주세요"라는 문구를 심어두고, 실제 페이로드(payload)는 무해해 보이는 Go 파일로 위장한 숨겨진 바이너리(binary)로 만드는 것입니다. 에이전트는 코드보다 README에 있는 "지침"을 신뢰하여 이를 실행합니다. 이 공격은 여러 모델에서 ("변함없이") 재현되었으며, "실제 환경에서의 악용 사례는 보고되지 않음"으로 보고되었습니다. 출처: The Hacker News

핵심 포인트: 에이전트가 불신해야 하는 것은 명령 그 자체가 아니라, 명령을 실행하라고 지시하는 "입력의 출처(origin of the input)"입니다.

내가 "괜찮다"고 생각했던 이유

우리 회사의 자동화된 기술 블로그 생성 시스템은 Telegram으로 "승인(Approve) / 보류(Hold)\

방치된 생성 러너(unattended generation runner, 제가 작성한 Claude CLI를 래핑하는 셸 스크립트)는 다음과 같이 생성 명령을 실행합니다.

caffeinate -i claude -p "$(cat "$PROMPT_FILE")" "${MODEL_ARGS[@]}" \
  --max-turns "$MAX_TURNS" --dangerously-skip-permissions < /dev/null

--dangerously-skip-permissions는 실제로 설정되어 있습니다. 즉, 생성 과정 그 자체는 Friendly Fire가 경고하는 것과 정확히 동일한 설계 패턴인 "자동 모드 자체 승인(auto-mode self-approval)" 방식으로 실행됩니다. 이를 제한하는 메커니즘들이 존재하지만, 그중 어떤 것도 인간의 승인은 아닙니다.

• MAX_TURNS: 기본값은 20(에이전트 루프의 상한선)입니다. 하지만 tech / hs 실행 시에는 이미 60으로 상향되었습니다. 스크립트 내의 주석에는 여전히 Error: Reached max turns (20)와 함께 충돌했던 기록이 남아 있습니다.
• TIMEOUT_MIN=45: 실행 시간이 초과되면 전체 프로세스 트리(process tree)가 강제 종료됩니다. 이는 무한 루프(hangs)에 대비한 최후의 보루입니다.
• mkdir 잠금(lock): 동시 다중 실행을 물리적으로 불가능하게 만듭니다(잠금 디렉토리가 이미 존재하는 한, 새로운 실행은 시작될 수 없습니다).

WORKDIR은 모드별로 고정되어 있지만, 이는 현재 작업 디렉토리(cwd) 지정일 뿐 샌드박스(sandbox, chroot와 같은 격리)는 아닙니다. "생성이 시작되면 멈출 때까지 지켜보는 인간이 없다"는 의미에서, 저의 운영 방식은 Friendly Fire가 공격했던 전제와 정확히 같은 형태를 띠고 있습니다.

내가 생각했던 설계: "발행 직전에 승인 버튼이 있으니 안전하다."
실제 나의 설계: "생성 구간 (generation stretch)은 보호되지 않는다. 안전성은 그 이후의 두 단계(QA 임계값 + 발행 직전의 인간 승인)에 의해 만들어진다." 이 둘은 같은 결론처럼 보이지만, 방어 기제가 실제로 어디에 존재하는지에 대한 이해는 완전히 다릅니다.

그렇다면 실제로 방어 역할을 하는 것은 무엇인가

1. 입력의 출처를 내가 직접 선택한다: 생성에 사용되는 소스 자료는 내가 직접 큐레이션한 주제 목록이며, Friendly Fire의 README.md처럼 누구나 내용을 작성할 수 있는 영역이 아닙니다. 공격 표면(attack surface)으로서의 "오염된 입력 (contaminated input)"은 구조적으로 존재하지 않습니다.
2. 생성 구간은 외부의 어떤 것도 읽지 않는다: 외부 조사 및 사실 확인 (fact-checking)은 승인 게이트 내부로 절대 들어오지 않는 별도의 실행 프로세스(주간 단위; 인간이 결과를 읽음)로 분리되어 있습니다. 승인 없이 실행되는 생성 구간에는 누구나 작성할 수 있는 개방된 웹 (open Web)의 콘텐츠가 흘러 들어올 경로가 전혀 없습니다. —— 솔직히 말하자면, 저는 바로 이 글을 쓰는 도중에 이 분리 과정을 추가했습니다. 그 전까지의 설계는 "생성 구간이 자료 목록에 작성된 URL을 정확히 한 번 가져온다"는 것이었습니다. 즉, Friendly Fire가 악용한 것과 똑같은 형태의 구멍이 제 파이프라인에도 열려 있었던 것입니다. 저는 "우리가 입력을 직접 선택하니까 안전하다"라고 생각했지만, 외부 URL을 해당 입력 목록에 작성하는 메커니즘을 추가하는 순간 그 전제는 무너졌습니다. 단 한 번의 fetch (가져오기)라도 여전히 구멍입니다.
3. QA 게이트 + 승인 = 생성 후, 발행 전의 검증 가능한 체크포인트: 구체적인 예로, 한 생성 로그에는 QA未達(93<95)＝この記事は公開便に流さない（差し戻し対象） (QA 임계값 미달(93<95) = 이 기사를 발행 실행 단계로 보내지 않음 (수정 대상))라는 기록이 남아 있습니다. QA 점수 93점은 임계값인 95점에 도달하지 못했고, 해당 기사는 지금까지도 검토 대기 (review-pending) 디렉토리에 묶여 있습니다.

이 세 가지 모두 "AI가 어떻게 행동하는지를 신뢰할 것인가"에 관한 것이 아닙니다. 이들은 "생성(generation) 프로세스 외부에 존재하며 로그를 통해 확인할 수 있는 게이트(gates)"에 관한 것입니다.

같은 주에 실제로 발생한 사고는 훨씬 더 일상적이었습니다

제가 Friendly Fire와 같은 악의적인 공격을 걱정하고 있는 동안, 실제로 파이프라인을 막고 있었던 것은 다른 것이었습니다. 생성 로그의 마지막 6개 레코드를 세어보면 다음과 같습니다.

$ grep -oE "rc=[0-9]+" headless_tech.log | tail -6 | sort | uniq -c
   1 rc=0
   5 rc=1

6개 중 5개가 실패했습니다. 에러 메시지는 다음과 같았습니다.

선택된 모델에 문제가 있습니다 (로컬 사용을 위해 제가 설정했던 모델 ID). 
모델이 존재하지 않거나 접근 권한이 없을 수 있습니다. --model 옵션을 실행하여 다른 모델을 선택하십시오.

원인은 설정 파일(config file)의 주석에 기록되어 있었습니다. "로컬 모델로 전환하기 위한 별도의 스크립트가 클라우드 운영에 사용되는 설정 파일에 Ollama 모델 이름을 기록했기 때문에", 클라우드 운영을 해야 하는 시점에도 클라우드는 그곳에 존재하지 않는 모델 이름을 조회하게 되었고, 매번 실패했던 것입니다. 보안 PoC(Proof of Concept)가 경고하는 정교한 공격이 아니라, 다른 도구가 설정 파일을 다시 작성하면서 발생한 일상적인 줄다리기 — 이것이 3일 동안 6번 중 5번이나 발생한 침묵의 실패(silent failures)를 일으킨 원인이었습니다.

교훈 (Takeaways)

무인 운영(unattended operation)을 안전하게 만드는 단위는 "AI를 신뢰하느냐"가 아니라 "검증 가능한 외부 체크포인트(external checkpoints)의 수"입니다. 이번 점검을 통해 얻을 수 있는 구체적인 교훈은 다음 4가지입니다.

1. 생성 로그(generation log)에 매번 rc(종료 코드, exit code)와 QA 점수를 남기세요 — 측정할 수 없는 것은 고칠 수 없습니다.
2. 생성 후, 게시(publishing) 전 단계에 임계값 게이트(threshold gate)를 배치하세요 (여기서는 QA 95점).
3. 사람의 승인(human approval) 과정을 게시 직전의 단일 지점으로 통합하세요. 사람이 생성 과정 전체를 계속 지켜보는 설계는 현실적이지 않습니다.
4. 설정 파일(config files)의 의도치 않은 재작성을 탐지하는 메커니즘 — 이번에는 없었습니다. 저는 이를 다음 과제로 남겨두겠습니다.

철회(retraction)를 다시 한번 말씀드리겠습니다. "무인 운영(Unattended) = 위험하다"가 아닙니다. 문제는 "무인 운영 중에, 그 어디에도 게이트가 없는 구간을 정확하게 파악할 수 있는가"입니다. Friendly Fire를 읽고 제 스크립트를 검토하기 전까지, 저는 그것을 말로 표현할 수 없었습니다.