도구 기반 에이전트를 위한 런타임 방어

일주일 전 저는 SSRF, 도구 포이즈닝, 신뢰 우회 패턴에 걸쳐 50개의 MCP 취약점을 공개했습니다. 암묵적인 결론은 암울했어요. 공격 표면이 감사 역량보다 빠르게 확장되고 있다는 것이었습니다. Wei Zhao, Zhe Li, Peixin Zhang, Jun Sun이 구조적 해결책을 제시하는 새 논문을 발표했고, 같은 주에 발생한 실제 텔레메트리 사건이 이 해결책이 왜 중요한지 정확히 보여줍니다.

4월 13일 arxiv에 게재된 ClawGuard는 모든 도구 호출 경계에서 사용자가 확인한 규칙 집합을 강제하는 런타임 보안 프레임워크입니다.¹ 평가된 구성에서 이 프레임워크는 기본적인 접근 제어 규칙(무단 파일 접근 차단, 자격 증명 유출 방지, 네트워크 호출 제한)을 모든 외부 도구 호출 전에 적용합니다. 모델 수정 없음. 인프라 변경 없음. 안전성 특화 파인튜닝 없음.¹ 저자들은 5개의 최신 LLM을 사용해 AgentDojo, SkillInject, MCPSafeBench에서 테스트했습니다.¹ 논문에는 사용자의 명시된 목표에서 자동으로 제약 조건을 도출하는 태스크 특화 규칙 유도 구성 요소도 설명되어 있지만, 저자들은 이를 평가 구성에 포함하지 않았습니다.

핵심 주장은 이것입니다: ClawGuard는 정렬 의존적 방어를 결정론적이고 감사 가능한 메커니즘으로 전환합니다.¹

정렬이 보안 경계가 될 수 없는 이유

지난주 제가 분류한 MCP 취약점 대부분은 공통적인 구조적 틈을 악용합니다. 에이전트가 도구 설명, 가져온 웹 페이지, 또는 스킬 파일에서 명령을 받았을 때, 그 주입과 실행 사이에 있는 유일한 방어선은 모델이 정당한 명령과 적대적 명령을 구분하는 능력뿐입니다. (SSRF, RCE, 경로 탐색을 포함한 일부 취약점은 모델의 명령 수행 여부와 관계없이 서버 측 결함을 악용하지만, 도구 호출 경계는 방어에 여전히 중요합니다.)

정렬 훈련은 도움이 됩니다. RLHF는 모델이 유해한 요청을 거부할 가능성을 높여줍니다. 하지만 “가능성이 높다”는 것은 보안 속성이 아닙니다. 프롬프트 주입의 99%를 거부하는 모델도 1%는 실패하며, 입력을 제어하는 공격자는 그 1%가 적중할 때까지 반복할 수 있습니다. 도구 포이즈닝 패턴은 모델의 실패조차 필요로 하지 않습니다. 오염된 설명이 악의적 행동을 의도된 행동처럼 보이게 만듭니다.

런타임 차단은 완전히 다른 계층에서 작동합니다. 실행 전에 도구 호출을 검사하는 훅이나 정책 엔진은 모델이 공격을 이해했는지 여부에 의존하지 않습니다. 검사는 결정론적입니다: 호출이 허용된 집합과 일치하는가, 아닌가?

세 가지 주입 채널, 하나의 시행 지점

ClawGuard는 도구 기반 에이전트에 대한 세 가지 공격 채널을 식별합니다:¹

웹 및 로컬 콘텐츠 주입. 에이전트가 적대적 명령이 포함된 웹 페이지나 로컬 파일을 읽습니다. 이 명령은 에이전트가 사용자가 의도하지 않은 방식으로 도구를 호출하도록 유도합니다. 은밀한 데이터 유출 공격 표면이 이 패턴의 한 사례로, 가져온 콘텐츠에 유출 명령이 숨겨져 있습니다.

MCP 서버 주입. 손상되었거나 악의적인 MCP 서버가 도구 설명이나 응답 페이로드에 명령을 삽입합니다. 에이전트는 이 명령을 컨텍스트로 읽고 실행합니다. 지난주의 50개 취약점 카탈로그가 이 채널을 상세히 문서화하고 있습니다.

