메인 콘텐츠로 건너뛰기
Model Context Protocol(MCP)을 말하는 에이전트는 연결하는 서버만큼만 안전합니다. 모든 MCP 서버는 새로운 툴 세트, 새로운 자격 증명, 그리고 새로운 네트워크 도달 범위입니다 — 그리고 에이전트가 하나에 직접 다이얼하는 순간, 아무도 그 호출을 보고 있지 않습니다. 그것이 바로 mcp 보안이 해결해야 하는 전체 문제입니다: “이 하나의 툴이 안전한가”가 아니라 “누가 모든 툴을, 모든 호출에서, 하나의 감사 추적으로 관리하는가.” OrcaRouter의 답은 단일 감사 초크 포인트입니다. 각 MCP 서버를 한 번 등록하면; 에이전트는 하나의 게이트웨이에 연결하고; 모든 tools/call은 실제 서버에 도달하기 전에 firewall 엔진을 통해 실행됩니다. 이 페이지는 그 표면의 지도입니다 — 게이트웨이, 호출별 판정, 스킬 거버넌스, egress, 그리고 암호화된 자격 증명 — 각각에 대한 집중된 how-to 링크와 함께.
여기의 모든 관리 액션은 콘솔(또는 세션/액세스 토큰을 사용하는 REST API)에서 구성되며 역할로 제한됩니다. /v1/* 릴레이 호출과 firewall 게이트웨이 라우트만 sk-orca-... 스타일 키를 사용합니다.

​
1. 왜 mcp 보안에는 게이트웨이가 필요한가

열 개의 에이전트를 다섯 개의 커뮤니티 MCP 서버에 직접 가리키면 모든 세계의 최악을 얻게 됩니다: 공유 정책 없음, 감사 추적 없음, 열 개의 에이전트 구성에 복사된 자격 증명, 그리고 클라우드 메타데이터 엔드포인트에서 리다이렉트 한 번 거리에 있는 shell.exec라는 이름의 툴. 게이트웨이는 그것을 하나의 관리되는 연결로 응축합니다.

하나의 연결, 모든 서버

에이전트는 단일 엔드포인트에 연결합니다. 게이트웨이는 활성화되고 도달 가능한 모든 서버의 툴을 <server>.<tool> 네임스페이스 아래로 집계합니다.

모든 호출에 정책

각 tools/call은 디스패치 전에 당신의 firewall 정책에 의해 평가됩니다.

암호화된 자격 증명

서버 인증 시크릿은 저장 시 암호화되고, 읽기 시 마스킹되며, 디스패치 시 주입됩니다 — 결코 모델이나 클라이언트에 도달하지 않습니다.

통제 하의 egress

등록된 서버의 엔드포인트는 기본적으로 사설 및 클라우드 메타데이터 IP 범위에 대해 검증됩니다. 툴별 목적지의 경우, 기준선 SSRF egress 거부 목록을 적용하거나 자체 host/CIDR 규칙을 작성하세요.
이 모든 것의 기반에 대해서는 AI 에이전트 보안 강화와 제로 트러스트가 필요한 이유를 참조하세요.

​
2. 네 가지 구성 요소

OrcaRouter의 MCP 거버넌스는 네 개의 협력하는 조각입니다. 답하려는 질문에 맞는 것을 고르세요.
에이전트가 서버에 직접 다이얼하는 대신 연결하는 단일 엔드포인트입니다. 그것은 등록된 모든 서버의 툴을 <server>.<tool>로 네임스페이스 처리하여 집계하고, 각 툴의 입력 스키마를 그대로 다시 노출합니다. MCP 서버 연결하기와 인증에서 시작하세요; 전체 레퍼런스는 Firewall: MCP 서버에 있습니다.
게이트웨이는 각 tools/call을 mcp 표면에서 firewall을 통해 실행하고 판정을 반환합니다 — allow, audit, deny, sanitize, 또는 pending_approval — 디스패치 전에. MCP 툴 허용 목록과 툴 인자 정화를 참조하세요.
에이전트가 자체 설치하는 기능 — 스킬, BYO MCP 서버, 플러그인 — 은 스캔되고, 위험 밴드가 할당되며, 모든 규칙 판정 위에 올라타는 강제 모드(allow / quarantine / block)가 부여됩니다. Firewall: 스킬과 러그풀 방어를 참조하세요.
각 서버의 인증 시크릿은 저장 시 암호화되고 읽기 시 마스킹됩니다. 인증과 자격 증명 교체를 참조하세요.

​
3. tools/call이 평가되는 방식

에이전트가 게이트웨이를 통해 툴을 호출하면, 그 호출은 서버로 곧장 가지 않습니다. 그것은 당신의 워크스페이스 정책에 대해 매칭되고, 소유하는 스킬의 강제 모드가 위에 적용되며, allow / audit / sanitize 판정만이 실제 서버에 도달합니다.
판정에이전트가 보는 것
allow / audit전달됨. audit는 이벤트도 로깅합니다.
sanitize인자가 편집(redact)된 채 전달됨(결과는 절대 아님).
deny / pending_approval툴 오류로 반환되어, 에이전트가 크래시하는 대신 적응할 수 있습니다.
차단된 MCP 호출은 툴 오류(firewall deny: …)로 돌아옵니다 — 실패하는 어떤 툴이든 반환하는 것과 동일한 형태 — 그래서 에이전트는 다르게 재시도, 사용자에게 질문, 또는 중단할 수 있습니다. 그것은 전송 크래시가 아닙니다.
판정 어휘, 표면, 그리고 규칙 매칭은 Firewall과 Firewall 규칙에 전부 문서화되어 있습니다; 개념적 모델은 강제 모드와 OrcaRouter가 검사하는 방식에 있습니다.

​
4. 서버 등록하기 (하나의 구체적인 예)

각 서버를 한 번 등록합니다. 서버 레코드는 name(워크스페이스당 고유, . 없음), endpoint, auth_mode(none / bearer / oauth / basic), 그리고 암호화된 자격 증명을 담습니다. 이를 콘솔에서 수행하세요 — 쓰기는 **Developer+**가 필요합니다. 
# 콘솔 라우트, 세션/액세스 토큰(UserAuth)으로 호출됨.
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\"}",
    "enabled": true
  }'
그런 다음 probe하여 그 툴을 발견하고 도달 가능성 (ok / degraded / down)을 기록하세요: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
이제 github.create_issue가 정확히 무엇을 받아들이는지 알고 github.*에 대한 규칙을 작성할 수 있습니다. 엔드투엔드 워크스루는 MCP 서버 연결하기에 있습니다.
시크릿은 결코 평문으로 저장되지 않습니다. auth_json은 저장 시 암호화되고 읽기 시 마스킹됩니다; 업데이트 시 저장된 값을 유지하려면 마스크를 그대로 돌려보내세요. 자격 증명 교체를 참조하세요.

​
5. 에이전트를 게이트웨이에 연결하기

서버가 등록되면, firewall-gateway-scoped 키와 함께 임의의 MCP 클라이언트를 게이트웨이로 가리킵니다(그 스코프가 없는 토큰은 403을 받습니다): 
https://api.orcarouter.ai/api/v1/firewall/mcp
게이트웨이는 streamable HTTP를 말하고 활성화되고 도달 가능한 모든 서버의 툴을 <server>.<tool> 네임스페이스 아래 광고합니다. 호출을 직접 프록시하는 SDK는 동일한 게이트웨이 토큰으로 GET /api/v1/firewall/mcp_servers에서 런타임 레지스트리를 읽을 수 있습니다.

​
6. 툴이 도달할 수 있는 것을 잠그기

호출별 판정은 어느 툴이 실행되는지를 관리하고; egress 통제는 어디까지 도달할 수 있는지를 통제합니다. 두 레이어가 협력합니다. 첫째, 게이트웨이가 등록된 서버의 엔드포인트에 연결할 때, 그 URL은 기본적으로 사설(RFC1918), loopback, link-local, 그리고 클라우드 메타데이터 범위에 대해 검증됩니다 — 그리고 호스트가 DNS 해석되어 차단된 범위로 해석되는 이름도 거부됩니다. 따라서 169.254.169.254나 인트라넷 주소를 가리키는 BYO 서버는 명시적으로 화이트리스트하지 않는 한 거부됩니다. 둘째, 툴별 목적지의 경우, egress 규칙은 egress 표면에서 호출의 아웃바운드 목적지에 대해 매칭되는 host/CIDR 허용/거부 목록을 담습니다. 기준선 유스케이스 템플릿은 그 목록이 이미 사설, loopback, link-local, 그리고 클라우드 메타데이터 범위(169.254.169.254와 metadata.google.internal 포함)를 커버하는 즉시 사용 가능한 egress 거부 규칙을 제공하므로, 그것을 적용하면 CIDR을 손으로 작성하지 않고도 SSRF/메타데이터 방어를 얻습니다.
SSRF와 egress는 “이 툴이 데이터를 반환했다”와 “이 툴이 당신의 시크릿을 공격자의 호스트로 유출했다”의 차이입니다. 기준선 egress 거부 목록을 적용하고 자체 host/CIDR 규칙을 추가하세요 — Egress 한도와 데이터 유출을 참조하세요.

​
7. 관찰하기: 이벤트, 실행, 그리고 이상 징후

관리되는 모든 호출은 추적을 남깁니다. Firewall 이벤트는 판정, 표면, 그리고 매칭된 규칙을 기록합니다; 실행(run)은 세션의 호출을 그룹화합니다; 그리고 이상 징후 피드는 학습된 기준선에 대한 비율 및 비용 급증을 플래그합니다. 설정, 정책, 발견된 툴의 읽기는 모든 Member에게 열려 있습니다; 이벤트/실행/집계 읽기는 **Developer+**가 필요합니다.

​
8. 다음 단계

MCP 서버 연결하기

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

MCP 툴 허용 목록

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

러그풀 방어

승인 후 변경되는 서버와 스킬을 관리합니다.

Firewall: MCP 서버

완전한 필드 및 라우트 레퍼런스.
이 모델이 처음이신가요? Guardrails vs. firewall을 읽고 MCP 거버넌스가 어디에 들어맞는지 본 다음, MCP 툴 포이즈닝과 과도한 에이전시에서 그것이 닫는 위협을 보세요.