메인 콘텐츠로 건너뛰기
firewall 정책은 에이전트가 만드는 모든 툴 호출에 대해 한 가지를 결정합니다: 판정. 규칙이 매치하여 판정을 생성하거나, 어떤 규칙도 매치하지 않아 정책의 기본 판정이 넘겨받습니다. 이 페이지는 둘 다 다룹니다 — 각 firewall 판정이 무엇을 하는지, cap_cost가 어떻게 해석되는지, 그리고 왜 audit이 시작하는 기본값인지. 판정이 규칙 문법 어디에 존재하는지는 Firewall Rules를 참조하고; 정책을 생성하는 동안 기본 판정을 고르는 것은 Create & attach를 참조하세요.

​
1. 여섯 가지 규칙 판정

규칙은 정확히 여섯 판정 중 하나를 생성합니다. 콘솔 규칙 편집기에서 작성하세요; 엔진은 규칙을 우선순위 순으로 순회하고 첫 매치가 이깁니다.
호출이 손대지 않은 채 진행됩니다. 여전히 이벤트 피드에 allow로 떨어지므로, 아무것도 차단하지 않으면서 감사 추적을 유지합니다. 기본 거부 정책에서 명시적 허가로 사용하세요.
allow과 동일한 트래픽 결과지만, 호출이 관찰하고 싶었던 것으로 플래그됩니다. 이는 또한 기본 판정이 박스에서 떨어지는 값입니다 — 강제할 준비가 될 때까지 모든 것을 관찰하고 아무것도 차단하지 않음.
호출이 툴에 결코 도달하지 않습니다. inbound 표면에서 릴레이는 오류 코드 firewall_blocked와 함께 HTTP 400을 반환하며 툴과 이유를 명명합니다; mcp 표면에서는 모델이 반응할 수 있도록 툴 오류로 돌아옵니다. block은 어떻게 보이는가 참조.
툴 호출 인자(에이전트가 command나 body 필드에 넣은 시크릿이나 PII)에서 매치된 부분 문자열을 가리고 정화된 호출을 전달합니다. 인자만 가립니다 — 툴이 반환하는 콘텐츠는 결코 건드리지 않습니다. inbound 표면에는 아직 호출 시점 인자가 없으므로 sanitize가 deny로 격상됩니다. 응답 정화 참조.
호출을 대역 외 검토로 전환합니다. 릴레이는 코드 firewall_approval_pending과 승인 id와 함께 HTTP 400을 반환합니다; 호출은 툴에 도달하지 않습니다. 검토자가 콘솔에서 또는 웹훅 콜백을 통해 그것을 해결하고, 에이전트는 일회용 승인 헤더와 함께 재제출합니다. approvals 참조.
비용 회로 차단기 — 규칙으로 작성되지만 평가 시점에 allow 또는 deny로 해석됩니다. §3과 cap cost 참조.
Shadow mode는 강제를 평탄화합니다. shadow mode에서 모든 강제 판정(deny, sanitize, pending_approval, 그리고 deny로 해석된 cap_cost)이 audit로 강등되고 이유에 [shadow] would …가 접두됩니다. 강제 정책을 이런 식으로 롤아웃하고 라이브로 전환하기 전에 이벤트 피드를 보세요.

​
2. 기본 판정

기본 판정(정책의 default_verdict)은 정책이 툴 호출에 어떤 규칙도 매치하지 않을 때 하는 일입니다. 그것은 자세의 바닥이며, 규칙 판정과 달리 세 값만 받습니다:
default_verdict어떤 규칙도 매치하지 않을 때…
audit (기본값)호출을 허용하되 기록합니다. 시작하기에 안전한 곳.
allow허용하고 로깅, 검토 레코드 없음.
deny규칙이 명시적으로 허용하지 않는 모든 것을 차단 — 기본 거부 자세.
새 정책은 **audit**으로 기본 설정됩니다: 강제 규칙을 추가하기 전까지 모든 툴 호출을 관찰하고 아무것도 차단하지 않습니다. 세 가지 규칙 전용 판정 — sanitize, pending_approval, 그리고 cap_cost — 은 기본값이 될 수 없습니다; 기본 판정은 포괄적 폴백이고, 그 판정들은 특정 매치에 범위 지정될 때만 의미가 있습니다.
기본 판정으로서 deny는 기본 거부입니다: 규칙이 명시적으로 allow하지 않는 모든 툴 호출은 차단됩니다. 잠긴 에이전트에 강력하지만, 허용 목록에 넣는 것을 잊은 호출을 멈추게 됩니다. 명시적 allow 규칙(툴 허용 목록)과 짝짓고 먼저 shadow mode하에서 롤아웃하세요.

