메인 콘텐츠로 건너뛰기
AI 에이전트는 텍스트를 생성하기만 하는 것이 아닙니다 — 행동합니다. shell.exec를 호출하고, 데이터베이스를 질의하고, URL을 가져오고, MCP 서버를 통해 툴을 디스패치합니다. 이들 각각은 프롬프트 수준 guardrail이 볼 수 없는 실제 세계의 액션입니다. 에이전트 firewall은 이를 통제하는 액션 계층 평면입니다: 게이트웨이가 모든 툴 호출에 대해 — 툴에 도달하기 전에 — 평가하는 워크스페이스 범위의, 이름이 지정된 정책. 이 페이지는 Firewall 섹션의 허브입니다 — 정책 모델, 판정, 표면, 그리고 정책이 키에 연결되는 방식. 각 스포크는 더 깊이 들어가며, 전체 엔진 레퍼런스는 Firewall과 Firewall Rules에 있습니다.

​
1. 에이전트 firewall이 하는 일

워크스페이스 콘솔에서 정책을 한 번 작성하고, API 키를 그것에 연결하거나(또는 하나를 워크스페이스 기본값으로 설정), 그 후로는 그 키가 발행하는 모든 툴 호출이 게이트웨이에서 정책에 대해 검사됩니다. 재배포 없음, 에이전트 코드 변경 없음 — 에이전트는 이전과 정확히 동일하게 툴 호출을 계속 발행하며, 정책을 편집하면 그것에 연결된 모든 키에서 바로 다음 호출에 반영됩니다. 정책은 순서가 있는 규칙 목록입니다. 각 규칙은 어떤 툴 호출에 적용되는지와 그것에 대해 무엇을 할지를 결정합니다. 엔진은 규칙을 우선순위 순으로 순회하며, 첫 매치가 이기고, 아무것도 매치하지 않으면 정책의 기본 판정으로 폴백합니다.
탐지는 게이트웨이에서, 최초 사용 시 일어납니다 — 설치 시점이 아닙니다. 에이전트가 자체 설치한 툴, MCP 서버, 또는 skill은 그 호출이 게이트웨이를 처음 가로지를 때 포착됩니다. 그것은 기능이 어떻게 거기에 도달했는지와 무관하게 모든 프로바이더, 모든 에이전트, 모든 툴 호출을 보는 단일 초크 포인트입니다.

​
2. 구체적인 예

파괴적 셸 명령은 차단하되 그 외 모든 것은 감사하에 통과시키고 싶다고 가정합시다. 콘솔에서 default_verdict = audit과 하나의 규칙으로 정책을 생성합니다: 
{
  "label": "block rm -rf",
  "tool_name_glob": "*.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"}]}",
  "verdict": "deny"
}
args_match_json은 JSON으로 인코딩된 문자열입니다(게이트웨이가 저장 시 절 스키마에 대해 검증합니다): path는 호출 인자로의 JSONPath이고, op는 eq, contains, regex, in, cidr_match, gt, lt 중 하나입니다. 키를 정책에 연결합니다(키에 firewall_policy_id를 설정). 이제 에이전트가 command: "rm -rf /"로 shell.exec를 발행하면, 게이트웨이는 오류 코드 firewall_blocked와 툴을 명시하는 이유와 함께 HTTP 400을 반환합니다 — 그리고 호출은 셸에 결코 도달하지 않습니다. 다른 모든 툴 호출은 허용되고 검토를 위해 기록됩니다.
새 정책은 먼저 shadow mode하에서 롤아웃하세요: 프로덕션에서와 정확히 동일하게 평가하고 로깅하지만, 모든 강제 판정이 audit로 강등되고 이유에 [shadow] would …가 접두됩니다. 이벤트 피드를 본 다음, shadow를 꺼서 강제하세요.

​
3. 정책, 규칙, 그리고 해석

