메인 콘텐츠로 건너뛰기
에이전트가 http_fetch, web_search, 또는 아웃바운드 연결을 여는 모든 툴을 호출할 때, 목적지가 가장 통제해야 할 부분입니다. 169.254.169.254에 도달할 수 있는 혼란하거나 탈취된 에이전트는 클라우드 자격 증명을 읽습니다; 공격자 호스트로 POST할 수 있는 에이전트는 데이터를 유출합니다. 에이전트 egress 제어는 그 목적지를 통제합니다 — firewall의 egress 표면에 호스트/CIDR 허용/거부 규칙을 작성하고, 키에 연결하면, 게이트웨이는 에이전트의 툴이 보고하는 모든 아웃바운드 목적지를 호출이 나가기 전에 검사합니다. 이것은 집중된 사용 사례 페이지입니다. 전체 규칙 문법과 판정 의미는 규칙 스키마와 Verdicts를; egress가 다른 강제 지점들 사이에 어떻게 위치하는지는 Stages를 참조하세요.

​
1. egress 표면의 에이전트 egress 제어

firewall의 네 표면 중, egress는 툴이 보고하는 아웃바운드 네트워크 목적지 — 호스트, IP 리터럴, 또는 CIDR — 를 보는 표면입니다. stage: egress에 고정된 규칙은 툴 이름이나 그 인자가 아니라 그 목적지에 매치하며, 이것이 SSRF 및 데이터 유출 제어가 되게 합니다: 그것은 어떤 툴이 도달했는지와 무관하게 이 에이전트가 어디에 도달할 수 있는가에 답합니다.
Egress는 툴 차단이 아니라 목적지 범위 지정입니다. 툴이 아예 존재하지 않게 멈추려면, inbound 표면에서 이름으로 거부하세요(툴 차단). Egress 제어는 툴이 정당하게 fetch할 수 있다고 가정합니다 — 그저 어디로를 제약할 뿐.

​
2. 한 예: SSRF 목적지 거부

정전(canonical) egress 규칙은 클라우드 메타데이터 엔드포인트와 사설 RFC-1918 범위 — fetch 형태의 툴이 결코 도달해서는 안 되는 목적지 — 를 거부합니다. 워크스페이스 콘솔에서, 정책을 열고 stage egress, 판정 deny, 그리고 egress 목록을 가진 규칙을 추가합니다: 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json은 호스트/CIDR 목록을 담은 JSON으로 인코딩된 문자열입니다 — 디코딩하면 {"deny": [...], "allow": [...]}입니다. 각 항목은 CIDR, IP 리터럴, 또는 대소문자 구분 없는 호스트명으로 매치합니다. deny 판정의 경우 deny 목록이 범위 내 집합(규칙이 차단하는 목적지)이고 allow 목록이 거기서 예외를 깎아냅니다 — 그래서 위의 규칙은 네 범위를 차단하지만 api.openai.com이 언젠가 그중 하나로 해석되더라도 통과시킵니다. 목적지가 IP 리터럴이 아니라 호스트명이고 목록에 IP/CIDR 항목이 있으면, 이름은 best-effort로 해석되고 그 주소들이 재검사되므로, metadata.internal은 이름으로 나열되지 않았더라도 여전히 169.254.0.0/16 deny에 매치합니다.
대신 허용 목록 자세를 위해 — 명명된 목적지 집합만 허가하고 나머지를 차단 — 판정 allow로 규칙을 작성하고 목적지를 allow 목록에 넣으세요. 극성이 뒤집힙니다: allow이 범위 내 집합이 되고 deny이 예외를 깎아냅니다. allow 규칙이 커버하지 않는 모든 것이 차단되도록 정책 default_verdict deny와 짝지으세요.

​
3. CIDR 규칙은 직접 작성합니다 — 어떤 프리셋도 제공하지 않습니다

프리셋 CIDR 목록은 없습니다. OrcaRouter는 169.254.169.254, RFC-1918, 또는 다른 어떤 범위를 거부하는 내장 규칙을 제공하지 않습니다. CIDR 허용/거부 규칙은 직접 작성하는 것입니다 — 그것은 §2의 예이며, 자신의 네트워크에 대해 직접 작성합니다. 그것을 복사한 다음, 범위와 허용 목록 예외를 환경에 맞게 조정하세요.
tight 자율성 수준과 그 block_ssrf_egress 프리셋이 실제로 제공하는 것은 fetch 형태의 툴 이름 — http_fetch, web_search, fetch_url, request, 그리고 그들의 <server>.<tool> MCP 변형 — 에 대한 거부 집합입니다. 그것은 무딘 자세: 그것들이 도달할 수 있는 곳을 범위 지정하기보다 egress 형태의 툴을 통째로 거부합니다. 에이전트가 네트워크 호출을 할 일이 전혀 없을 때 그것을 사용하세요; 그것이 실제로 fetch하지만 승인된 호스트 집합에서만 할 때는 목적지 규칙(§2)을 사용하세요.
접근무엇을 제약하는가작성자
tight SSRF 프리셋Fetch 형태 툴 이름(거부)내장
Egress CIDR/호스트 규칙fetch가 도달할 수 있는 목적지사용자

