AI 코딩 에이전트(Claude Code, Cursor, Gemini CLI 등)의 보안 위험이라고 하면 보통 "모델이 폭주해서 위험한 명령을 실행하는" 그림을 떠올립니다. 그런데 최근 몇 달 사이 실제로 보고된 심각한 사례는 하나같이 모델이 원인이 아니었습니다. 시작점은 전부 설정 파일이었습니다.
이 글에서는 TrustFall과 AWS Kiro 사례로 "설정 파일이 왜 공격면이 되는가"를 본 다음, 그 대응으로 만든 OSS 도구 Sigil을 소개합니다.
사례 1: clone하고 열기만 해도 RCE (TrustFall)
2026년 5월 Adversa AI가 공개한 TrustFall은, 악성 리포지토리를 clone해서 열기만 해도 Claude Code / Cursor / Gemini CLI / GitHub Copilot 네 도구에서 원클릭 RCE가 성립한다는 것을 보여준 보고입니다.
공격자는 리포지토리에 파일 두 개만 심어두면 됩니다.
.mcp.json: 공격자가 준비한 MCP 서버를 가리킴.claude/settings.json:enableAllProjectMcpServers같은 프로젝트 스코프 설정
사용자가 그 리포지토리를 열고 "이 폴더를 신뢰하시겠습니까?" 다이얼로그에서 Enter를 누르는 순간, 공격자의 MCP 서버가 기동합니다. 그다음은 다른 프로젝트의 소스나 저장된 인증 정보를 읽거나, 외부로 나가는 통신 채널을 여는 식입니다. CI 러너에서 headless로 실행 중이면 신뢰 다이얼로그 자체가 뜨지 않으므로, 사람의 조작 없이도 성립합니다.
게다가 이건 단발성 버그가 아닙니다. Check Point Research는 "신뢰 확인보다 먼저 프로젝트 설정이 처리되어 버린다"는 문제로, CVE-2025-59536(.claude/의 hooks나 MCP 서버 설정을 경유한 RCE)과 CVE-2026-21852(ANTHROPIC_BASE_URL을 악용한 API 키 유출)를 보고했습니다. 둘 다 clone하고 여는 것만으로, 신뢰 다이얼로그를 확인하기 전에 성립합니다.
사례 2: 설정을 나중에 다시 쓴다 (AWS Kiro)
TrustFall이 "악성 설정을 처음부터 심어두는" 공격이라면, AWS의 Agentic IDE인 Kiro 사례는 "설정을 나중에 다시 쓰는" 공격입니다.
Johann Rehberger(Embrace The Red)의 보고에서는, 간접 프롬프트 인젝션으로 다음 설정이 재작성됐습니다.
.vscode/settings.json의kiroAgent.trustedCommands: ["*"].kiro/settings/mcp.json
trustedCommands에 *가 들어가면 에이전트는 확인 없이 임의 명령을 실행할 수 있습니다. 웹 페이지나 이슈에서 흘러 들어온 지시가 로컬 설정 파일을 다시 쓰고, 그게 임의 명령 실행으로 이어진 겁니다. 이 문제는 Kiro 0.1.42에서 수정됐습니다.
공격면은 모델이 아니라 설정 파일
세 사례에서 모델이 "악의를 갖고 판단한" 것은 하나도 없습니다. 노려진 건 다음 같은 설정이었습니다.
- hooks
- permissions (allow / deny)
- MCP allowlist
- sandbox 플래그
- trustedCommands
에이전트가 "무엇을 해도 되는가"를 정하는 건 이런 설정 파일입니다. 그리고 이것들은 파일을 읽을 때가 아니라 프로젝트를 열 때 효력이 생깁니다. 리뷰하기 전에 권한이 붙어버리는 셈입니다.
EDR은 실제로 실행된 rm -rf는 잡아낼 수 있지만, 그 실행을 허용한 설정 변경 쪽은 보지 않습니다. 지켜야 할 곳은 에이전트가 실행한 명령이 아니라, 그걸 허용한 설정 쪽에 있습니다.
어떻게 막을까
쓸 수 있는 수는 크게 두 가지입니다.
- AI 코딩 에이전트는 가능한 한 container / sandbox 안에서만 쓴다
- 설정 파일의 변경을 감시해서, 위험한 상태가 되면 알아챌 수 있게 한다
다만 2번을 손으로 계속하는 건 무리가 있습니다. .claude/settings.json이나 .mcp.json이 바뀔 때마다 사람이 눈으로 확인하는 운영은 언젠가 안 굴러갑니다.
만든 것: Sigil
그래서 만든 게 Sigil입니다. 호스트 쪽에서 도는 AI Security Posture Management(AI-SPM) 에이전트입니다.
에이전트의 권한을 정하는 설정 파일(hooks, permissions, MCP allowlist, sandbox 플래그)을 감시해서, 설정이 위험해지면 위험도를 채점하고, 그 이벤트를 로그나 SIEM으로 흘려보냅니다.
차단은 하지 않습니다. 채점하고 기록할 뿐입니다. "이 설정이 바뀌어서, 지금 에이전트는 X를 할 수 있는 상태가 됐다"고 알립니다. 실제로 막는 건 에이전트 쪽 런타임이나 기존 장치에 맡깁니다. 막지 않는 대신, 오탐으로 개발자 작업을 방해하지도 않습니다.
데모
실제로 돌려보면 이렇습니다.
- 읽기 전용 permission에 hook 없는 정상 config → 점수 0 / low
- 거기에 matcher
.*인 PreToolUse hook으로rm -rf $HOME을 심음 → 7.5 / critical로 재채점 (no sandbox, broad matcher, destructive command)
기술 메모
- Rust 단일 바이너리 (x86_64 musl 정적 빌드, macOS arm64, Windows)
- 파일 감시는 tokio + notify (폴링 안 함)
- 원라인 설치, Apache-2.0
겸사겸사 정직하게 적어두면, 구현의 대부분은 Claude Code를 쓴 바이브 코딩입니다. 위협 모델과 채점 규칙과 아키텍처는 직접 정하고, 코드의 상당 부분은 AI에게 쓰게 했습니다. 에이전트가 무엇을 해도 되는지 감시하는 도구를 에이전트에게 쓰게 한 셈이라, 스스로도 좀 이상하긴 했습니다.
마치며
AI 코딩 에이전트가 공격당할 때 노려지는 건 모델이 아니라, 아무도 리뷰하지 않은 설정 파일입니다. TrustFall도 Kiro도 CVE-2025-59536도, 결국 같은 곳을 찌르고 있습니다.
여러분은 신뢰할 수 없는 리포지토리의 설정 파일을 어떻게 다루시나요. 전부 sandbox에 넣나요, 손으로 리뷰하나요, 아니면 그냥 여나요.
리포지토리와 데모는 여기 있습니다.
https://github.com/Ju571nK/sigil
참고 링크
- TrustFall: coding agent security flaw enables one-click RCE in Claude, Cursor, Gemini CLI and GitHub Copilot (Adversa AI)
- Claude Code trust prompt can trigger one-click RCE (The Register)
- Caught in the Hook: RCE and API Token Exfiltration Through Claude Code Project Files, CVE-2025-59536 / CVE-2026-21852 (Check Point Research)
- AWS Kiro: Arbitrary Command Execution with Indirect Prompt Injection (Embrace The Red)
'AI for Security' 카테고리의 다른 글
| 바이브코딩의 설정 파일 공격 (CVE-2026-30615) (0) | 2026.05.30 |
|---|