AI 코딩 에이전트의 진짜 공격 표면은 설정 파일이다

만약 당신이 AI 코딩 에이전트(Claude Code, Cursor, Gemini CLI)의 보안 위험이 "모델이 폭주하여 위험한 명령을 실행하는 것"이라고 생각한다면, 지난 몇 달간 발생한 심각한 사건들은 다른 이야기를 들려줍니다. 그중 어느 것도 실제로 모델에 관한 것이 아니었습니다. 시작점은 언제나 설정 파일(config file)이었습니다. 이 포스트에서는 TrustFall과 AWS Kiro를 살펴보고, 왜 설정 파일이 공격 표면(attack surface)이 되었는지 설명하며, 이에 대응하여 제가 만든 오픈 소스 도구인 Sigil을 소개합니다.

TrustFall: 클론, 열기, RCE
2026년 5월, Adversa AI는 TrustFall을 발표했습니다. 악성 저장소(repository)를 클론(clone)하고 여는 것만으로도 Claude Code, Cursor, Gemini CLI, 그리고 GitHub Copilot 전체에 걸쳐 원클릭 RCE(원격 코드 실행)가 가능했습니다. 설정은 저장소 내의 두 파일로 구성됩니다: 공격자가 제어하는 MCP 서버를 가리키는 .mcp.json, 그리고 enableAllProjectMcpServers와 같은 프로젝트 범위 설정을 포함하는 .claude/settings.json입니다. 사용자가 저장소를 열고 "이 폴더를 신뢰합니까?"라는 대화 상자에서 Enter를 누르면 공격자의 MCP 서버가 시작됩니다. 거기서부터 공격자는 다른 프로젝트의 소스 코드와 저장된 자격 증명(credentials)을 읽거나, 장기적인 아웃바운드 연결(outbound connection)을 열 수 있습니다. 헤드리스(headless) CI 러너(runner)에서는 신뢰 대화 상자가 절대 나타나지 않으므로, 인간의 개입(human in the loop) 없이 그대로 실행됩니다. 그리고 이것은 단발성 사건이 아닙니다. Check Point Research는 "프로젝트 설정이 신뢰 프롬프트 이전에 처리된다"는 동일한 유형의 문제를 보고했습니다: CVE-2025-59536 (.claude/ hooks 또는 MCP 서버 설정을 통한 RCE) 및 CVE-2026-21852 (ANTHROPIC_BASE_URL 오용을 통한 API 키 유출). 두 사례 모두 신뢰 대화 상자를 확인하기 전, 클론 후 열기(clone-and-open) 단계에서 발생합니다.

AWS Kiro: 사후에 설정을 재작성하기
TrustFall이 사전에 악성 설정을 배포한다면, AWS의 에이전트형 IDE인 Kiro의 사례는 나중에 설정을 재작성하는 것에 관한 것입니다. Johann Rehberger (Embrace The Red)는 간접 프롬프트 주입(indirect prompt injection)을 통해 다음과 같은 내용을 재작성할 수 있음을 보여주었습니다:
.vscode/settings.json 내의 kiroAgent.trustedCommands: ["*"]
.kiro/settings/mcp.json
일단 trustedCommands에 * 가 포함되면, 에이전트는 확인 절차 없이 임의의 명령을 실행합니다.

웹 페이지나 이슈(issue)에서 주입된 지침(Instructions)이 로컬 설정 파일을 조용히 수정하면, 그것이 임의 명령 실행(arbitrary command execution)으로 이어집니다. 이 문제는 Kiro 0.1.42 버전에서 수정되었습니다. 공통점은 설정 파일이 권한을 부여한다는 것입니다. 이 모든 사례에서 모델은 악의적인 행동을 하기로 스스로 "결정"한 것이 아닙니다. 공격받은 대상은 바로 설정(configuration)이었습니다: hooks 권한 (allow / deny), MCP 허용 목록 (allowlists), 샌드박스 플래그 (sandbox flags), trustedCommands. 이러한 설정 파일들이 에이전트가 무엇을 할 수 있는지를 결정합니다. 난처한 점은 이 설정들이 당신이 내용을 읽을 때가 아니라, 프로젝트를 열 때 즉시 적용된다는 것입니다. 당신이 무엇인가를 검토하기도 전에 권한이 부여됩니다. EDR(Endpoint Detection and Response)은 실행된 rm -rf는 볼 수 있지만, 이를 승인한 설정 변경은 볼 수 없습니다. 방어해야 할 지점은 명령 그 자체가 아니라, 그 명령을 허용한 설정입니다.