스킬 파일 주입. 공격자가 에이전트가 신뢰할 수 있는 컨텍스트로 로드하는 스킬 파일과 설정에 적대적 명령을 배치합니다. 에이전트는 스킬 파일 내용을 권위 있는 것으로 취급하므로, 스킬 파일이나 설정에 쓸 수 있는 공격자가 에이전트의 동작을 지시할 수 있습니다.

방어 아키텍처는 시행 지점을 도구 호출 경계에 배치합니다. 어떤 채널이 명령을 주입했든 모든 외부 동작이 통과해야 하는 단일 지점입니다.¹ 에이전트가 도구를 호출하기 전에 ClawGuard가 호출을 규칙 집합에 대해 검사합니다. 평가된 구성에서 이 규칙들은 기본적인 접근 제어 제약(파일 경로 제한, 네트워크 호출 허용 목록, 자격 증명 접근 차단)입니다. ClawGuard는 주입 프롬프트가 아무리 그럴듯해도 이 제약을 벗어나는 모든 호출을 차단합니다.

아키텍처적 통찰을 명확히 말하면: 실행 경계에서 정책을 강제할 수 있다면 모든 주입을 탐지할 필요가 없습니다.

Vercel 텔레메트리 사건

ClawGuard 논문이 공개되기 4일 전인 4월 9일, Akshay Chugh가 Claude Code용 Vercel Plugin에 대한 공개를 발표했습니다.² 공개 시점의 발견 사항은 다음과 같습니다:

플러그인이 bash 명령 문자열을 telemetry.vercel.com으로 전송하는 훅을 등록했습니다.² ~/.claude/vercel-plugin-device-id에 저장된 영구 UUID가 이 명령 문자열을 기기에 연결했습니다.² 플러그인이 훅에 빈 문자열 매처를 사용해서, Vercel 프로젝트뿐만 아니라 모든 프로젝트에서 훅이 발동되었습니다.² 동의 메커니즘은 네이티브 UI가 아닌 프롬프트 주입을 사용해 사용자 동의를 획득했습니다.² 사용자가 VERCEL_PLUGIN_TELEMETRY=off를 설정하지 않으면 매칭된 모든 이벤트에서 텔레메트리가 발동되었습니다.²

Vercel은 4월 14일에 텔레메트리 우려를 해결하며 광범위한 매처와 프롬프트 기반 동의 메커니즘을 제거했습니다.²

Vercel 사건은 전통적 의미의 취약점이 아닙니다. 자격 증명을 탈취하는 것은 아닙니다. 하지만 런타임 방어가 해결해야 할 정확한 유형의 문제를 보여줍니다: 사용자가 의도한 것보다 넓게 발동하는 훅이, 사용자가 명시적으로 공유에 동의하지 않은 데이터를 수집하며, 네이티브 동의 UI를 우회하는 메커니즘을 통해 작동합니다.

“텔레메트리”를 “유출”로 바꾸면 아키텍처는 동일합니다. 지나치게 광범위한 매처를 가진 훅이 모든 프로젝트에서 실행되며 외부 엔드포인트로 데이터를 전송합니다. 텔레메트리와 공격의 차이는 의도인데, 의도는 런타임에서 감사할 수 없습니다.

논문에서 실무로: 실무자들이 이미 가진 것

ClawGuard는 실무자들이 비공식적으로 구축해온 것을 공식화합니다. Claude Code은 PreToolUse 및 PostToolUse 차단을 지원하는 훅 시스템을 제공합니다. 저는 파일 경로 제한 강제, 도구 입력 검증, 파괴적 작업에 대한 명시적 확인 게이팅을 수행하는 95개 이상의 훅을 운영하고 있습니다.³