​
3. cap_cost는 allow 또는 deny로 해석됩니다

cap_cost는 이벤트에 나타나는 것이 아닌 유일한 판정입니다. cap_cost_cents 상한으로 규칙을 작성하지만, 평가 시점에 엔진은 이벤트가 기록되기 전에 그것을 구체적인 allow 또는 deny로 해석합니다 — 그래서 이벤트 피드는 결코 리터럴 cap_cost 판정을 담지 않고, 에이전트가 실제로 본 allow/deny만 담습니다. 상한은 에이전트 실행당입니다: 엔진은 실행의 누적 지출을 상한에 대해 비교합니다.
  • 상한 미만 → allow로 해석. (내부적으로 이는 비매칭으로 취급되므로, cap_cost가 허가로서 첫 매치로 이기게 하기보다 평가가 다음 규칙으로 계속됩니다.)
  • 상한 초과 → deny로 해석, 실행의 총합 대 상한을 명명하는 이유와 함께. 이것이 종착, 회로 차단기 결과입니다.
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost는 디스패치 전 표면(inbound, mcp)에서만 발동합니다 — 호출 차단이 여전히 지출을 막는 지점. 디스패치 후 response와 egress 표면에서는 비활성입니다(멈출 것이 남아 있지 않음), 그래서 엔진이 거기서 그것을 건너뜁니다.

​
4. 판정이 선택되는 방식

임의의 툴 호출에 대해, 어떤 판정이 이기든 해석은 동일합니다:
게이트웨이는 호출하는 키에 연결된 정책(firewall_policy_id) 또는 워크스페이스 기본값을 고릅니다 — 해석 참조.
규칙은 priority ASC 순으로 실행됩니다. 표면, 툴 glob, 선택적 인자 절, 그리고 선택적 egress 범위가 모두 매치하는 첫 규칙이 판정을 생성합니다.
어떤 규칙도 매치하지 않으면, 정책의 default_verdict가 적용됩니다 — 변경하지 않았다면 audit.
호출이 통제되는 skill에 의해 소유되면, block 모드 skill은 deny를 강제하고 quarantine 모드 skill은 deny에 미치지 않는 모든 것을 pending_approval로 격상시킵니다.

​
5. deny의 비용 및 재시도 동작

inbound 표면의 firewall 판정은 업스트림 모델 호출 전에 발동하므로, 거기서의 deny는 모델 토큰을 들이지 않습니다. 오류는 skip-retry로 표시됩니다 — 동일하게 차단된 호출을 다시 실행하면 그저 다시 차단될 뿐이므로, 게이트웨이는 클라이언트에게 재시도하지 말라고 알립니다. 이는 guardrail block과 구별됩니다. 후자는 툴 액션이 아니라 프롬프트/응답 텍스트(PII, 시크릿)를 스크리닝하고 자체 guardrail_blocked 오류를 반환합니다. 요청은 두 평면 모두를 통과할 수 있습니다.
각 판정은 흔적을 남깁니다. 모든 평가 — allow, audit, deny, 해석된 cap_cost, 보류된 승인 — 가 firewall 이벤트로 기록되며, 판정, 표면, 툴, 실행으로 필터링 가능합니다. 이벤트 피드는 정책이 예상한 판정을 생성하고 있음을 확인하는 방법입니다. 이벤트 로그와 분석 참조.

​
다음으로 갈 곳

정책 생성 & 연결

기본 판정을 고르고 정책을 키에 바인딩합니다.

Cap cost

지출 상한을 작성하고 그것이 실행별로 어떻게 해석되는지.

Shadow mode

영향을 측정하는 동안 모든 강제 판정을 audit로 강등합니다.

규칙 레퍼런스

판정 뒤의 전체 매칭 언어.
이 판정들이 멈추기 위한 위협은 위험한 툴 호출과 과도한 자율성을 참조하세요.