우리가 자동화된 MCP 보안 스캐너를 구축한 방법 (그리고 우리가 발견한 것)

Source: Dev.to

우리가 해결하고자 했던 문제

MCP 서버를 설치하면 AI 에이전트에 새로운 기능을 부여하게 됩니다. 그 서버는 파일 시스템을 읽거나, 셸 명령을 실행하거나, 외부 API를 호출할 수 있습니다. 하지만 그 코드가 여러분의 머신에서 실행되기 전에 누가 감사를 했을까요?

아무도 없습니다. 지금까지는요.

AgentAudit에서는 MCP 서버, npm 패키지, pip 패키지, 그리고 AgentSkills를 자동으로 감사하고, 에이전트가 이를 사용하기 전에 보안 위험을 표시하는 다중‑에이전트 파이프라인을 구축했습니다.

아키텍처

우리의 감사 파이프라인은 서로 다른 보안 관점을 가진 세 개의 특화된 서브‑에이전트를 병렬로 실행합니다:

에이전트 1: 정적 분석

알려진 취약점 패턴을 소스 코드에서 스캔합니다:

• 사용자 입력을 그대로 사용하는 셸 명령 주입 (child_process.exec)
• 하드코딩된 자격 증명 및 API 키
• 과도하게 넓은 파일 시스템 접근 권한
• 안전하지 않은 역직렬화

에이전트 2: 기능 그래프 분석

MCP 서버의 tool schema declarations—각 도구가 할 수 있는 일을 설명하는 JSON—를 파싱하고, 실제 코드가 수행하는 일과 교차 검증합니다.

날씨 데이터를 읽는다고 선언했지만 내부적으로 파일 시스템에 접근할 수 있는 날씨 MCP 서버? 이것은 레드 플래그입니다. 우리는 그 차이를 포착합니다.

에이전트 3: 의존성 체인 감사

의존성 트리를 재귀적으로 스캔하여:

• 전이적 의존성에 존재하는 알려진 CVE
• 지나치게 넓은 권한을 가진 패키지
• 공급망 이상 현상(예: 2주 전에 유지보수자가 바뀐 패키지)

다중‑에이전트 합의

각 에이전트는 구조화된 감사 보고서를 생성합니다. 합의 레이어는 다음을 수행합니다:

• 중복 제거: 겹치는 발견 사항을 하나로 합침
• 심각도 할당: 에이전트 컨텍스트에서의 악용 가능성을 기준으로 심각도 부여
• 신뢰 점수 생성: 패키지에 대해 0–100 점의 Trust Score 부여

왜 다중‑에이전트 합의가 필요할까요? 단일 모델은 환각을 일으킵니다. 서로 다른 시스템 프롬프트를 가진 세 모델이 서로 교차 검증하면 환각을 방지할 수 있습니다.

결과 (현재까지)

194개의 패키지에 대해 211개의 독립적인 감사 보고서를 실행한 결과:

평균 신뢰 점수: 98/100. MCP 생태계는 대부분 안전하지만, 14개의 Critical/High 발견은 실제로 악용 가능한 취약점을 의미합니다.

가장 흔한 패턴

• 프롬프트 입력을 통한 셸 명령 주입 — 조작된 프롬프트가 MCP 서버가 임의의 셸 명령을 실행하도록 함
• 환경 변수 누출 — API 키가 실수로 LLM 컨텍스트 창에 포함됨
• 과도하게 넓은 파일 시스템 접근 — 하나의 디렉터리만 필요함에도 전체 ~/ 접근을 요청하는 서버

MCP 보안이 다른 점

전통적인 스캐너(Snyk, Socket)는 알려진 CVE와 공급망 위험을 탐지하는 데 뛰어납니다. 그러나 MCP 서버는 전혀 다른 위협 모델을 가집니다:

• 공격 벡터는 프롬프트이며, 네트워크가 아닙니다
• ‘사용자’는 AI 에이전트 — 의심스러운 행동을 인식하지 못합니다
• 실행 컨텍스트는 여러분의 로컬 머신 또는 프로덕션 서버입니다

패키지가 모든 전통적인 보안 검사를 통과하더라도, 적대적인 프롬프트를 통해 여전히 악용될 수 있습니다. 바로 우리가 메우고자 하는 격차입니다.

사용해 보기

어떤 MCP 서버, npm 패키지, 혹은 pip 패키지도 **agentaudit.dev**에서 감사해 보세요.

전체 결과: State of MCP Security 2026

모든 발견은 여러분에게 전달되기 전에 세 개의 독립적인 AI 에이전트에 의해 교차 검증됩니다.