제 훅과 ClawGuard의 비전 사이의 격차는 자동화입니다. 제 훅은 수작업으로 작성된 규칙입니다: MCP 입력에서 내부 IP 주소 차단, 프로젝트 디렉토리로 파일 쓰기 제한, git 강제 푸시에 승인 요구. 평가된 ClawGuard 구성은 수작업 훅과 성격이 비슷한 기본 접근 제어 규칙을 사용합니다. 논문에서 제안하는 태스크 특화 규칙 유도 구성 요소는 사용자의 명시된 목표에서 자동으로 제약 조건을 도출합니다.¹ “쓰기를 /etc로 차단”이라고 작성하는 대신, 프레임워크가 “로그인 모듈 리팩토링”이라고 기술된 태스크는 시스템 디렉토리에 대한 쓰기 접근이 필요하지 않다고 추론합니다. 이 구성 요소는 향후 과제로 남아 있습니다.

자동 제약 도출은 더 어려운 문제이며, ClawGuard의 태스크 특화 규칙 유도 구성 요소는 평가된 결과가 아니라 향후 과제입니다. 저자들이 실제로 평가한 기본 규칙 구성은 강력하지만 완벽하지는 않은 결과를 보여주었습니다: AgentDojo는 0%의 공격 성공률(ASR)을 달성했지만, SkillInject는 여전히 4.8-14%의 ASR을 보였고 MCPSafeBench는 모델에 따라 7.1-11.0%의 ASR을 나타냈습니다.¹ 수작업 규칙은 취약합니다 — 예상한 공격만 다룹니다. 도출된 제약은 예상하지 못한 공격도 다룰 수 있는데, 부정 집합(일어나면 안 되는 것)이 아닌 긍정 집합(일어나야 하는 것)에 기반해 작동하기 때문입니다.

자동 도출이 프로덕션에서 안정적으로 작동하는지는 미해결 질문입니다. 벤치마크는 통제된 환경입니다. 실제 에이전트 세션은 모호한 태스크, 다단계 도구 체인, 비정상적으로 보이지만 정당한 도구 호출을 수반합니다. 유효한 도구 호출을 차단하는 오탐이 발생하면 “에이전트 유용성을 저해하지 않는다”는 주장은 빠르게 무너질 것입니다.

계층적 방어 스택

런타임 방어는 단일 메커니즘이 아닙니다. 도구 기반 에이전트를 위한 실용적 스택은 최소 네 개의 계층으로 구성됩니다:

계층 1: 입력 검증. 실행 전 도구 호출 인수를 검사하는 훅. 내부 IP 주소 차단, 파일 경로 검증, 셸 메타문자 거부. 제 PreToolUse 훅이 이 계층에서 작동합니다. 오탐률은 낮지만, 알려진 악성 패턴만 포착합니다.

계층 2: 기본 규칙 시행. 접근 제어 규칙(경로 제한, 네트워크 허용 목록, 자격 증명 보호)에 기반해 허용된 도구와 인수 집합을 제한합니다. ClawGuard의 평가된 구성이 이 계층에서 작동합니다.¹ 논문은 이 계층과 다음 계층 사이에 위치할 태스크 범위 제약 도출도 제안하지만, 이 구성 요소는 향후 과제로 남아 있습니다. 입력 검증만으로는 부족한 범위를 보완하지만, 환경이 변할 때 규칙도 유지 관리해야 합니다.

계층 3: 출력 검사. 에이전트가 도구 결과를 처리하기 전에 검사하는 PostToolUse 훅. 데이터 유출을 포착하고, 비정상적 응답을 탐지하며, 예상치 못한 도구 동작을 플래그합니다. 중간자 포스트에서 출력 검사가 중요한 이유를 설명했습니다: 손상된 라우터가 생성 후 응답을 수정합니다.

계층 4: 세션 감사. 모든 도구 호출, 모든 인수, 모든 결과를 사후 검토를 위해 로깅. 예방 메커니즘이 아니라 탐지 메커니즘입니다. Akshay Chugh가 정확히 이런 종류의 감사를 통해 Vercel 텔레메트리 사건을 발견했습니다: 훅 설정을 읽고 훅이 무엇을 하는지 추적한 것입니다.²

