도구를 등록할 때의 통제와 명령을 실행할 때의 통제는 역할과 시점이 다릅니다.
GitLab 버그 리포트는 이 실패 양상을 정확히 짚습니다. "mcp_client 기능 플래그가 켜지면 에이전트가 정의한 toolset과 무관하게 MCP 도구가 모든 기반 에이전트에 기본으로 주입된다"는 것입니다. 최소한의 toolset만 쓰도록 범위를 좁혀 둔 "Data Analyst" 에이전트에도 관련 없는 도구가 예상치 못하게 딸려 왔고, 그중 두 개는 설명 자체에 "[UNTRUSTED SOURCE — READ BEFORE USING]"라는 경고를 달고 있었습니다. 리포터가 기대한 것은 단순했습니다. MCP 도구가 각 에이전트에 설정된 toolset을 따라야 한다는 것입니다. (GitLab issue #583935)
GitLab만의 버그는 아닙니다. MCP 클라이언트가 서버의 모든 도구를 연결된 에이전트에 그대로 등록하고, 도구 노출을 별도의 권한 결정으로 다루지 않으면 같은 일이 생깁니다. 에이전트의 작업에 필요하지 않은 도구까지 프롬프트 인젝션의 표적이 될 수 있습니다.
도구가 많아지면 성능도 떨어집니다
도구를 그대로 다 등록해 두면 에이전트의 작업 성능도 나빠집니다. 전체 도구 표면을 그대로 실은 GitHub 공식 MCP 서버는 시스템 프롬프트나 작업 내용 한 줄을 넣기도 전에, 도구 정의만으로 토큰 약 42,000개를 씁니다. 한 실무자가 직접 집계한 수치입니다. 해당 글은 그 결과를 구체적으로 추적합니다. 과부하 상태의 에이전트는 "명백한 도구 선택을 놓치고", "존재하지 않는 파라미터를 지어내고", "단순한 작업에도 엉뚱한 도구를 고릅니다." 도구 10개를 등록했을 때는 멀쩡히 돌던 작업이 50개가 되는 순간 깨집니다. (dev.to, "MCP tool overload")
도구 노출 범위를 좁히는 이유는 보안에만 있지 않습니다. 필요한 도구 열 개만 보는 에이전트가 쉰 개의 도구를 모두 보는 에이전트보다 작업을 더 안정적으로 처리할 수 있습니다. 이 경우 최소 권한과 작업 성능은 같은 방향을 가리킵니다.
에이전트에 필요한 만큼만 등록하기
도구를 선택해 등록하는 기능은 GitHub의 공식 MCP 서버의 정식 문서화된 --toolsets 플래그와 alpacon-mcp 로컬 모드(v0.8.0, 2026-07-30)에서 제공합니다. 운영자는 MCP 서버가 노출하는 도구를 전부 등록하는 대신, 클라이언트에 등록할 도구 그룹을 직접 고릅니다. 로컬 모드는 선택한 toolset만 등록합니다. 클라이언트가 알지 못하는 도구는 프롬프트 인젝션의 지시나 잘못된 도구 선택으로 호출될 수 없습니다.
레이어는 두 개입니다
MCP 최소 권한은 에이전트 생애주기의 서로 다른 두 지점에서 작동합니다. 하나는 클라이언트가 에이전트에 어떤 도구를 등록할지 정하는 일입니다. 다른 하나는 등록된 도구가 호스트 명령을 실행할 때 그 명령을 무엇이 판단할지 정하는 일입니다. 첫 번째는 등록 시점 통제입니다. 명령이 하나도 실행되기 전에 에이전트가 볼 수 있는 도구를 정합니다. 두 번째는 실행 시점 통제입니다. 도구가 호스트 명령을 실행할 때마다 그 명령을 판단합니다. 등록 시점의 범위 제한은 필요하지만 첫 번째 질문에만 답합니다.
첫 번째 질문은 클라이언트가 애초에 어떤 도구를 볼 수 있느냐입니다. --toolsets가 등록 시점에, 에이전트가 명령을 한 번이라도 내리기 전에 답하는 질문입니다.
두 번째 질문은 에이전트가 호출한 도구가 호스트에서 명령을 실행하는 순간 무슨 일이 일어나느냐입니다. Alpacon의 명령 판단이 켜져 있는 환경에서는 그 명령이 호스트에 닿기 전에 Alpacon의 exec lane을 거칩니다. 도구가 등록된 시점이 아니라 실행되는 시점입니다. 규칙(Tier 1, 패턴 40개 이상), 기준선 점검(Tier 1.5), 회색 지대에 대한 LLM 의도 판단(Tier 2, 위험도 0.3~0.8 구간 안팎)까지 3단계로 검증하는 엔진입니다.
등록만 제한한 환경에서는 도구가 호스트에서 실행하려는 명령을 실행 시점에 판단하지 못합니다. 반대로 명령 판단만 두면 에이전트가 처음부터 어떤 도구에 접근할 수 있는지 줄여 놓지 못해, 전체 도구 표면이 프롬프트 인젝션에 노출됩니다. exec lane이 회색 지대로 판단한 명령은 실행 전에 별도 채널의 사람 승인을 기다리게 할 수 있습니다. 두 통제 중 하나만 적용하면 공백이 남고, 공백의 성격은 빠진 통제에 따라 달라집니다.
이 구분이 중요한 이유는 같은 생태계에서 다른 형태의 과신 실패도 이미 확인됐기 때문입니다. 2026년 4월 OX Security는 MCP STDIO 결함을 공개했습니다. 보고서는 정제되지 않은 명령 실행과 실행 경계 부재를 핵심 문제로 짚었고, 취약 인스턴스 약 20만 개 추정과 공개 IP에서 실제 접근 가능한 인스턴스 약 7천 개를 제시했습니다. 도구를 지나치게 많이 등록하는 문제와는 다른 실패 지점이지만, 실무 교훈은 같습니다. 기본값이 전제한 신뢰를 프로덕션에서는 그대로 확장할 수 없습니다.
에이전트를 연결하기 전, 무엇을 확인해야 할까요?
오늘 에이전트를 MCP 서버에 연결한다면, 이 글의 논지는 실무적으로 두 가지 질문으로 좁혀집니다.
- 클라이언트가 이 에이전트의 작업에 실제로 필요한 도구만 등록합니까, 아니면 서버의 전체 표면을 기본으로 등록합니까?
- 도구가 명령을 실행하기 전에, 그것을 판단하는 장치가 있습니까? 아니면 등록 시점의 범위 제한이 유일한 통제입니까?
실행 시점에 판단하는 장치가 없다면, 잘 짜인 toolset도 실질적인 역할을 하긴 합니다. 에이전트가 애초에 손을 뻗을 수 있는 범위를 좁히는 유일한 장치이기 때문입니다. 다만 두 통제는 서로를 대신하지 못합니다. 가장 견고한 구성은 등록 시점의 toolset과 실행 시점의 명령 판단을 함께 갖추는 것입니다.
