메인 콘텐츠로 건너뛰기
firewall 규칙은 툴 호출 수명 주기의 특정 지점에서 발동합니다. 그 지점이 그것의 스테이지입니다 — 네 가지 강제 표면 중 하나로, 각각 호출의 다른 조각을 봅니다. 규칙을 잘못된 스테이지에 고정하면 그것은 잘못된 데이터를 봅니다: inbound 표면의 egress 허용 목록은 검사할 목적지가 없고; inbound의 인자 절은 아직 호출 시점 인자가 없습니다. 이 페이지는 네 가지 에이전트 firewall 스테이지에 대한 집중 가이드입니다: 각 표면이 무엇을 관찰하는지, 규칙이 언제 그것을 타깃해야 하는지, 그리고 같은 의도가 서로 다른 스테이지에서 표현되는 한 가지 구체적인 방법. 전체 규칙 어휘는 Firewall rules를 참조하고; 그 주변의 정책 모델은 Firewall을 참조하세요.

​
1. 네 가지 스테이지 한눈에 보기

모든 평가는 정확히 하나의 스테이지로 표시됩니다. 스테이지가 없는 규칙("")은 그것들 모두에 적용됩니다; 한 스테이지에 고정된 규칙은 거기서만 발동합니다.
Stage표면이 보는 것
inbound에이전트가 요청에서 광고하는 툴
response모델이 응답에서 발행하는 tool_calls
mcpMCP 게이트웨이를 통해 디스패치된 tools/call
egress툴이 도달하는 아웃바운드 호스트 / IP / CIDR
스테이지 이름은 안정적인 enum 값입니다 — 규칙 편집기의 스테이지 필드에서 그대로 설정하거나, API를 통해 작성할 때 stage 속성으로 설정합니다.
스테이지는 어떤 데이터가 범위 안에 있는지를 통제하지, 판정이 얼마나 엄격한지를 통제하지 않습니다. deny는 어느 스테이지에서나 deny입니다; 변하는 것은 규칙이 매치할 인자, 툴 이름, 또는 목적지를 가지고 있는지 여부입니다.

​
2. inbound — 에이전트가 광고하는 툴

가장 이른 표면. 모델이 실행되기 전에, 에이전트는 모델이 호출하도록 허용할 툴 정의 목록을 보냅니다. inbound 스테이지는 그 광고된 툴셋을 보고 위험한 툴을 모델이 선택조차 하기 전에 차단할 수 있습니다. 이 스테이지에는 호출 시점 인자가 없습니다 — 모델이 아직 무엇을 어떻게 호출할지 결정하지 않았습니다 — 그래서 inbound 규칙은 args_match_json이 아니라 툴 이름(그리고 선택적으로 그 소유 skill)에 매치합니다.
inbound의 sanitize 판정은 가릴 것이 없으므로(아직 인자가 존재하지 않음) block으로 격상됩니다. inbound 규칙은 명시적 allow / deny로 작성하고, sanitize는 실행 스테이지를 위해 남겨두세요.
여기서 거부된 호출은 코드 firewall_blocked와 함께 HTTP 400을 반환하며, 툴과 이유로 명명되고 skip-retry로 표시됩니다.

​
3. response — 모델이 발행하는 툴 호출

모델이 응답하면, 하나 이상의 tool_calls — 실제 인자를 가진 구체적인 호출 — 을 발행할 수 있습니다. response 스테이지는 그것들을 보므로, 여기가 인자 수준 규칙이 속하는 곳입니다: “shell.exec 차단”이 아니라 “명령이 rm -rf일 때만 shell.exec 차단.” 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
모델이 선택한 인자가 존재하므로, sanitize가 여기서 작동합니다 — 호출 인자에서 매치된 부분 문자열을 가리고 정화된 호출을 전달합니다. (Sanitize는 툴 호출 인자만 가립니다; 툴이 반환하는 콘텐츠는 결코 건드리지 않습니다.)

​
4. mcp — 게이트웨이를 통해 디스패치된 호출