어떤 단일 계층도 충분하지 않습니다. 입력 검증은 새로운 패턴을 놓칩니다. 태스크 범위 제약은 너무 제한적이거나 너무 느슨할 수 있습니다. 출력 검사는 지연을 추가합니다. 세션 감사는 피해가 발생한 후에야 문제를 포착합니다. 각 계층이 다른 계층이 남기는 틈을 메우기 때문에 스택이 작동합니다.

ClawGuard가 올바르게 짚은 점

논문은 실무자에게 중요한 세 가지 기여를 합니다:

정렬보다 결정론. 런타임 방어를 정렬 속성이 아닌 결정론적 메커니즘으로 프레이밍하는 것이 올바른 접근입니다. 정렬은 적대적 조건에서 약화되는 훈련 시점의 속성입니다. 결정론적 시행은 모델의 동작과 무관하게 유지되는 런타임 속성입니다. 학술적으로 들릴 수 있지만, 시스템의 보안 태세에 대해 무엇을 보장할 수 있는지를 바꿉니다.

채널 비의존적 시행. 웹 주입, MCP 주입, 스킬 파일 주입을 하나의 시행 지점으로 방어하는 것은 아키텍처적으로 건전합니다. 세 가지 주입 채널에 대해 세 가지 별도 방어를 구축하면 유지 관리 부담과 교차 지점의 틈이 생깁니다. 도구 호출 경계의 단일 시행 지점은 구조적으로 세 채널 모두를 포괄합니다.

모델 수정 불필요. 파인튜닝도 아키텍처 수정도 필요하지 않다는 것은, 제어할 수 없는 모델을 포함해 어떤 모델에서도 방어가 작동한다는 의미입니다. Claude Code, Codex CLI, 또는 다른 에이전트 프레임워크를 운영하는 오퍼레이터가 모델 제공자의 보안 업데이트를 기다리지 않고도 런타임 방어를 추가할 수 있습니다.

미해결 과제

ClawGuard는 벤치마크에서 테스트되었습니다. 프로덕션 에이전트 세션은 더 복잡합니다. 실무자가 자동 제약 도출에 의존하려면 몇 가지 질문이 남아 있습니다:

모호한 태스크. “이 프로젝트 좀 도와줘”는 어떤 도구나 경로가 범위 내인지 명시하지 않습니다. 모호한 목표에서 제약을 도출하면 정당한 호출을 차단하거나(너무 제한적) 위험한 호출을 허용할(너무 느슨한) 위험이 있습니다.

다단계 체인. 설정 파일을 읽고, API를 호출하고, 결과를 데이터베이스에 쓰는 에이전트는 복잡한 접근 패턴을 가집니다. 초기 태스크 설명에서 도출된 제약이 중간 단계를 예상하지 못할 수 있습니다.

적대적 태스크 설명. 제약 도출이 사용자의 명시된 목표에 의존한다면, 태스크 설명을 제어하는 공격자(공유 워크스페이스, 오염된 이슈 트래커, 조작된 프로젝트 파일을 통해)가 제약 자체에 영향을 미칠 수 있습니다.

성능 비용. 모든 도구 호출 경계에서 제약을 평가하면 지연이 추가됩니다. 논문은 프레임워크가 유용성을 유지한다고 주장하지만, 지연 측정치를 보고하지 않습니다.¹ 대화형 에이전트 세션에서는 도구 호출당 200ms만으로도 사용자 경험이 달라집니다.

실무 핵심 사항

현재 도구 기반 에이전트를 운영하는 실무자를 위한 조언입니다:

지금 바로 PreToolUse 훅을 배포하세요. ClawGuard나 다른 프레임워크를 기다릴 필요가 없습니다. Claude Code의 훅 시스템은 현재 도구 호출 차단을 지원합니다. 입력 검증부터 시작하세요: 내부 주소 차단, 파일 경로 제한, 파괴적 작업 게이팅. 훅 튜토리얼에서 구현을 다룹니다.

훅 매처를 감사하세요. Vercel 사건은 빈 문자열 매처가 모든 프로젝트에서 발동되었기 때문에 발생했습니다.² .claude/settings.json의 모든 훅을 검토하고 각 매처가 의도된 컨텍스트만 대상으로 하는지 확인하세요. 지나치게 광범위한 매처를 가진 훅은 방어가 아니라 부채입니다.

