MCP는 AI 에이전트의 USB-C가 되어가고 있습니다. 즉, 에이전트를 GitHub, Slack, Postgres, Stripe, 그리고 내부 도구에 연결할 수 있는 하나의 표준입니다. 좋습니다. 하지만 스위치를 켜기 전에 거의 아무도 확인하지 않는 것이 있습니다:

이 에이전트가 실제로 무엇을 할 수 있도록 허용되어 있는가?

공식 MCP 로드맵에는 현재 감사 추적(audit trails), 인증 강화(auth hardening), 게이트웨이 패턴(gateway patterns)이 기업용 미해결 과제로 나열되어 있습니다. 커뮤니티에서는 이미 "서버를 당신의 자격 증명(credentials)이 있는 호스트에 연결하기 전에 코드를 읽으라"고 말합니다. 하지만 수십 개의 도구에 대해 한 줄씩 실제로 그렇게 하는 사람이 누가 있을까요?

그래서 저는 MCPGuard를 만들었습니다. 에이전트의 도구 설정(tool config)을 읽고 다음과 같은 내용을 쉬운 용어로 알려주는 작은 오픈 소스 CLI입니다:

• 어떤 도구를 호출할 수 있는지, 실제 기능별로 그룹화하여 표시 (읽기 / 쓰기 / 삭제 / 전송 / 결제 / 관리)
• 도구별 및 전체 위험 점수 (risk score)
• 노출된 비밀 정보 (API 키, 토큰) — 마스킹 처리되어 표시
• 누락된 인증 및 암묵적으로 신뢰되는 도구
• 즉시 사용 가능한 YAML 형식의 권장 허용/확인/거부(allow/ask/deny) 정책

이것은 **정적 분석기 (static analyzer)**입니다. 설정을 읽을 뿐, 에이전트를 실행하거나 트래픽 사이에 위치하지 않습니다. 시스템을 망가뜨릴 일도 없고, 데이터를 신뢰해야 할 필요도 없습니다. 60초 안에 설치하고 스캔하세요:

pipx install git+https://github.com/sengchanhkano-prog/mcpguard.git

mcpguard scan my_config.json

Repo (MIT): https://github.com/sengchanhkano-prog/mcpguard

이것은 v1 버전이며 의도적으로 작게 제작되었습니다. 현재는 설정 / 도구 정의를 스캔합니다. 실시간 MCP 연결 (tools/list)은 새로운 스펙에 맞춰 로드맵의 다음 단계로 예정되어 있습니다.

실제 운영 환경(production)에서 에이전트를 실행하는 분들의 진솔한 피드백을 듣고 싶습니다:

1. 권한 위험(permission risk)이 실제로 걱정되는 부분인가요, 아니면 실제로는 문제가 되지 않는 부분인가요?
2. 실시간 스캔(실행 중인 MCP 서버에 연결하여 실제 도구를 가져오고 점수를 매기는 방식)이 유용할까요?
3. 어떤 도구에 대한 탐지 규칙을 가장 먼저 원하시나요?

가차 없이 비판해 주셔도 좋고, 무의미하다고 말씀해 주셔도 좋으며, 혹은 무엇이 이 도구를 유용하게 만들지 말씀해 주셔도 좋습니다. 어떤 것이든 도움이 됩니다.