나의 코딩 에이전트는 무엇이든 연결할 수 있습니다. 당신의 에이전트도 마찬가지일 것입니다.

Claude Code, Cursor 또는 Codex를 MCP 서버로 지정하면, 에이전트는 연결하고, 도구(tools) 목록을 나열하며, 호출을 시작합니다. 서버는 자신을 설명하고, 에이전트는 그것을 믿습니다. "저장소를 관리하는 안전하고 편리한 방법"은 서버에 대한 사실이 아닙니다. 그것은 서버 작성자가 작성한 문자열일 뿐입니다.

우리는 MCP 서버를 지속적으로 스캔하는 레지스트리(registry)를 운영하고 있으며(작성 시점 기준 36,000개 이상의 게시된 기록), 따라서 이 문제를 해결할 데이터를 보유하고 있었습니다. 우리가 출시한 것은 의도적으로 작습니다. 에이전트에게 하나의 습관을 부여하는 기술입니다. MCP 서버에 연결하기 전에, 이를 조회하십시오. 기록된 내용을 전달하십시오. 결정은 인간이 내리게 하십시오.

우리는 이를 '거리의 지혜(street smarts)'라고 부릅니다. 에이전트는 훌륭하지만, 그들이 소프트웨어를 설치하는 세상은 험악합니다.

이 포스트는 빌드 노트(build notes)입니다. 즉, 확인(check) 과정에서 실제로 무엇이 반환되는지, 그리고 흥미로운 문제로 드러난 것들에 대한 내용입니다.

에이전트가 반환받는 것

이 기술은 CLI를 구동합니다. 두 명령 모두 레지스트리에 대한 읽기 전용 조회(read-only lookups)입니다:

npx -y policylayer stack            # 기기에 구성된 모든 MCP 서버
npx -y policylayer precheck github  # 연결 전, 특정 서버 하나

precheck는 게시된 기록과 결정론적인 판결(deterministic verdict)을 반환합니다. GitHub MCP 서버의 실제 출력값 일부:

