메인 콘텐츠로 건너뛰기
MCP 에이전트는 도달 범위를 가진 에이전트입니다. 그것이 연결하는 모든 Model Context Protocol 서버는 아무도 검토하지 않은 새로운 툴, 자격 증명, 네트워크 목적지 세트입니다 — 그리고 에이전트는 실행 중간에 새 서버를 끌어올 수 있습니다. 이 레시피는 산만한 MCP 설정을 호스팅된 게이트웨이에서 통제되는 것으로 바꾸는 네 가지 움직임을 보여줍니다: 감사된 하나의 MCP 게이트웨이, skill 격리, egress 거부, 그리고 암호화된 서버 인증. 여러분의 워크스페이스에 대해 콘솔(또는 REST API)에서 그 모든 것을 구성합니다. 여러분의 에이전트는 이전과 정확히 동일하게 MCP를 계속 말합니다.

​
1. MCP 에이전트를 보안하는 이유

에이전트를 다섯 개의 MCP 서버에 직접 가리키면 다섯 개의 신뢰 경계, 다섯 개의 자격 증명 저장소, 그리고 공유된 감사 추적은 0개를 갖게 됩니다. 고객 레코드를 읽는 tools/call과 셸 명령을 실행하는 것이 모델에게 동일하게 보이고, 커뮤니티 서버는 처음 로드될 때 조용히 shell.exec와 외부 네트워크 범위를 요청할 수 있습니다. 해결책은 OrcaRouter를 모든 호출이 가로지르는 단일 초크 포인트로 만드는 것입니다. MCP 에이전트 트래픽을 처음부터 끝까지 보안하려면 모든 MCP 디스패치를 Firewall의 MCP 게이트웨이를 통해 라우팅하여, 모든 tools/call이 실제 서버에 도달하기 전에 정책 평가를 받게 하세요 — skill은 위험 점수가 매겨지고, egress는 통제되며, 자격 증명은 저장 시 암호화됩니다.
이것은 레시피입니다 — 기존 기능을 하나의 구체적인 강화 패스로 엮습니다. 전체 레퍼런스는 Firewall, MCP 서버, Skills로 가는 링크를 따라가세요.

​
2. Secure Agents 기준선에서 시작하기

맞춤형인 무엇을 작성하기 전에, 자세를 설정하세요. 콘솔에서 Firewall → Posture를 열고 balanced 자율성 수준(Developer 역할)을 적용하세요. 한 트랜잭션에서 가장 파괴적인 액션을 거부하면서 툴 호출을 감사하고 PII를 플래그합니다 — 광범위하게 강제하기 전에 관찰하며, 원클릭 실행 취소가 있습니다. Events와 Runs 피드가 적절해 보이면, **tight**로 이동하세요: 기본 거부, 파괴적 셸 거부, SSRF 형태 egress 거부, 그리고 PII Shield와 Secrets Blocker guardrail 강제. 그 단일 스위치가 이 레시피가 그 위에 구축하는 바닥입니다.
전체 워크스페이스를 뒤집지 않고 점진적으로 올리고 싶으신가요? 아래 규칙을 이름이 지정된 하나의 정책에 작성하고 그것의 shadow mode를 켜세요 — 그것은 확신할 때까지 평가하고 로깅하되 모든 강제 판정을 audit로 강등합니다(이유에 [shadow] would … 접두). 강제 모드를 참조하세요.

​
3. 모든 tools/call을 하나의 MCP 게이트웨이를 통해 라우팅하기

각 MCP 서버를 한 번 등록하세요; 게이트웨이는 단일 연결 아래에서 그들의 툴을 집계하고(네임스페이스 <server>.<tool>) 모든 tools/call을 firewall 엔진을 통해 실행합니다. 콘솔(또는 REST API, Developer+)에서 서버를 등록하세요: 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-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
  }'
그런 다음 전용 firewall-gateway-scoped 키를 사용하여 MCP 클라이언트를 업스트림 서버가 아니라 게이트웨이로 가리키세요: 
https://api.orcarouter.ai/api/v1/firewall/mcp
이제 github.create_issue와 shell.exec가 하나의 연결 아래에 나란히 나타나고, 각 디스패치는 실행되기 전에 평가됩니다. 차단된 호출은 전송 크래시가 아니라 툴 오류(firewall deny: …)로 모델에 돌아오므로, 에이전트가 적응할 수 있습니다.
일반 릴레이 키는 게이트웨이 라우트 /api/v1/firewall/mcp에서 403을 받습니다. MCP 연결을 위해 전용 게이트웨이 토큰(is_firewall_gateway)을 발급하세요; 그 게이트웨이 키의 평문을 읽으려면 **Admin+**가 필요합니다.
서버의 툴에 대해 규칙을 작성할 수 있으려면, 먼저 그것을 probe하여 이름과 스키마를 발견하세요: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. 에이전트가 끌어오는 skill 격리하기

MCP 게이트웨이는 호출을 통제합니다; skill 거버넌스는 에이전트가 로드하는 기능을 통제합니다. 모든 설치 가능한 skill, BYO MCP 서버, 또는 플러그인은 모든 규칙 판정 위에 올라타는 위험 밴드와 강제 모드로 스캔됩니다:
모드런타임에서의 효과
allow규칙 판정이 결정합니다; skill은 아무것도 더하지 않습니다.
quarantinedeny에 미치지 않는 모든 것이 pending_approval로 보류됩니다.
blockskill의 툴이 강제 거부됩니다.
MCP 에이전트의 핵심: 아무도 승인하지 않은 기능은 무임승차를 얻지 못합니다. 에이전트가 무언가를 자체 설치하고 그 툴이 처음 게이트웨이를 가로지를 때, Firewall은 그것을 자동 탐지하고 사람이 검토할 때까지 격리합니다 — 스캔이 깨끗했더라도. 신뢰하는 서버는 사전 승인하세요; 나머지는 검토 큐에 도착하게 두세요.
에이전트가 실제로 무엇을 설치하는지 학습하는 동안 balanced/observe를 켜 두세요, 그런 다음 신뢰하는 skill을 allow로 격상하고 긴 꼬리는 격리된 채로 두세요. Skills를 참조하세요.