어떻게 방어할 것인가? 두 가지 실질적인 조치가 있습니다: 1. 가능한 한 항상 컨테이너(container)나 샌드박스(sandbox) 내부에서 AI 코딩 에이전트를 실행하십시오. 2. 설정 파일을 모니터링하며 언제 위험하게 변하는지 감지하십시오. 2번을 수동으로 하는 것은 지속 가능하지 않습니다. .claude/settings.json과 .mcp.json이 변경될 때마다 일일이 눈으로 확인하는 과정은 결국 무너지기 마련입니다.

내가 만든 것: Sigil
그래서 저는 호스트 측 AI 보안 태세 관리 (AI-SPM, AI Security Posture Management) 에이전트인 Sigil을 만들었습니다. Sigil은 에이전트의 권한을 결정하는 설정 파일들(hooks, permissions, MCP allowlists, sandbox flags)을 감시하고, 설정이 위험해지면 점수를 매기며, 해당 이벤트를 로그나 SIEM(Security Information and Event Management)으로 전송합니다. Sigil은 차단하지 않습니다. 점수를 매기고 기록할 뿐입니다. Sigil은 "이 설정이 변경되었으며, 이제 에이전트가 X를 할 수 있습니다"라고 알려줍니다. 실제로 동작을 중단시키는 것은 에이전트 런타임(runtime)과 기존의 제어 수단에 맡깁니다. 차단 대신 측정 방식을 사용하기 때문에, 오탐(false positives)으로 인해 개발자의 업무를 방해하지 않습니다.

데모
읽기 전용 권한만 있고 hooks가 없는 일반적인 설정은 0점 / 낮음(low) 점수를 받습니다. rm -rf $HOME을 실행하는 매처(matcher) .*를 가진 PreToolUse hook을 추가하면, 점수는 7.5점 / 심각(critical)으로 재산정됩니다 (샌드박스 미사용, 지나치게 광범위한 매처, hook 내의 파괴적인 명령 포함).

기술 노트
단일 정적 바이너리 (x86_64 musl, macOS arm64 및 Windows 포함)
tokio 및 notify를 사용한 파일 감시 (File watching), 폴링 (Polling) 방식 미사용
한 줄 설치, Apache-2.0
참고로, 구현의 대부분은 Claude Code를 사용하여 바이브 코딩 (vibe-coded)되었습니다. 저는 위협 모델 (threat model), 채점 기준 (scoring rubric), 그리고 아키텍처 (architecture)를 주도했고, AI가 많은 코드를 작성하도록 했습니다. 코딩 에이전트 (coding agent)가 무엇을 할 수 있는지 감시하는 도구를 코딩 에이전트를 사용하여 만드는 것은 조금 재미있는 경험이었습니다.

맺음말
AI 코딩 에이전트가 공격받을 때, 타겟은 모델 (model)이 아닙니다. 아무도 검토하지 않은 설정 파일 (config file)입니다. TrustFall, Kiro, 그리고 CVE-2025-59536은 모두 동일한 지점을 타격했습니다. 여러분은 오늘날 신뢰할 수 없는 저장소 설정 (untrusted repository configs)을 어떻게 처리하고 계신가요? 모든 것을 샌드박스 (Sandbox) 처리하시나요, 설정을 수동으로 검토하시나요, 아니면 그냥 열어보고 운에 맡기시나요?

저장소, 데모, 그리고 설정 감시 (config-watching)에 대한 상세 정보: https://github.com/Ju571nK/sigil

참고 문헌
TrustFall (Adversa AI)
Caught in the Hook: CVE-2025-59536 / CVE-2026-21852 (Check Point Research)
AWS Kiro: Arbitrary Command Execution with Indirect Prompt Injection (Embrace The Red)