​
4. 차단된 egress는 어떻게 보이는가

목적지가 강제 egress 규칙에 매치하면, 호출은 게이트웨이를 떠나기 전에 거부되고 평가는 표면 egress와 판정 deny를 가진 firewall 이벤트로 기록됩니다. shadow mode에서 deny는 이유에 [shadow] would …가 접두된 audit로 강등되므로, 강제하기 전에 규칙이 실제 트래픽에 대해 어떤 목적지를 차단할지 정확히 측정할 수 있습니다.
잘못 형성되거나 항목이 없는 egress 목록은 보수적으로 취급됩니다: 강제 deny 규칙은 여전히 게이트합니다(오타가 그것이 차단하는 것을 조용히 멈출 수 없음), 하지만 깨진 목록을 가진 allow 규칙은 발동하지 않습니다 — 그렇지 않으면 잘못 타이핑된 허용 목록이 allow-all이 되어 기본 deny를 가릴 것입니다. 새 규칙은 저장 시 검증되므로(목록은 최소 하나의 allow나 deny 항목을 선언해야 함), 이는 레거시 행만 보호합니다.

​
5. 실제 트래픽에서 작성한 다음, 롤아웃

이벤트 로그는 각 egress 표면 이벤트에 목적지 호스트(egress_host/egress_url)를 기록하므로, 표면 egress로 필터링하고 추측하기보다 실제로 나타난 목적지에서 deny 목록을 작성하세요. Discovered Tools 탭은 툴 이름별 롤업(툴 이름과 그들이 발동한 표면)입니다 — 어떤 fetch 형태 툴이 실행되었는지 알려주지, 그들이 도달한 호스트는 아닙니다. 분석 참조.
콘솔 Test 탭은 샘플 tool_name + 표면(+ 선택적 args)에 대해 정책을 dry-run하고 판정, 매치된 규칙, 이유를 반환합니다 — 아무것도 디스패치되지 않습니다. 그것은 호출이 어떤 규칙으로 해석되는지 확인합니다; 실제 목적지에 대해 CIDR/호스트 계산을 확인하려면 아래의 shadow mode를 사용하세요(Test 페이로드는 목적지를 담지 않으므로, egress 목록 매칭은 라이브 egress 트래픽에서 행사됩니다). 규칙 테스트 참조.
shadow mode를 켜면 egress deny가 차단 없이 발동할 대로 로깅됩니다. 표면 egress로 필터링된 이벤트 로그를 보고, 예상한 목적지를 잡는지 확인한 다음, shadow를 끄세요.
게이트웨이에서의 목적지 범위 지정은 최후의 선이 아니라 심층 방어입니다. 평가 시점에 호스트명이 해석되는 IP는 툴이 실제로 다이얼하는 것과 다를 수 있습니다(DNS 리바인딩). 자체 egress/dialer 계층에도 IP 거부 제어를 유지하세요; 게이트웨이 규칙은 명백한 경우를 위한 저렴한 사전 점검입니다.

​
6. 정책 연결과 누가 편집할 수 있는가

정책은 키가 그것으로 해석되기 전까지 아무것도 하지 않습니다. 키에 firewall_policy_id를 설정하여 콘솔에서 연결하거나, 정책을 워크스페이스 기본값으로 만드세요. 해석은: 키의 연결된 정책(존재하고 활성화된 경우), 그렇지 않으면 워크스페이스 기본값. 모든 egress 규칙 구성은 세션하에 콘솔에서(/api/workspace/firewall/*) 실행됩니다:
액션역할
정책, 프리셋, discovered tools, 자율성 Simulate 읽기Member
egress 규칙 및 정책 생성 / 편집 / 삭제Developer+
Test 엔드포인트 dry-run(POST /test)Developer+
이벤트 로그 및 실행 집계 읽기Developer+

​
관련

데이터 유출

egress 제어가 다루는 위협.

Stages

네 표면, 그리고 egress가 위치하는 곳.

Verdicts

deny, audit, allow이 와이어에서 하는 일.

툴 차단

목적지가 아니라 이름으로 fetch 툴을 거부합니다.

위험한 툴 호출

더 넓은 위험 부류.

Firewall 레퍼런스

egress 목록을 포함한 전체 규칙 + 매칭 레퍼런스.