​
5. SSRF 형태의 egress 거부하기

손상되거나 혼동된 MCP 툴이 클라우드 메타데이터나 인트라넷 호스트에 도달하는 것은 고전적인 유출 경로입니다. 두 레이어가 그것을 커버합니다. 먼저, 게이트웨이는 등록 시점과 각 디스패치 홉에서 모든 원격 MCP 엔드포인트와 그 해석된 다이얼 IP를 SSRF 정책에 대해 검증합니다 — 인트라넷 범위와 클라우드 메타데이터 주소는 거부되며, DNS 리바인딩을 무력화하기 위해 재검사됩니다. 그것은 내장되어 있습니다; 여러분이 구성하지 않습니다. 둘째, tight 자율성 수준은 fetch 형태의 툴 이름을 거부하는 SSRF egress 프리셋을 제공합니다 — http_fetch, web_search, fetch_url, request, 그리고 그들의 <server>.* 네임스페이스 형태 — 그래서 전체 역할이 “이 URL을 가서 가져오기”인 툴은 다이얼하기 전에 멈춥니다. 툴이 목적지별로 어디에 도달할 수 있는지 통제하려면, host/CIDR 거부 목록과 함께 여러분 자신의 egress 규칙을 작성하세요 — 그것이 아웃바운드 도달 범위를 고정하는 표면입니다: 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
어떤 프리셋도 CIDR egress 규칙을 제공하지 않습니다 — SSRF 프리셋은 목적지가 아니라 툴 이름을 매치합니다. 목적지 수준 통제가 필요할 때는 host/CIDR 거부 목록을 직접 작성하세요. egress 목록과 유출 중지를 참조하세요.

​
6. 서버 자격 증명을 암호화 상태로 유지하기

모든 MCP 서버의 auth_json은 저장 시 암호화되고 읽을 때 마스킹됩니다; 게이트웨이는 디스패치 시점에 자격 증명을 주입하므로, 그것들은 결코 모델이나 클라이언트에 도달하지 않습니다. 지원되는 auth_mode 값:
{ "token": "…" } — 정적 bearer 토큰, Authorization: Bearer로 전송됨.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — client-credentials OAuth; 게이트웨이가 토큰을 가져오고 갱신합니다.
{ "username": "…", "password": "…" } — HTTP Basic 인증.
"" — 인증되지 않은 서버. 기본값.
읽을 때 시크릿은 마스킹됩니다; 저장된 값을 유지하려면 업데이트 시 마스크를 그대로 돌려보내세요. 마지막 probe에서 온 서버의 status(ok / degraded / down)는 그것에 의존하기 전에 도달 가능한지를 알려줍니다.

​
7. 요청에 콘텐츠 guardrail 추가하기

Firewall은 액션을 통제합니다; 여러분의 MCP 에이전트를 통과하는 텍스트도 스크리닝되도록 Guardrail과 짝지으세요. Secrets Blocker 프리셋은 모델 — 또는 어떤 툴 — 이 보기 전에 요청 내 자격 증명을 잡고, PII Shield는 들어오는 길에 식별자를 마스킹합니다. 둘 다 tight 자율성 수준과 함께 켜지거나, guardrail_id를 통해 에이전트의 릴레이 키에 이름이 지정된 guardrail을 연결하세요.
firewall의 sanitize 판정은 툴 호출 인자를 가리며, 툴이 반환하는 콘텐츠는 결코 아닙니다. Secrets Blocker guardrail로 요청에서 시크릿을 벗겨내세요; 에이전트가 내보내는 인자는 firewall 규칙으로 정화하세요. 그것들은 흐름의 서로 다른 절반을 커버합니다.

​
8. 검증하고 지켜보기

정책에 신뢰하기 전에 그것이 예상하는 것을 하는지 확인한 다음, 피드를 주시하세요:

툴 호출 테스트

여러분의 정책에 대해 샘플 tools/call을 dry-run하고 판정, 매치된 규칙, 그리고 이유를 보세요 — 아무것도 디스패치되지 않고, 아무것도 로깅되지 않습니다.

Discovered tools

워크스페이스가 본 모든 툴이, covered 또는 gap으로 플래그됨 — 실제 MCP 트래픽으로부터 곧바로 규칙을 작성하세요.

Events & Runs

모든 디스패치, 그 판정, 그리고 그것이 친 표면이, 에이전트 run별로 롤업됨.

이상 피드

학습된 베이스라인에 대한 속도/비용 급증, retry 루프, 그리고 새로운 툴 경로.

​
9. 다음으로 갈 곳

MCP 툴 오염

격리와 MCP 게이트웨이 뒤의 위협 모델.

과도한 에이전시

자율 툴 사용에 기본 거부와 HITL이 중요한 이유.

자율 에이전트 레시피

고자율 에이전트를 처음부터 끝까지 강화하세요.

유출 중지

아웃바운드 egress를 깊이 있게 잠그세요.