정책은 워크스페이스 범위이고 이름이 지정되며, enabled, is_default, default_verdict(allow / audit / deny, 기본값 audit), 그리고 shadow_mode 플래그를 가집니다. 규칙은 그 안의 한 검사입니다 — 정책 생성과 규칙 스키마 참조. 임의의 툴 호출에 대해 게이트웨이는 활성 정책을 다음 순서로 해석합니다:
  1. 키 연결 — 호출하는 키의 firewall_policy_id, 그 정책이 존재하고 활성화된 경우.
  2. 워크스페이스 기본값 — 그렇지 않으면 활성화된 is_default 정책.
비활성화된 연결 firewall 정책은 워크스페이스 기본값으로 폴백합니다 — 이는 guardrails와 다릅니다. guardrails에서는 비활성화된 연결이 없음으로 해석됩니다. 키의 firewall 오프 스위치는 “강제 없음”이 아니라 “기본값을 사용하라”입니다. 정책 관리 참조.
어떤 정책도 전혀 해석되지 않으면, 동작은 워크스페이스 firewall_observe_mode 설정에 따라 달라집니다: observe mode 켬일 때 호출은 허용되지만 커버리지 갭으로 로깅됩니다(Discovered Tools에 나타남); 꺼져 있으면 호출이 조용히 허용됩니다.

​
4. Verdicts

규칙 — 또는 기본값 — 은 다음 중 하나를 생성합니다:
Verdict무엇을 하는가
allow통과시킴, 로깅됨.
audit허용 + 검토를 위해 기록. 일반적인 기본값.
deny차단. inbound에서는 HTTP 400 firewall_blocked; MCP에서는 툴 오류.
sanitize툴 인자에서 매치된 부분 문자열을 가리고 전달.
pending_approval사람을 위해 보류; HTTP 400 firewall_approval_pending.
cap_cost실행의 지출이 규칙별 상한을 넘으면 거부.
sanitize 판정은 호출 인자만 가립니다 — 툴이 반환하는 콘텐츠는 결코 건드리지 않습니다. inbound 표면에서는 아직 호출 시점 인자가 없으므로 sanitize가 block으로 격상됩니다. Verdicts와 응답 정화 참조.

​
5. 네 가지 강제 표면

모든 툴 호출은 정확히 하나의 표면에 대해 평가됩니다 — stage 필드로 규칙을 하나에 고정하거나, 비워두어 모두에 적용하세요.

inbound

에이전트가 요청에서 모델에게 광고하는 툴. 위험한 툴을 모델이 선택조차 하기 전에 차단합니다.

response

모델이 응답에서 발행하는 tool_calls.

mcp

MCP 게이트웨이를 통해 디스패치된 tools/call. MCP 서버 참조.

egress

툴이 도달하는 아웃바운드 호스트 / IP / CIDR — SSRF 및 데이터 유출 표면.

​
6. 매칭

규칙은 핫 패스에서 안전한, 작고 결정론적인 어휘로 어떤 툴 호출을 포착하는지를 표현합니다:
툴 이름에 대한 대소문자 구분 glob(shell.*, *.delete), 선택적으로 소유 skill에 대한 glob과 AND로 결합됨. Glob 구문과 툴 허용 목록 참조.
eq, contains, regex, in, cidr_match, gt, lt 연산자로 호출 인자에 대한 JSONPath 술어 — “shell.exec 차단”과 “명령이 rm -rf일 때만 차단”의 차이. 절은 페일 클로즈됩니다(요청이 아니라 규칙이). 인자 검증 참조.
egress 표면의 호스트 / IP / CIDR 허용 및 거부 목록. 클라우드 메타데이터나 RFC-1918 범위에 대한 자체 거부 규칙을 작성할 수 있습니다. Egress 제어 참조.
sequence 규칙은 윈도우에 걸친 순서가 있는 호출 체인을 매치합니다(반응적으로 강제됨); cap_cost 규칙은 에이전트 실행의 누적 지출이 센트 상한을 넘으면 거부합니다. 시퀀스 규칙과 비용 상한 참조.

