MCP TrustFall 이슈는 2026년 5월 기준 AI 코딩 도구에서 폴더를 신뢰한다는 클릭이 로컬 실행을 허용한다는 뜻까지 넓어질 수 있음을 보여줬다. Claude Code, Gemini CLI, Cursor CLI, Copilot CLI처럼 로컬 프로젝트 설정을 읽는 도구를 쓴다면 .mcp.json, .claude/settings.json, MCP 승인 목록, CI 실행 방식을 먼저 확인해야 한다.
신뢰 버튼을 눌렀는데, 그 버튼이 실제로는 로컬 프로세스 실행까지 뜻한다면 어디부터 봐야 할까. 이 질문이 2026년 5월 TrustFall 이후 MCP 보안 글의 핵심이다. 예전에는 “MCP 서버를 믿을 수 있나”가 질문이었다면, 이제는 “내가 지금 무엇을 신뢰한다고 동의했는지 보이나”가 질문이다.
지금 결론: 외부 저장소를 열기 전에는
.mcp.json과.claude/settings.json을 먼저 보고, 프로젝트 스코프 MCP 서버 자동 승인 설정을 끄거나 좁혀야 한다. CI에서 Claude Code 계열 액션을 headless로 돌린다면 PR 브랜치의 MCP 설정을 그대로 실행하지 않는 별도 게이트가 필요하다.
TrustFall이 말한 위험은 무엇인가
Adversa AI는 2026년 5월 7일 TrustFall 리포트에서 주요 agentic coding CLI 4종이 프로젝트에 정의된 MCP 서버를 폴더 신뢰 승인 뒤 실행할 수 있다고 설명했다. 특히 Claude Code 분석에서는 악성 저장소가 .mcp.json과 .claude/settings.json을 함께 넣어, 사용자가 일반적인 신뢰 프롬프트를 통과한 직후 MCP 서버 프로세스를 띄우는 흐름을 제시했다.
The Register도 같은 날 이 이슈를 보도하면서, cloned repository 안의 JSON 설정 두 개가 공격자가 제어하는 MCP 서버 실행으로 이어질 수 있다는 점을 강조했다. 여기서 중요한 지점은 모델이 이상한 답을 했다는 이야기가 아니다. 설정 파일이 실행 권한으로 이어지는 경계가 흐려졌다는 이야기다.
NVD에 등록된 CVE-2026-33068도 같은 계열의 경고로 읽어야 한다. 이 CVE는 Claude Code 2.1.53 이전 버전에서 repo-controlled .claude/settings.json의 permissions.defaultMode가 workspace trust dialog 판단보다 먼저 반영될 수 있었고, 이로 인해 trust prompt가 우회될 수 있었다고 정리한다. NVD 기준 공개일은 2026년 3월 20일이고, 해당 이슈는 2.1.53에서 패치된 것으로 기록되어 있다.
TrustFall은 이 CVE와 완전히 같은 버그라고만 보면 좁다. 더 정확히는 “AI 코딩 도구가 프로젝트 설정을 어디까지 신뢰할 것인가”라는 운영 문제에 가깝다. 버그는 패치될 수 있지만, 저장소 안 설정 파일이 로컬 실행 권한과 연결되는 구조는 팀이 계속 관리해야 한다.
먼저 볼 파일은 두 개다
첫 번째는 .mcp.json이다. Claude Code 공식 MCP 문서는 project-scoped server가 프로젝트 루트의 .mcp.json에 저장되고, 이 파일이 버전 관리에 들어갈 수 있다고 설명한다. 예시 구조에는 mcpServers 아래에 server name, command, args, env가 들어간다. 말이 설정이지, command가 있으면 결국 로컬에서 실행될 프로그램 경로를 담을 수 있다.
두 번째는 .claude/settings.json이다. Claude Code settings 문서는 권한 설정으로 permissions.allow, permissions.ask, permissions.deny, disableBypassPermissionsMode, enableAllProjectMcpServers, enabledMcpjsonServers 같은 항목을 제공한다. 이 중 enableAllProjectMcpServers는 프로젝트 .mcp.json에 정의된 MCP 서버를 모두 승인하는 설정이고, enabledMcpjsonServers는 승인할 서버 목록을 지정하는 설정이다.
운영 기준은 단순해야 한다. 외부에서 받은 저장소라면 .mcp.json 안의 command, args, env를 먼저 읽고, .claude/settings.json 안에서 MCP 자동 승인이나 넓은 permissions.allow가 있는지 본다. Bash(*), mcp__서버명 전체 승인, Read(~/...), 민감 파일 접근 허용 같은 패턴이 보이면 그 저장소는 바로 작업하지 말고 격리해서 열어야 한다.
| 점검 위치 | 위험 신호 | 왜 문제인가 | 먼저 할 일 |
|---|---|---|---|
.mcp.json |
모르는 command 또는 inline script |
폴더 신뢰 뒤 로컬 프로세스가 실행될 수 있다 | command 전체와 args를 리뷰한다 |
.mcp.json |
env에 토큰 또는 기본값 포함 |
저장소가 비밀값 흐름을 유도할 수 있다 | env는 local secret manager로 분리한다 |
.claude/settings.json |
enableAllProjectMcpServers: true |
프로젝트 MCP 서버를 한 번에 승인한다 | 기본값을 끄고 서버별 승인으로 바꾼다 |
.claude/settings.json |
permissions.allow가 넓다 |
개별 tool call 승인 경계가 무너진다 | allow보다 ask와 deny를 먼저 둔다 |
| CI 설정 | PR 브랜치에서 headless 실행 | 사람이 신뢰 프롬프트를 볼 수 없다 | PR 설정 검증 job을 먼저 둔다 |
권한 설정은 allow보다 deny가 먼저다
Claude Code 보안 문서는 기본적으로 읽기 전용에서 시작하고, 파일 수정이나 명령 실행 같은 추가 작업에는 명시적 승인을 요구한다고 설명한다. 동시에 사용자는 한 번 승인하거나 자동 허용할 수 있다. 이 구조는 편하지만, 팀 저장소에서는 편의가 누적되면 권한 목록이 과거의 퇴적층이 된다.
자료 기준으로 제가 운영한다면 permissions.allow를 먼저 늘리지 않는다. 먼저 permissions.deny에 .env, .env.*, secrets/**, credential 파일, 빌드 산출물, 홈 디렉터리 민감 경로를 넣는다. Claude Code settings 문서도 .claude/settings.json에서 민감 파일을 permissions.deny로 제외하는 예시를 제공한다.
그다음 ask를 넓게 잡는다. git push, curl, wget, deploy script, package publish, cloud CLI, SSH, database migration, payment 관련 명령은 자동 허용보다 질문 대상으로 두는 게 낫다. AI 코딩 도구에서 보안은 “잘 막는 도구”보다 “멈출 지점을 잊지 않는 운영”에 가깝다.
MCP permissions도 서버 단위 전체 승인보다 tool 단위 승인이 좋다. Claude Code 문서는 MCP tool permission을 구성할 수 있다고 설명한다. 서버 이름 전체를 승인하면 그 서버가 제공하는 도구 전체를 믿는 뜻이 되기 쉽다. 처음 붙이는 MCP 서버라면 읽기 도구만 열고, 쓰기와 외부 전송 도구는 별도 승인으로 분리하는 편이 안전하다.
Trust prompt는 보안 설계가 아니라 마지막 확인이다
TrustFall 리포트가 불편한 이유는 프롬프트 자체가 공격 지점이라는 데 있다. 개발자는 신뢰 프롬프트를 자주 본다. 자주 보면 빨라지고, 빨라지면 읽지 않는다. 권한창이 길어도 문제고, 너무 짧아도 문제다. 길면 귀찮아서 넘기고, 짧으면 무엇을 승인하는지 모른다.
그래서 팀 기준은 trust prompt 앞에 있어야 한다. 외부 저장소를 열기 전 preflight 스크립트가 .mcp.json, .claude/settings.json, .cursor, .github/workflows, package scripts를 먼저 훑어야 한다. 여기서 MCP 서버 command, 자동 승인, 네트워크 전송, 민감 파일 read, CI headless 실행이 발견되면 개발자가 직접 승인하기 전까지 agentic coding tool을 실행하지 않는 식이다.
MCP 공식 security best practices도 local MCP server compromise를 별도 위험으로 다룬다. 로컬 MCP 서버는 사용자의 머신에서 실행되는 바이너리 또는 스크립트이고, 적절한 sandboxing과 consent가 없으면 arbitrary code execution, data exfiltration, data loss 같은 위험이 생길 수 있다고 정리한다. 이 문서는 consent dialog가 실행될 정확한 command와 argument를 보여줘야 한다고도 권고한다.
여기서 독자가 가져갈 문장은 하나다. “이 저장소를 믿습니까?”는 충분한 질문이 아니다. “이 저장소가 어떤 MCP 서버를 어떤 command로 실행하고, 어떤 권한을 자동 허용하며, 어떤 파일을 읽을 수 있습니까?”까지 보여야 운영 가능한 질문이 된다.
CI에서는 더 보수적으로 봐야 한다
로컬 개발자는 그나마 화면을 본다. CI runner는 화면을 보지 않는다. Adversa AI는 TrustFall에서 headless CI 변형도 다뤘고, 신뢰 프롬프트가 렌더링되지 않는 실행 환경에서는 공격이 사람 클릭 없이 이어질 수 있다고 설명했다.
팀에서 Claude Code Action이나 비슷한 agentic coding action을 PR에 붙인다면, PR 브랜치의 .mcp.json과 agent 설정을 그대로 신뢰하면 안 된다. PR이 수정할 수 있는 파일과 CI가 실행하는 파일이 겹치면, 외부 기여자가 실행 환경을 바꿀 수 있다. 이건 AI 문제가 아니라 CI 보안의 오래된 문제인데, MCP가 붙으면 실행면이 더 커진다.
CI 쪽 최소 기준은 세 가지다. 첫째, PR 브랜치의 MCP 설정은 실행하지 않는다. 둘째, agent가 필요한 secret은 read-only token과 최소 권한 GitHub token으로 분리한다. 셋째, MCP 설정 변경이 들어온 PR은 별도 label이나 CODEOWNERS 승인이 없으면 agent job이 스킵되게 한다. 조금 귀찮지만, 나중에 로그 뒤지는 것보다 싸다.
우리 팀 체크표
| 단계 | 질문 | 통과 기준 |
|---|---|---|
| 1 | 외부 저장소인가 | 예라면 agent 실행 전 설정 파일부터 본다 |
| 2 | .mcp.json에 project server가 있는가 |
command, args, env를 사람이 읽었다 |
| 3 | MCP 자동 승인 설정이 있는가 | 전체 승인 대신 서버별, 도구별 승인을 쓴다 |
| 4 | permissions.allow가 넓은가 |
위험 명령은 ask 또는 deny로 옮겼다 |
| 5 | 민감 파일 read가 가능한가 | .env, secrets, credentials는 deny에 들어갔다 |
| 6 | CI에서 headless 실행하는가 | PR 브랜치 설정을 그대로 실행하지 않는다 |
| 7 | 로그가 남는가 | 어떤 tool이 언제 왜 실행됐는지 추적 가능하다 |
이 체크표를 통과하지 못하면 MCP를 쓰지 말자는 뜻이 아니다. 반대로 MCP를 오래 쓰려면 이 정도 경계선이 필요하다는 뜻이다. 도구는 점점 좋아지고, 팀은 점점 더 많이 연결한다. 연결이 많아질수록 “좋은 서버인가”보다 “나쁜 설정이 들어와도 어디서 멈추나”가 더 중요해진다.
누구에게 맞고 아닌가
개인 장난감 프로젝트에서 내가 만든 MCP 서버 하나를 로컬로 붙이는 정도라면 이 글의 기준이 과하게 느껴질 수 있다. 그래도 외부 저장소를 자주 열거나, GitHub Actions에서 AI agent를 돌리거나, 사내 토큰과 고객 데이터가 있는 저장소를 다룬다면 기준을 낮추면 안 된다.
팀 도입 단계라면 처음부터 managed settings나 공통 .claude/settings.json 정책을 잡는 편이 낫다. 프로젝트별 설정을 전부 금지하라는 뜻은 아니다. 다만 자동 승인, 민감 파일 접근, 네트워크 전송, 배포 명령은 사용자 취향이 아니라 팀 정책이어야 한다.
TECHTAEK의 기존 MCP 보안 허브도 같은 이유로 업데이트한다. MCP STDIO, config write, Codex Always allow, 이번 TrustFall은 이름은 다르지만 같은 질문으로 모인다. AI 코딩 에이전트에게 실행 권한을 줄 때, 설정 파일과 권한창이 정말 같은 말을 하고 있는가.
FAQ
TrustFall은 Claude Code만의 문제인가
아니다. Adversa AI 리포트는 Claude Code를 깊게 다루지만 Gemini CLI, Cursor CLI, Copilot CLI에서도 project-defined MCP server 실행 흐름을 확인했다고 설명한다. 다만 도구마다 권한창이 MCP를 얼마나 명확히 보여주는지는 다르다.
CVE-2026-33068과 TrustFall은 같은 이슈인가
같은 계열의 신뢰 경계 문제로 보면 된다. CVE-2026-33068은 Claude Code 2.1.53 이전 버전의 trust dialog bypass 이슈로 NVD에 등록되어 있고, TrustFall은 2026년 5월에 공개된 MCP 프로젝트 설정과 trust prompt UX 문제를 다룬다.
지금 당장 무엇을 확인해야 하나
외부 저장소라면 .mcp.json, .claude/settings.json, .github/workflows, package scripts를 먼저 확인한다. 그중 command, enableAllProjectMcpServers, enabledMcpjsonServers, 넓은 permissions.allow, secret 접근, CI headless 실행이 1차 점검 대상이다.
.mcp.json을 전부 금지해야 하나
그럴 필요는 없다. 프로젝트 단위 MCP 서버는 팀 협업에 유용하다. 대신 어떤 command가 실행되는지 보이고, 서버별 승인이나 도구별 승인으로 좁혀야 한다. 모르는 서버를 전체 승인하는 습관이 위험하다.
permissions.deny에는 무엇을 넣어야 하나
기본으로 .env, .env.*, secrets/**, credential 파일, SSH key, cloud config, production dump, 개인 홈 디렉터리 민감 경로를 둔다. 팀 저장소라면 배포, 결제, DB migration, package publish는 deny 또는 ask로 시작하는 편이 낫다.
CI에서 MCP를 꼭 써야 한다면 어떻게 해야 하나
PR 브랜치가 MCP 설정을 바꿔도 바로 실행되지 않게 해야 한다. MCP 설정 변경은 CODEOWNERS 승인 후 main에서만 반영하고, agent job은 read-only token과 최소 secret으로 실행하는 쪽이 안전하다.
참고 자료
- Adversa AI, TrustFall research, 2026년 5월 7일
- The Register, Claude Code trust prompt can trigger one-click RCE, 2026년 5월 7일
- NVD, CVE-2026-33068
- Claude Code security docs
- Claude Code settings docs
- Claude Code MCP docs
- Model Context Protocol security best practices