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

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

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

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

정렬은 보안 경계가 아닌 이유

지난주 정리한 MCP 취약점 다수는 공통된 구조적 틈새를 악용합니다. 에이전트가 도구 설명, 가져온 웹 페이지, 스킬 파일에서 지시를 받으면, 그 인젝션과 실행 사이에 서 있는 유일한 방벽은 모델이 정당한 지시와 적대적 지시를 구별하는 능력뿐입니다. (일부 취약점 — SSRF, RCE, 경로 순회 — 은 모델의 지시 수행과 무관한 서버 측 결함을 악용하지만, 도구 호출 경계는 방어에 여전히 중요합니다.)

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

런타임 인터셉션은 완전히 다른 계층에서 작동합니다. 실행 전에 도구 호출을 검사하는 훅이나 정책 엔진은 모델이 공격을 이해했는지 여부에 의존하지 않습니다. 확인은 결정론적입니다: 호출이 허용된 세트와 일치하느냐, 그렇지 않느냐.

세 가지 인젝션 채널, 하나의 집행 지점

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

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

MCP 서버 인젝션. 손상되었거나 악의적인 MCP 서버가 도구 설명이나 응답 페이로드에 지시를 삽입합니다. 에이전트는 그 지시를 컨텍스트로 읽고 이에 따라 행동합니다. 지난주의 50개 취약점 목록이 이 채널을 광범위하게 문서화하고 있습니다.

스킬 파일 인젝션. 에이전트가 신뢰할 수 있는 컨텍스트로 로드하는 스킬 파일과 구성에 적대적 지시가 배치됩니다. 에이전트는 스킬 파일의 내용을 권위 있는 것으로 취급하므로, 스킬 파일이나 구성에 쓰기 권한이 있는 공격자는 에이전트의 동작을 지시할 수 있습니다.

방어 아키텍처는 도구 호출 경계에 집행 지점을 배치합니다 — 어떤 채널이 지시를 주입했든 모든 외부 행동이 반드시 통과해야 하는 단일 지점입니다.¹ 에이전트가 도구를 호출하기 전에, 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 force-push에 승인 요구. 평가된 ClawGuard 구성은 수동 작성 훅과 정신적으로 유사한 기본 접근 제어 규칙을 사용합니다. 논문에서 제안한 작업별 규칙 유도 컴포넌트는 사용자의 명시된 목적에서 자동으로 제약 조건을 도출할 것입니다¹ — “/ etc에 쓰기 차단” 대신, “로그인 모듈 리팩토링”으로 설명된 작업은 시스템 디렉토리에 대한 쓰기 접근이 필요하지 않다고 추론하는 것이죠. 이 컴포넌트는 아직 향후 과제로 남아 있습니다.

자동 제약 조건 도출이 더 어려운 문제이며, ClawGuard의 작업별 규칙 유도 컴포넌트는 평가된 결과가 아닌 향후 과제입니다. 저자들이 실제로 평가한 기본 규칙 구성은 강력하지만 완벽하지는 않은 결과를 보여주었습니다: AgentDojo에서는 공격 성공률(ASR) 0%를 달성했지만, 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의 권한 시스템은 도구 수준에서 사용자 승인을 요청합니다 — 특정 도구 카테고리를 승인하거나 거부하는 방식이죠. ClawGuard는 인수 수준에서 작동하여, 현재 작업을 기반으로 도구 호출에 어떤 인수가 포함되어야 하는지 자동으로 제약 조건을 도출합니다. 두 메커니즘은 상호보완적입니다: 권한은 어떤 도구가 실행될 수 있는지를 결정하고, 런타임 제약은 그 도구가 어떻게 호출될 수 있는지를 결정합니다.

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

아닙니다. Claude Code의 훅 시스템은 현재 PreToolUse와 PostToolUse 인터셉션을 지원합니다. 도구 입력을 검증하는 수동 작성 훅만으로도 가장 흔한 공격 패턴을 즉시 커버할 수 있습니다. ClawGuard의 기여는 자동 제약 조건 도출이며, 이는 수동 규칙을 대체하는 것이 아니라 보강하는 역할을 합니다.

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

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

런타임 도구 호출 인터셉션의 성능 영향은 어떤가요?

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