​
7. Human approval, 자율성, 그리고 이상

  • Human-in-the-loop. pending_approval 판정은 호출을 보류하고 그 승인 id를 반환합니다. 검토자가 콘솔에서(Developer+) 또는 HMAC 서명 웹훅 콜백을 통해 그것을 해결합니다; 에이전트는 폴링하고 일회용 X-OrcaRouter-Firewall-Approval 헤더와 함께 재제출합니다. Approvals와 승인 웹훅 참조.
  • 자율성 수준. 단일 스위치가 전체 자세를 설정합니다: tight(기본 거부 + 파괴적 셸 거부 + fetch 형태의 툴 (http_fetch/web_search/fetch_url/request, SSRF 벡터) 거부 + PII Shield + Secrets Blocker 강제), balanced(기본 감사, 파괴적 셸 거부, PII Shield 감사 전용), 또는 permissive(observe 전용). 각각은 실제의, 편집 가능한 정책 및 guardrail 행을 작성하며, 감사 스냅샷에서 원클릭 실행 취소를 제공합니다.
  • 이상 탐지. 정적 규칙을 넘어, firewall은 학습된 주중 시간대 베이스라인(14일)에 대해 툴 사용을 채점하고 속도/비용 급증, retry_loop, novel_path를 최대 7일까지 스누즈할 수 있는 Member 판독 가능한 피드에 플래그합니다.

​
8. Firewall이 어디에 들어맞는가

Firewall은 인접한 두 평면의 액션 계층 동료입니다:
평면통제 대상언제 사용하는가
Guardrails프롬프트 & 응답 텍스트PII, 시크릿, 탈옥, 인젝션 의도
에이전트 firewall툴 액션어떤 툴, MCP 호출, 호스트, 그리고 비용
Compliance증거 & 프레임워크SOC 2 / HIPAA / EU AI Act 준비
콘텐츠 평면과 액션 평면 둘 다 단일 요청에 적용될 수 있으며, 자율성 수준이 그것들을 함께 구성합니다. Guardrails vs. Firewall과 제어 스택 참조.

​
9. 연결하고 접속하기

정책은 firewall_policy_id를 통해 키에 바인딩됩니다(콘솔에서 구성됨; 바인딩은 게이트웨이의 키에 존재). 툴 호출이 엔진에 도달하는 방법은 두 가지이며, 둘 다 firewall-gateway-scoped 키(is_firewall_gateway = true)를 요구합니다 — 일반 릴레이 키는 이 라우트들에서 403을 받습니다:
  • MCP 게이트웨이 — MCP 클라이언트를 통합 ANY /api/v1/firewall/mcp 엔드포인트로 가리킵니다; 모든 tools/call이 인라인으로 평가됩니다. MCP 서버 참조.
  • Evaluate 훅 — 디스패치하기 전에 자체 에이전트 루프에서 POST /api/v1/firewall/evaluate(또는 다단계 계획을 위한 /evaluate_plan)를 호출하고, 판정에 따라 행동합니다.
모든 콘솔 구성은 /api/workspace/firewall/*을 통해 세션하에서 실행됩니다. 정책, 설정, discovered tools, 읽기 전용 자율성 시뮬레이터, 그리고 이상 피드 읽기는 모든 워크스페이스 멤버에게 개방됩니다; dry-run Test 샌드박스, Events / Runs 로그, 그리고 모든 쓰기는 **Developer+**를 요구합니다. 게이트웨이 키와 규칙 테스트 참조.

​
10. 이 평면이 다루는 위협

위험한 툴 호출

파괴적 셸, DB drop, 위험한 동사를 glob + args로 거부합니다.

데이터 유출

Egress 목록과 read-then-export 시퀀스 규칙.

MCP 툴 포이즈닝

디스패치 전 mcp 표면에서의 호출별 평가.

과도한 자율성

승인, 비용 상한, 그리고 기본 거부 자세.

​
다음 단계

정책 생성

첫 정책과 규칙을 작성합니다.

Verdicts

각 판정이 와이어에서 무엇을 하는가.

이벤트 로그

firewall이 무엇을 왜 결정했는지 읽습니다.