메인 콘텐츠로 건너뛰기
당신이 연결하는 MCP 서버는 네트워크로 손을 뻗는 툴을 제공합니다 — fetch, web_search, 웹훅 포스터. 툴 이름이 당신의 허용 목록에 있고, 인자가 깨끗해 보여도, 호출은 여전히 당신의 데이터를 공격자가 통제하는 호스트로 POST하거나 169.254.169.254 메타데이터 엔드포인트에서 자격 증명을 끌어내며 끝날 수 있습니다. 목적지는 당신의 툴 이름 규칙이 결코 보지 못하는 호출의 부분입니다. mcp egress 통제는 그 갭을 닫습니다. egress 규칙은 firewall 판정을 툴이 도달하는 곳 — 호스트, IP, 또는 CIDR 범위 — 으로 범위 지정하므로, api.openai.com에 허용된 동일한 http_fetch가 나머지 모든 것에는 거부됩니다. 그것은 모든 tools/call이 이미 거치는 호출별 평가 위에서, firewall의 egress 표면에서 실행됩니다.
이것은 콘솔 작업입니다. Firewall 규칙은 릴레이 sk-orca-… 키가 아니라 세션/액세스 토큰으로 인증하는 /api/workspace/firewall/* 라우트에 존재합니다. 규칙 작성은 Developer+ 역할이 필요합니다.

​
1. egress 규칙이 통제하는 것

일반 규칙은 툴 이름과 그 인자에 매칭합니다. egress 규칙은 세 번째 차원을 추가합니다: 호출이 해석되는 목적지. 규칙의 stage를 egress로 설정하고 allow / deny 항목의 egress_json 목록을 첨부합니다. 엔진은 호출에서 목적지 호스트를 추출하고 그 호스트가 범위에 있을 때만 규칙을 발동합니다. 항목은 세 가지 방식으로 매칭됩니다:

호스트명

대소문자 구분 없는 정확한 매칭, 예: api.openai.com. 후행 점은 양쪽에서 트리밍됩니다.

IP 리터럴

해석된 다이얼 IP에 대한 정확한 매칭, 예: 169.254.169.254.

CIDR 범위

목적지 IP — 리터럴 또는 DNS 해석 — 가 블록 내부에 들어가야 함, 예: 10.0.0.0/8.
목적지가 호스트명이지만 당신의 목록이 IP/CIDR 항목을 담을 때, 이름이 해석되고 그 IP가 다시 검사됩니다 — 그래서 metadata.internal은 이름으로 나열되지 않았어도 169.254.0.0/16 deny에 매칭됩니다. 이것은 거부된 범위로 해석되는 이름에 대한 최선 노력의 심층 방어입니다; 권위 있는 SSRF 가드는 여전히 게이트웨이의 다이얼 레이어에서 실행됩니다.

​
2. 하나의 구체적인 예

모든 fetch 형태 툴이 클라우드 메타데이터 엔드포인트와 RFC-1918 범위에 도달하는 것을 거부합니다. 이것은 전형적인 SSRF 유출 다리 절단입니다: egress 단계에서의 deny 판정, egress_json 거부 목록으로 범위 지정됨. 
curl https://api.orcarouter.ai/api/workspace/firewall/rules \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": 12,
    "priority": 10,
    "label": "Deny SSRF / metadata egress",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny",
    "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"]}"
  }'
목적지가 그 범위 중 어느 것으로든 해석되는 tools/call은 모델에 툴 오류로 돌아옵니다; 거부 목록이 커버하지 않는 공개 호스트로의 호출은 통과합니다.
allow/deny 목록은 판정에 따라 의미가 뒤집힙니다. deny(또는 다른 강제) 규칙에서, deny 목록은 범위 내 집합이고 allow는 예외를 새깁니다 — “이것들을 거부, 저것들은 제외.” allow 규칙에서는 역할이 역전됩니다: allow 목록이 범위 내 집합이고 deny가 예외를 새깁니다 — “이것들만 허용.” 비어 있지 않은 egress_json은 적어도 하나의 allow 또는 deny 항목을 선언해야 하며, 그렇지 않으면 쓰기가 거부됩니다.

​
3. 단 하나의 목적지만 허용 목록화하기

위 예의 반대: fetch 툴을 단일 승인된 호스트로 고정하고 정책의 default_verdict(또는 이후 catch-all)가 나머지를 처리하게 합니다. 이것은 allow 판정이므로, allow 목록이 범위 내 집합입니다. 
// allow-판정, stage=egress 규칙의 egress_json
{ "allow": ["api.openai.com", "api.anthropic.com"] }
규칙은 이제 목적지가 그 두 호스트 중 하나일 때만 발동(허용)합니다. 나머지는 다음 규칙으로 떨어집니다 — 나열되지 않은 목적지가 통과되는 대신 거부되도록 이것을 기본 거부 정책과 짝지으세요.
신뢰하기 전에 테스트하세요. 콘솔의 Test 탭과 POST /api/workspace/firewall/test 엔드포인트(Developer+)는 당신의 초안 정책에 대해 샘플 호출을 재생하므로, 라이브 트래픽을 보내지 않고 알려진 목적지에 대한 판정을 확인할 수 있습니다.

​
4. firewall의 나머지와 어떻게 구성되는가

egress 규칙은 워크스페이스 firewall 정책의 많은 규칙 중 하나입니다. 엔진은 우선순위 순서(낮은 것 먼저)로 규칙을 걸으며 첫 매칭이 이기므로, 광범위한 allow 위에 타이트한 egress deny를 두세요.
egress 규칙의 판정효과
deny범위 내 목적지로의 호출을 차단 — egress 표면에 기록되고 툴에 오류로 반환됨.
audit매칭된 호출을 firewall 이벤트로 로깅; 여전히 디스패치됨.
allow범위 내 목적지를 허용; 기본 거부 바닥과 짝지어짐.
pending_approval과 cap_cost는 egress 표면에서 강제되지 않습니다 — egress는 목적지 검사이지 보류나 지출 상한이 아닙니다. 대신 그 판정은 mcp나 inbound 표면에서 사용하세요. 판정 레퍼런스를 참조하세요.
egress 규칙과 함께 배선할 가치가 있는 두 가지 관련 통제:
당신이 작성하는 어떤 규칙과도 독립적으로, MCP 게이트웨이는 모든 서버 엔드포인트와 그 해석된 다이얼 IP를 SSRF 정책에 대해 검증합니다 — 인트라넷 범위와 클라우드 메타데이터 주소가 거부되며, IP가 DNS 리바인딩을 무력화하기 위해 모든 홉에서 다시 검사됩니다. 당신의 egress 규칙은 그 기준선 위에 워크스페이스별 목적지 정책을 계층화합니다.
단일 egress deny는 툴이 호스트에 도달하는 것을 멈춥니다. 시퀀스 규칙은 체인을 멈춥니다 — 예: “파일을 읽은 다음, 윈도우 내에서 egress” — 민감한 읽기 뒤에 따라올 때만 egress 다리를 플래그하여. 그것이 lethal-trifecta 차단기입니다; egress 범위 지정은 호출별 통제입니다.

​
5. 먼저 shadow한 다음 강제하기

바쁜 워크스페이스에서 egress deny를 곧장 강제로 롤링하면 잊은 정당한 통합을 깨뜨릴 위험이 있습니다. 두 안전망:
  • Shadow 모드. shadow 모드의 정책은 모든 강제 판정을 audit로 다운그레이드합니다 — 당신의 egress deny가 차단하는 대신 [shadow] would deny …를 로깅하므로, 그것이 물기 전에 폭발 반경을 봅니다.
  • Observe 모드. 워크스페이스 firewall_observe_mode 설정은 커버되지 않은 호출을 Discovered Tools로 로깅하여, 에이전트가 이미 도달하는 실제 목적지를 표면화하므로 추측이 아니라 데이터로부터 정확한 허용 목록을 작성할 수 있습니다.
Egress 목적지 매칭은 호출이 평가 시점에 해석되는 호스트를 키로 합니다. 적대적 서버는 여전히 정책 검사와 실제 다이얼 사이에 DNS를 리바인딩할 수 있습니다(TOCTOU) — 그것이 바로 게이트웨이의 소켓 레이어 IP 가드가 권위 있는 통제이고 이 규칙이 유일한 라인이 아닌 심층 방어인 이유입니다.

​
6. 역할과 라우트

모든 콘솔 라우트는 워크스페이스 범위이며 세션/액세스 토큰으로 인증합니다. 읽기는 모든 Member에게 열려 있습니다; 규칙 작성이나 편집은 **Developer+**가 필요합니다.
메서드 및 경로역할목적
GET /api/workspace/firewall/policies/:idMember정책과 그 규칙 읽기.
POST /api/workspace/firewall/rulesDeveloper+규칙 추가(stage: egress 설정).
PUT /api/workspace/firewall/rulesDeveloper+규칙 업데이트(본문에 id).
DELETE /api/workspace/firewall/rules/:idDeveloper+규칙 제거.
POST /api/workspace/firewall/testDeveloper+초안 정책에 대해 샘플 호출 재생.

​
관련

Firewall 규칙 레퍼런스

전체 규칙 DSL — 툴 글로브, 인자 매칭, egress 목록, 시퀀스.

MCP 서버 연결하기

툴 호출이 firewall 뒤에서 실행되도록 서버를 등록합니다.

MCP 툴 허용 목록

명시적으로 승인하지 않은 툴을 기본 거부합니다.

데이터 유출

egress 통제가 멈추도록 만들어진 위협.