메인 콘텐츠로 건너뛰기
서드파티 MCP 서버는 검토되지 않은 툴 묶음, 라이브 자격 증명, 그리고 새로운 네트워크 도달 범위입니다. 에이전트가 하나에 직접 다이얼하는 순간, 아무도 그 호출을 보고 있지 않습니다 — 그리고 “서버가 승인 후 툴을 변경했다”는 가설이 아니라 실제 공격입니다. 다른 누군가가 운영하는 서버에 에이전트를 가리키기 전에, 반복 가능한 사전 점검을 원합니다. 이 페이지가 그 사전 점검입니다: 이미 존재하는 통제 — 호출별 평가, 기본 거부 허용 목록화, egress 한도, 암호화된 자격 증명, 그리고 스킬 격리 — 를 사용하여 OrcaRouter에서 mcp 서버 연결을 검증하는 짧고 정렬된 체크리스트. 각 단계는 깊이를 위한 집중 how-to로 링크합니다. 새 서버당 한 번 실행하세요; 서버가 변경될 때마다 드리프트에 민감한 단계를 다시 실행하세요.
여기의 모든 구성 단계는 콘솔(또는 세션/액세스 토큰을 사용하는 REST API)에서 수행되며 역할로 제한됩니다. firewall 게이트웨이 라우트와 /v1/* 릴레이 호출만 sk-orca-... 스타일 키를 사용합니다.

1. mcp 서버 연결을 검증하는 체크리스트

위에서 아래로 작업하세요. 처음 세 단계는 당신이 직접 운영하지 않는 어떤 서버에든 필수입니다; 나머지는 그것을 하드닝합니다.

1. 신뢰하기 전에 프로빙

규칙 하나 작성하기 전에 실제 툴 목록과 도달 가능성을 발견합니다.

2. 기본 거부한 다음 허용 목록

검토한 툴만 허용; 나머지 모두는 거부됩니다.

3. 자격 증명 암호화

인증을 저장 시 암호화, 읽기 시 마스킹, 결코 모델이 보지 못하게 저장합니다.

4. Egress 잠그기

서버의 툴이 네트워크에서 도달할 수 있는 곳을 제약합니다.

5. 자체 설치된 스킬 격리

에이전트가 스스로 설치하는 모든 것을 사람이 검토할 때까지 보류합니다.

6. 먼저 shadow한 다음 관찰

audit 전용으로 롤아웃한 다음, 강제하기 전에 이벤트와 이상 징후를 읽습니다.

2. 신뢰하기 전에 프로빙

본 적 없는 툴을 검토할 수 없으며, 서버의 광고된 툴 목록은 당신 모르게 변경될 가능성이 가장 높은 것입니다. 서버를 등록한 다음, 그것을 프로브하세요 — 게이트웨이가 엔드포인트에 대해 MCP initialize + tools/list를 실행하고 실제 툴을 그 입력 스키마와 함께, 그리고 ok, degraded, 또는 down의 도달 가능성 status와 함께 반환합니다.
# 콘솔 라우트, 세션/액세스 토큰(UserAuth)으로 호출됨. Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
모든 툴 이름과 그 인자가 무엇을 받아들이는지 읽으세요. 예상하지 못한 shell.exechttp_fetch를 광고하는 서버는 세부 사항이 아니라 발견 사항입니다 — 그것이 먼저 프로빙하는 것의 전체 핵심입니다.
서버가 손을 바꾸거나 드리프트가 의심될 때마다 다시 프로빙하세요. 목록에 나타나는 새 툴 — “러그풀” — 이 바로 당신이 감시하는 것입니다. 러그풀 방어를 참조하세요.
전체 등록 및 프로브 레퍼런스는 Firewall: MCP 서버에 있습니다; 엔드투엔드 워크스루는 MCP 서버 연결하기 입니다.

3. 기본 거부한 다음 검토한 툴 허용 목록

허용 목록은 “서버가 여섯 가지를 할 수 있다”와 “서버가 그 운영자가 내일 결정하는 무엇이든 할 수 있다”의 차이입니다. 정책의 default_verdictdeny로 설정한 다음, 검토하고 신뢰하는 툴당 규칙을 추가하세요. 게이트웨이가 모든 툴을 <server>.<tool>로 네임스페이스 처리하므로, 다른 서버를 건드리지 않고 한 서버로 규칙을 범위 지정할 수 있습니다.
// mcp 표면의 정책: 기본 거부, 검토한 것만 허용.
// tool_name_glob은 full-segment 와일드카드를 지원합니다: "github.*"(접두),
// "*.exec"(접미), 또는 "*.shell.*"(중위). "github.get_*" 같은 중간 세그먼트
// 글로브는 정확한 매칭으로 폴백되며 확장되지 않습니다.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
이제 github.create_issue가 실행되고, github.get_issue가 실행되며, 새로 도입된 github.delete_repo는 당신이 검토하고 허용할 때까지 거부됩니다. 거부된 tools/call은 모델에 툴 오류(firewall deny: …)로 돌아옵니다 — 에이전트는 크래시하는 대신 적응합니다. 전체 레시피는 MCP 툴 허용 목록을, 매칭 DSL은 Firewall 규칙을 참조하세요.

4. 자격 증명 암호화 — 결코 직접 인증을 만들지 마세요

서드파티 서버는 거의 항상 자격 증명을 필요로 하며, 자격 증명은 평문으로 앉아 있거나 모델에 도달하는 것을 가장 원치 않는 것입니다. 서버의 인증을 OrcaRouter를 통해 등록하여 저장 시 암호화, 읽기 시 마스킹, 그리고 디스패치 시에만 주입되게 하세요. auth_modenone, bearer, oauth, 또는 basic 중 하나입니다:
# 콘솔 라우트, UserAuth, Developer+.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}"
  }'
자격 증명은 저장되는 순간 암호화되고 마스킹됩니다 — 그것은 결코 모델이나 클라이언트에 도달하지 않으며, 읽기 시 마스크만 보입니다. 업데이트 시 저장된 값을 유지하려면 마스크를 그대로 돌려보내세요; 교체할 때만 새 auth_json을 보내세요. 인증자격 증명 교체를 참조하세요.

5. Egress 잠그기: 그 툴은 어디까지 도달할 수 있나?

호출별 판정은 어느 툴이 실행되는지 결정합니다; egress는 어디까지 도달할 수 있는지 결정합니다. “데이터를 반환하는” 툴과 “당신의 시크릿을 공격자 호스트로 유출하는” 툴은 다른 인자를 가진 같은 툴일 수 있습니다 — egress 통제가 그것들을 구별하는 것입니다. 게이트웨이는 이미 모든 원격 엔드포인트와 그 해석된 다이얼 IP를 모든 홉에서 SSRF 정책에 대해 검증하며, 인트라넷 범위와 클라우드 메타데이터 주소를 거부하고 DNS 리바인딩을 무력화하기 위해 IP를 다시 검사합니다. 그 위에, 이 서버가 결코 건드리지 말아야 할 호스트와 CIDR에 대해 자체 egress deny 규칙을 작성하세요:
// egress-stage 규칙은 그 판정을 아웃바운드 목적지로 범위 지정합니다.
// egress_json은 host/CIDR allow + deny 목록을 담습니다.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
당신을 위해 CIDR 규칙을 제공하는 프리셋은 없습니다 — 이 서버가 정당하게 필요로 하는 것으로 범위 지정하여 host/CIDR 거부 목록을 직접 작성하세요. Egress 한도데이터 유출을 참조하세요.

6. 에이전트가 스스로 설치하는 것을 격리하기

등록한 서버는 하나의 위험입니다; 에이전트가 그 후 자체 설치하는 스킬, BYO MCP 서버, 그리고 플러그인은 또 다른 위험입니다. OrcaRouter는 모든 설치 가능한 기능을 스캔하고, 위험 밴드를 할당하며, 모든 규칙 판정 위에 올라타는 강제 모드 — allow, quarantine, 또는 block — 를 도출합니다. 첫 사용 시 자동 탐지된 모든 것은 사람이 검토할 때까지 격리됩니다: 아무도 승인하지 않은 기능은 무해하게 스캔되었다는 이유만으로 무료 통행권을 얻지 못합니다. quarantine 기능은 deny에 못 미치는 모든 것을 pending_approval로 에스컬레이션하므로, 그 툴은 당신이 살펴본 후에만 실행됩니다.
모든 스킬을 손으로 등록하려 하지 마세요. 신뢰하는 것을 사전 승인하고 나머지는 자동 탐지 및 격리되게 하세요 — 그런 다음 실제 데이터로부터 검토하세요. 모드는 재스캔 시 더 엄격하게 래칫되며, 결코 더 느슨해지지 않습니다. Firewall: 스킬MCP 툴 포이즈닝을 참조하세요.

7. 먼저 shadow한 다음 추적을 관찰하기

새로 만든 서버를 곧장 강제로 전환하지 마세요. 정책을 shadow 모드에 두세요 — 강제 판정이 audit로 다운그레이드되고 [shadow] would …로 로깅됨 — 그래서 실제로 차단되기 전에 무엇이 차단될 것인지 볼 수 있습니다. 감사 추적이 옳아 보이면, shadow 모드를 떨어뜨리고 강제하세요. 라이브된 후, 통제는 계속 감시합니다:
관리되는 모든 호출은 그 판정, 표면, 그리고 매칭된 규칙을 기록합니다. 허용 목록과 egress 규칙이 의도대로 동작하는지 확인하려면 그것들을 읽으세요. MCP 이벤트 감사를 참조하세요.
학습된 기준선에 대한 비율 및 비용 급증, 더하기 재시도 루프와 새로운 툴 경로가 이상 징후로 표면화됩니다 — 모든 Member가 읽을 수 있습니다.
observe 모드를 켜서 정책이 아직 커버하지 않는 호출을 갭으로 로깅하면, 추측이 아니라 에이전트가 실제로 하는 것으로부터 타이트하게 합니다.

8. 빠른 경로: 자율성 수준 고르기

완전히 신뢰하지 않는 서버에 대해 단계 3–5를 손으로 빌드하기보다, 자율성 수준을 적용하고 거기서 편집하고 싶다면. 수준들은 실제, 편집 가능한 정책과 guardrail 행을 씁니다 — 그것들은 블랙박스가 아니라 시작점입니다:
수준설정하는 것
permissiveObserve 모드 켬 — 모든 것을 로깅, 아무것도 강제하지 않음.
balanced파괴적 셸을 거부하는 기본 audit 정책, 더하기 flag 전용 모드의 PII Shield guardrail.
tight파괴적 셸과 fetch 형태 툴(http_fetch/web_search/fetch_url/request — SSRF 벡터)을 거부하는 기본 거부 정책, 더하기 강제된 PII Shield와 Secrets Blocker guardrail. 인자의 시크릿은 tool-arg 규칙이 아니라 요청에 대한 Secrets Blocker guardrail에 의해 잡힙니다.
아직 검증 중인 서드파티 서버의 경우, tight에서 시작하고, 프로빙한 다음, 특정 툴을 허용 목록으로 완화하세요. 원클릭 실행 취소는 적용 전 스냅샷을 복원합니다.
설정, 정책, 발견된 툴, 이상 징후, 등록된 MCP 서버, 그리고 스킬의 읽기는 모든 Member에게 열려 있습니다; 이벤트, 실행, 그리고 집계 읽기는 **Developer+**가 필요하며, 모든 쓰기는 **Developer+**가 필요합니다. 토큰의 평문 키를 드러내는 것도 **Developer+**입니다.

9. 다음 단계

MCP 서버 연결하기

게이트웨이를 통해 서버를 등록, 프로빙, 노출합니다.

MCP 툴 허용 목록

서버를 기본 거부로 두고 검토한 툴만 허용합니다.

러그풀 방어

승인 후 변경되는 서버나 스킬을 잡습니다.

MCP 보안 개요

MCP 거버넌스 표면의 전체 지도.
이 모델이 처음이신가요? MCP 거버넌스가 어디에 들어맞는지는 Guardrails vs. firewall을 읽은 다음, 이 체크리스트가 닫는 위협은 과도한 에이전시위험한 툴 호출을 참조하세요.