에이전트가 OrcaRouter의 MCP 게이트웨이를 통해 툴에 도달하면, 모든 tools/call이 등록된 서버로 디스패치되기 전에 mcp 스테이지에서 평가됩니다. 이것이 Model Context Protocol 트래픽을 통제하는 표면입니다 — response와 동일한 glob / 인자 / 판정 어휘가 MCP 디스패치에 적용됩니다. 여기서의 block은 전송 실패가 아니라 툴 오류(firewall deny: <reason>)로 나타나므로, 모델이 거부를 보고 반응할 수 있습니다 — 다른 툴 선택, 사용자에게 질문, 또는 중단.
mcp 스테이지는 서버별 통제와 짝을 이룹니다: 등록된 각 MCP 서버는 자체 health probe와 암호화된 자격 증명을 가지며, 그것을 통해 로드된 skill은 위험 등급과 강제 모드를 지닙니다. Firewall MCP와 Firewall skills 참조.

​
5. egress — 툴이 도달하는 아웃바운드 목적지

마지막 표면. 툴이 아웃바운드 네트워크 목적지를 보고하면, egress 스테이지가 그것에 매치합니다 — SSRF 및 데이터 유출 표면. Egress 규칙은 툴 이름 패턴만으로 매치하지 않습니다; 호스트 / IP / CIDR 목록에 매치합니다: 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
항목은 CIDR, IP 리터럴, 또는 대소문자 구분 없는 호스트명으로 매치합니다. 호스트와 CIDR 거부 규칙은 직접 작성합니다 — 클라우드 메타데이터 엔드포인트(169.254.169.254)와 RFC-1918 범위가 거부할 정전(canonical) 대상입니다. 허용/거부 극성은 Firewall rules §6을 참조하세요.
어떤 프리셋도 CIDR 규칙을 제공하지 않습니다. tight 자율성 수준의 SSRF 자세는 fetch 형태의 툴 이름(예: http_fetch, web_search, fetch_url)을 거부합니다; 목적지 기반 egress 거부는 에이전트가 결코 도달해서는 안 되는 호스트와 범위를 위해 직접 작성하는 것입니다.

​
6. 올바른 스테이지 선택

같은 보안 목표는 종종 최적의 스테이지를 가집니다. 의도를 실제로 필요한 데이터를 담은 표면에 맞추세요:
모델이 툴을 결코 보지조차 못하게 하려면, inbound에서 거부하세요. block은 모델 호출 전에 떨어지므로 모델 토큰을 들이지 않습니다.
인자 절은 모델이 선택한 인자를 필요로 하며, 이는 response와 mcp에만 존재합니다. 위험한 인자에서 거부하거나, 에이전트가 인자에 넣은 시크릿이나 PII 값을 벗겨내기 위해 sanitize하세요.
MCP 게이트웨이를 통해 라우팅된 호출은 디스패치 전에 mcp에서 평가됩니다 — 등록된 모든 서버의 툴을 위한 초크 포인트.
목적지 기반 규칙 — 클라우드 메타데이터 IP 차단, CIDR 거부, 승인된 호스트 허용 목록 — 은 egress에서만 의미가 있습니다.
스테이지가 없는 규칙은 네 가지 모두에서 실행됩니다. 포괄적인 default_verdict 스타일 규칙이나 나타나는 모든 곳에서 거부하는 툴에 사용하세요.

​
7. 스테이지와 shadow mode

정책의 shadow_mode 플래그는 스테이지와 독립적입니다. 그것을 켜면 어느 스테이지에서든 모든 강제 판정이 audit로 강등되고 이유에 [shadow] would …가 접두되므로, 규칙이 라이브 트래픽을 변경하기 전에 올바른 표면에서 발동하는지 확인할 수 있습니다. Shadow mode와 강제 모드 참조.

​
8. 스테이지가 큰 그림에 어디에 들어맞는가

네 가지 스테이지는 강제의 어디서입니다; 모델의 나머지는 무엇과 누구입니다.

Verdicts

각 스테이지가 매치한 후 할 수 있는 것 — 허용, 감사, 거부, 정화, 승인 대기, 비용 상한.

툴 허용 목록

inbound를 사용해 에이전트가 광고하는 툴셋을 제약합니다.

인자 검증

툴을 어떻게 호출되는지로 게이트하는 response / mcp 인자 절을 작성합니다.

Egress 제어

egress 표면에서 아웃바운드 목적지를 차단합니다 — 유출 경계.
이 표면들이 검사 경로에 어떻게 위치하는지는 OrcaRouter가 검사하는 방식과 강제 경로 지연 노트를 참조하세요. 각 스테이지가 다루는 위협은 위험한 툴 호출, 데이터 유출, 그리고 MCP 툴 포이즈닝을 참조하세요.