MCP 서버는 종종 어시스턴트와 API 사이의 편리한 어댑터로 소개됩니다. 보안 관점에서 볼 때, 이는 모델의 영향을 받은 요청을 수락하는 특권 게이트웨이입니다.

중요한 질문은 도구가 read_dashboard인지 아니면 fix_incident인지가 아닙니다. 중요한 것은 구현체가 어떤 신원(identities), 리소스(resources), 부수 효과(side effects), 그리고 네트워크에 접근할 수 있는지 여부입니다.

도구별 권한 목록화 (Inventory authority per tool)

Tool	Read scope	Write scope	Credential	Approval
get_metric	one tenant, named metric	none	read-only service token	none
...
Do not give every tool the server process's full credential. Split read and write identities, scope them to a tenant and resource class, and mint short-lived tokens near execution.

인수를 신뢰하지 않게 처리 (Treat arguments as untrusted)

const Restart = z.object({
  service: z.enum(["api", "worker"]),
  environment: z.literal("staging"),
...

엄격한 스키마는 예상치 못한 필드를 거부합니다. 하지만 서버 측 권한 부여(authorization)는 여전히 호출자, 테넌트, 현재 리소스 상태, 그리고 정책 버전을 검증해야 합니다. 모델이 제공하는 URL, 경로, 셸 조각(shell fragment), SQL 절(SQL clause), 또는 헤더를 원시적인 권한으로 절대 변환하지 마십시오.

결과가 중요한 호출(consequential calls)의 경우, 유효성 검사된 인수를 기반으로 생성된 미리보기를 보여주어야 합니다. 승인(approval)은 사용자, 도구 이름, 표준 인수(canonical arguments), 정책 버전, 리소스 버전, 그리고 만료 기한에 바인딩되어야 합니다. 변경 사항이 발생하면 다시 요청해야 합니다.

비밀 정보가 아닌 증거 기록 (Log evidence, not secrets)

요청 ID, 행위자(actor), 도구, 표준 인수 해시(canonical argument hash), 대상 리소스, 정책 결정, 자격 증명 신원(credential identity), 결과 클래스, 그리고 타이밍을 기록하십시오. 토큰, 쿠키, 자격 증명을 포함하는 프롬프트, 원시적인 타사 응답은 마스킹(redact) 처리해야 합니다. 중복된 operationId 호출이 부수 효과를 반복하기보다 원래의 결과를 반환하도록 만드십시오.

도구 출력에서의 프롬프트 주입(prompt injection), 크로스-테넌트 ID, 알 수 없는 인수, 오래된 승인(stale approval), 중복 전달(duplicate delivery), 성공적인 원격 쓰기 후 시간 초과, 자격 증명 취소, 그리고 로그 마스킹에 대한 테스트를 수행하십시오.

공개된 MonkeyCode repository는 모델 관리, AI 작업, 개발 환경 및 비공개 배포에 대해 설명합니다. MCP 스타일의 통합은 이러한 플랫폼과 관련될 수 있지만, 이 문서는 현재 MonkeyCode MCP 구현을 주장하거나 그 보안 테스트를 보고하지 않습니다.

공개 고지: 저는 MonkeyCode 프로젝트에 기여하고 있습니다. 제품 컨텍스트는 공개 문서에서 가져왔으며, 위협 모델은 도구 독립적입니다.

어떤 기능을 도구로 명명하는 것이 그것의 권위를 떨어뜨리지는 못합니다. 게이트웨이를 신뢰할 수 없는 입력이 노출된 모든 스키마에 도달할 수 있다고 가정하고 설계하십시오. 왜냐하면 결국 그렇게 될 것이기 때문입니다.