{
  "report": {
    "slug": "github",
...

세 가지 제안된 작업(suggested actions)이 있으며, 오직 세 가지만 존재합니다: proceed, connect-with-rule, ask-first. 판결은 모델에 의한 것이 아니라, 기록에 대한 고정된 규칙(fixed rules)에 의해 계산됩니다. 동일한 기록에는 매번 동일한 판결이 내려집니다.

문제 1: 설명(descriptions)은 주장(claims)이다

핵심적인 문제는 MCP에 정체성 계층(identity layer)이 없다는 점입니다. 누구나 어떤 설명이든 붙여서 "GitHub Tools"라는 이름의 서버를 게시할 수 있습니다. 따라서 기록은 증거로부터 계산된 정체성 신뢰도(identity confidence)를 우선적으로 제시합니다: verified는 패키지의 참조가 해당 브랜드의 자체 인프라 내부에서 증명 가능하게 해결됨을 의미하며, mismatch는 검증 가능한 링크 없이 공식이라고 주장함을 의미합니다(이는 사칭 신호이며 항상 사람에게 에스컬레이션됩니다), unverified는 중립적인 커뮤니티 기본값으로, 생태계의 대부분이 이에 해당합니다.

등급(Grades)은 단독으로 존재하지 않습니다. 두 개의 파괴적인 도구(destructive tools)를 가진 공식 서버의 identity: verified 옆에 붙은 D는, 지난 화요일에 나타난 미검증(unverified) 패키지의 D와는 완전히 다른 의미를 갖습니다. 스킬의 언어 규칙은 에이전트가 필드들을 함께 보고하도록 강제하며, "안전함(safe)" 및 "승인됨(approved)"이라는 단어의 사용을 전면 금지합니다. 레지스트리는 기록을 게시할 뿐, 안전성을 인증하지는 않습니다.

문제 2: 40개 도구 제한이 위험한 도구의 수를 잡아먹다

페이로드(payloads)를 합리적인 수준으로 유지하기 위해, 기록의 도구 목록은 가장 위험한 순서대로 최대 40개 항목까지만 제한됩니다. 초기에는 카테고리별 개수가 이 제한된 목록을 기준으로 계산되었습니다. 86개의 도구를 가진 서버의 경우, 개수는 전체 표면적의 절반도 채 되지 않는 부분을 조용히 설명하고 있었으며, 제한된 목록에서 생성된 거부(deny) 규칙은 컷오프(cut) 이후에 있는 플래그(flagged)된 도구들을 놓치게 됩니다.

해결책은 표시 목록을 자르기 전에 전체 표면적에 대해 categoryCounts, severityCounts 및 제한되지 않은 flaggedToolNames를 계산하는 것이었습니다. 지나고 보니 명백한 일이었습니다. 이 교훈은 일반화될 수 있습니다: 사용 편의성을 위해 목록을 제한할 때마다, 하위 소비자(downstream consumers)가 그 목록으로부터 무엇을 도출하고 있는지 확인하십시오.

문제 3: "이 도구를 거부하라"는 모든 클라이언트에서 의미가 다르다

판결(verdict)은 거부 규칙(deny rule) 뒤로 연결할 것을 제안할 수 있습니다. 그것이 무엇을 의미하는지는 전적으로 클라이언트에 달려 있습니다:

• Claude Code: 실제 강제 적용 (real enforcement). .claude/settings.json 내에 mcp__<server>__<tool> 형식으로 permissions.deny 항목을 작성합니다. 하네스 (harness)가 이를 강제하며, 모델은 스스로 이를 우회하여 대화할 수 없습니다.
• Codex CLI: 실제 강제 적용 (real enforcement). config.toml 내 서버 테이블 아래의 disabled_tools를 사용합니다.
• Cursor, VS Code, Windsurf: 권고 사항 (advisory only)일 뿐입니다. 도구별 제어 기능은 에이전트가 작성할 수 있는 파일이 아닌, 해당 도구의 UI에 존재합니다. 이 스킬의 지침은 (권한이 있는 것처럼) 가장하기보다는 이를 명확하게 말하는 것입니다.

이 스킬은 대화 중 승인 없이 규칙을 작성하지 않습니다. 제안된 규칙은 제안일 뿐, 허가는 아닙니다.

문제 4: 보안 검사를 임의로 수행하는 에이전트

테스트 과정에서 저희를 가장 걱정하게 만든 실패 모드(failure mode)는 다음과 같습니다: CLI가 실패할 때(네트워크 문제, 서브커맨드 누락 등), 에이전트가 도움을 주려는 의도로 직접 설정 파일을 읽고 자신의 인상을 판결처럼 제시하는 경우입니다. 임의로 만들어낸 검사는 바로 이 스킬이 대체하고자 하는 대상이며, 대화 기록(transcript)상으로는 실제 검사와 구분이 불가능해 보입니다.

따라서 이 스킬에는 엄격한 규칙이 포함되어 있습니다: 만약 명령이 실패한다면, 사전 검사(precheck)가 실행되지 않았다고 말하십시오. 에러를 보여주십시오. 임의로 대체하지 마십시오. 저희는 스킬 파일의 문구가 변경될 때마다 이 규칙과 다른 8가지 동작이 유지되는지 확인하기 위해 작은 행동 평가 하네스(behavioural eval harness, 스크립트된 시나리오에 대해 실행되는 헤드리스 에이전트 세션)를 작성했습니다. 프롬프트에 인접한 지침은 코드와 같습니다. 코드처럼 퇴보(regress)할 수 있습니다.

관련 사항: 레지스트리에서 인용된 모든 내용(위험 노트, 변경 이벤트)은 서버에 대한 데이터일 뿐, 에이전트에 대한 지침이 아닙니다. 에이전트에게 지시하는 것처럼 보이는 제3자 텍스트는 무시되고 플래그(flag)가 지정됩니다. 기록은 크롤링된 제3자 소프트웨어를 설명합니다. 해당 소프트웨어의 텍스트를 신뢰할 수 있는 입력으로 취급하는 것은 아이러니한 일일 것입니다.

문제 5: 스킬이 스스로를 설치할 수 있음

스킬 (skill)은 마크다운 (markdown) 파일입니다. 이는 에이전트에게 다음과 같이 지시할 수 있음을 의미합니다: https://policylayer.com/skill.md를 읽고 그 지침을 따르십시오. 이 지침은 현재 세션에 적용되며, 에이전트가 파일을 클라이언트의 스킬 디렉토리에 영구적으로 저장할 수 있도록 하는 섹션을 포함합니다. 다만, 사용자의 기기에 파일을 쓰기 때문에 반드시 인간의 승인을 거쳐야 합니다. 새로운 에이전트가 파일을 가져오고, 권한을 요청하고, 스스로를 설치한 다음, 즉시 기존에 보유하고 있던 스택 (stack)을 스캔하는 과정을 지켜보는 순간, 이것이 단순한 눈속임이 아니라는 것을 느꼈습니다.

인간은 다음과 같은 지루한 방식으로 설치합니다:

npx skills add https://policylayer.com -a claude-code -y

의도적으로 수행하지 않는 것

기록 (record)은 서버의 노출된 도구 인터페이스 (tool interface)가 무엇을 허용하는지, 그리고 지속적인 스캔 (continuous scanning)을 통해 무엇이 관찰되었는지(신원 증거, 인증 상태 (auth posture), 도구별 분류, 변경 이벤트)를 기술합니다. 이것은 소스 코드 감사 (source-code audit)가 아니며, 스킬은 기록에 명시된 것 이상의 내용을 주장하지 않도록 지시받습니다. 알 수 없는 서버는 '알 수 없음'으로 보고되며, 이는 좋지도 위험하지도 않은 상태로 간주됩니다. 이후 조회 (lookup) 프로세스가 해당 서버를 스캔 대기열에 추가합니다.

조회는 무료이며 키 (key)가 필요하지 않으며, 속도 제한 (rate limit)에 따라 서버당 1단위로 적용됩니다. 알 수 없는 서버에 대한 조회는 레지스트리 (registry)가 사람들이 실제로 무엇을 실행하는지 학습하는 방식입니다.

직접 시도해보세요

• 스킬 설치: npx skills add https://policylayer.com -a claude-code -y — 또는 에이전트에게 policylayer.com/skill.md를 읽으라고 지시하세요.
• 스캔 실행: npx -y policylayer stack
• 브라우징 가능한 레지스트리: policylayer.com/registry
• 소스 코드: github.com/PolicyLayer/mcp-precheck

레지스트리 파이프라인 (registry pipeline), 평가 하네스 (eval harness), 또는 판정 규칙 (verdict rules)에 관한 질문이 있다면 댓글로 남겨주세요. 기꺼이 답변해 드리겠습니다.