HOL Guard: 악성 MCP와 스킬로부터 AI 에이전트를 지키는 오픈소스 백신

AI 에이전트가 채팅창을 벗어나고 있다. 지난 한 해 동안 코딩 보조 도구는 셸 명령을 직접 실행하고, 로컬 파일을 읽고 쓰며, 의존성 패키지를 설치하고, MCP 서버를 통해 외부 도구를 호출하는 단계까지 나아갔다. 능력의 확장은 단순하지만 날카로운 질문을 낳는다. 프롬프트에 좌우될 수 있는 프로그램이 사용자의 터미널 권한을 쥐고 있을 때, 누가 문을 지킬 것인가. hashgraph-online이 공개한 HOL Guard의 답은 분명하다. AI 에이전트를 위한 오픈소스 백신이라는 위치 설정이다. 모델을 더 말 잘 듣게 만들려 하지 않고, 모델의 행동이 실제로 일어나기 직전에 모델과 독립된 로컬 계층이 먼저 살펴본다. 이 발상은 기존 엔드포인트 보안의 다층 방어와 같은 계보에 있으며, 검사 대상이 실행 파일에서 에이전트의 모든 행동으로 바뀌었을 뿐이다. HOL Guard의 동작 방식은 실행 전 검토로 요약된다. 대상 행동은 셸 명령, 파일 접근, 패키지 설치, MCP 도구 호출이며, 탐지하는 위험은 비밀 정보 노출, 파괴적 작업, 프롬프트 인젝션, 공급망 위험이다. 이후 사용자가 정한 정책에 따라 허용하거나 차단하거나 승인을 요청한다. 공식 문서는 보호 대상을 여섯 갈래로 정리한다. 셸 명령과 파일 접근, 패키지 설치, 플러그인과 스킬과 에이전트 설정, MCP 서버와 도구, 프롬프트와 도구 결과, 그리고 승인과 증거다. 마지막 항목이 특히 중요하다. 모든 결정은 로컬에 영수증으로 남고, 사용자는 명령줄과 로컬 대시보드에서 이력을 확인할 수 있다. 보안 결정이 일회성 팝업에서 되돌아볼 수 있는 기록으로 바뀌는 것이며, 사고 조사와 정책 조정 모두에 도움이 된다. 구조 면에서 HOL Guard는 로컬 우선 원칙을 고수한다. 계정 없이 동작하며, 에이전트에 연결되는 방식은 세 가지다. 각 에이전트가 제공하는 네이티브 훅, 관리형 MCP 프록시, 그리고 실행 시점 통합이다. 공식 문서는 보호 범위가 각 에이전트가 노출하는 이벤트에 달려 있다고 솔직하게 밝히고, 통합별로 강제력, 승인 전달 방식, 실패 시 동작을 적은 지원 매트릭스를 유지한다. 이 솔직함 자체가 공학적 미덕이다. 보안 도구에서 가장 위험한 상태는 사용자가 전면적으로 보호받는다고 믿는데 실제로는 훅을 걸 수 없는 이벤트 범주가 존재하는 경우다. 플러그인, 스킬, 설정에 대해서는 로컬 산출물의 목록을 만들고, 새로 추가되거나 바뀐 항목을 실행 전에 검토한다. 최근 반복해서 나타난 악성 스킬과 오염된 MCP 서버를 정면으로 겨냥한 기능이다.

도입 문턱은 낮다. Python 3.10 이상과 pipx만 있으면 되고, pipx install hol-guard 다음에 hol-guard init을 실행한다. 첫 실행 마법사는 기기에 있는 지원 에이전트를 찾아내고, 대시보드를 여는 일, 에이전트 통합을 설치하는 일, 선택형 클라우드에 연결하는 일처럼 변경이 있을 때마다 먼저 묻는다. 지원 에이전트는 Codex, Claude Code, GitHub Copilot CLI, Cursor, Cline, Gemini CLI, Grok, Hermes, Kimi Code, Pi, OpenClaw, OpenCode, Antigravity, Devin 등으로 폭넓고, Paseo는 이들 네이티브 제공자를 통해 지원된다. 팀 단위 기능이 필요하면 선택형 Guard Cloud가 공유 이력, 팀 정책, 플릿 관리를 더한다. 같은 저장소의 plugin-scanner는 확장 기능 자체를 설치 전에 검사한다.

평가에서는 한계도 분명히 적어야 한다. 첫째, 백신이라는 비유는 전달을 위한 편의일 뿐 기술적 등가물이 아니다. 기존 백신은 시그니처와 행동 감시에 의존하지만, 에이전트의 위험은 의미 층위에서 생긴다. 프롬프트 인젝션 판별은 본질적으로 확률적이어서 누락을 없앨 수 없다. 둘째, 훅의 적용 범위가 능력의 상한이다. 에이전트가 노출하지 않는 이벤트는 Guard도 볼 수 없다. 셋째, 승인 절차는 피로를 낳는다. 정책이 느슨하면 형식에 그치고, 지나치게 엄격하면 꺼지게 된다. 넷째, 공급망 판단은 외부 정보의 품질과 최신성에 좌우된다. 이는 결함이 아니라 이 범주의 모든 도구가 마주하는 제약이며, 핵심은 프로젝트가 이를 문서에 정직하게 드러내는가이다. 공개 자료를 보면 그렇게 하고 있으며, Apache-2.0 라이선스, 지속적 통합, 컨테이너 이미지, OpenSSF Scorecard 배지 같은 탄탄한 공학적 신호도 갖추고 있다.

독자에게 주는 실무 조언은 이것을 다층 방어의 한 층으로 다루라는 것이다. 개인 개발자는 가장 자주 쓰는 에이전트 하나에서 먼저 켜고, 일주일쯤 차단 기록을 살핀 뒤 정책을 단계적으로 조이면 된다. 팀은 비밀 정보 분리, 최소 권한, 샌드박스를 그대로 유지하면서 Guard에게 행동 전의 감사 가능한 관문 역할을 맡기는 것이 좋다. 길게 보면 에이전트 보안은 모델 정렬의 주제에서 운영체제에 가까운 권한과 감사의 문제로 옮겨 가고 있다. HOL Guard의 가치는 이 이동을 오늘 설치하고 내일 로그를 돌아볼 수 있는 구체적 도구로 만들었다는 데 있다. 추상적인 호소보다 훨씬 실행에 가까운 안전장치다.