모든 도구 호출을 로깅하세요. 세션 감사는 노력 대비 가치가 가장 높은 방어 계층입니다. 모든 공격을 예방할 수 없더라도 사후에 탐지할 수 있습니다 — 로그가 있어야만 가능합니다.

ClawGuard를 기존 스택과 비교 평가하세요. 논문은 저장소 링크를 제공하지만, 작성 시점에 저자들은 아직 코드를 공개하지 않았습니다. 공개되면 기존 훅 스택과 비교해 기본 규칙 구성을 평가하세요. 태스크 특화 규칙 유도 구성 요소가 성숙하면, 자동 제약 도출은 수작업 규칙을 대체하는 것이 아니라 보완할 것입니다.

설정을 신뢰 경계로 취급하세요. 스킬 파일, 훅 설정, MCP 서버 정의: 에이전트 동작에 영향을 미치는 모든 파일이 공격 표면입니다. 프로덕션 자격 증명에 적용하는 것과 동일한 접근 제어를 적용하세요.

MCP 취약점 카탈로그가 공격 표면을 문서화했습니다. ClawGuard가 방어 아키텍처를 제안합니다. Vercel 사건이 둘 다 왜 중요한지 보여줍니다. 도구 호출 경계의 런타임 방어가 강제할 수 있는 계층입니다 — 정렬이 도움이 되지 않아서가 아니라, 시행은 정렬에 의존하지 않기 때문입니다.

출처

자주 묻는 질문

ClawGuard는 Claude Code의 내장 권한 시스템과 어떻게 다른가요?

Claude Code의 권한 시스템은 도구 수준 승인(도구 카테고리 승인 또는 거부)과 인수 수준 지정자(예: Bash(git diff *)로 일치하는 명령만 허용)를 모두 지원합니다. ClawGuard의 평가된 구성은 인수 수준에서 기본 접근 제어 규칙을 시행합니다. 제안된 태스크 특화 규칙 유도 구성 요소는 현재 태스크에서 인수 제약을 자동으로 도출하지만, 저자들은 이 구성 요소를 평가하지 않았습니다. 두 시스템은 상호 보완적입니다: Claude Code 권한은 어떤 도구와 인수 패턴이 실행될 수 있는지 게이팅하고, ClawGuard 스타일의 런타임 제약은 두 번째 시행 계층을 추가합니다.

런타임 방어를 추가하려면 ClawGuard 출시를 기다려야 하나요?

아닙니다. Claude Code의 훅 시스템은 현재 PreToolUse 및 PostToolUse 차단을 지원합니다. 도구 입력을 검증하는 수작업 훅이 가장 일반적인 공격 패턴을 즉시 다룹니다. ClawGuard의 기여는 자동 제약 도출이며, 수동 규칙을 대체하는 것이 아니라 보강합니다.

Vercel 텔레메트리 사건은 보안 취약점이었나요?

이 공개는 전통적 취약점이 아닌 개인정보 보호 및 동의 문제를 기술했습니다. 공개 시점에 플러그인은 모든 프로젝트에서 bash 명령 문자열을 수집해 네이티브 UI를 통한 명시적 옵트인 없이 외부 엔드포인트로 전송했습니다. Vercel은 이후 이 우려를 해결했습니다. 아키텍처 패턴(광범위한 훅 매처, 외부 데이터 전송, 비네이티브 동의)은 악의적 훅이 데이터 유출에 사용할 동일한 패턴을 반영하므로 여전히 교훈적입니다.

런타임 도구 호출 차단의 성능 영향은 어떤가요?

셸 스크립트나 경량 검증기를 사용하는 수작업 훅의 경우, 제 운영 경험상 오버헤드는 도구 호출당 200ms 미만으로 유지되어야 합니다. ClawGuard 논문은 제약 평가에 대한 지연 측정치를 보고하지 않으며, 추가 오버헤드가 발생할 수 있습니다. 대화형 세션에서는 도구 호출당 지연이 중요하므로, 복잡한 검증 로직을 배포하기 전에 테스트하세요.