메인 콘텐츠로 건너뛰기
두 규칙이 같은 툴 호출에 모두 매치할 수 있을 때, firewall 규칙 우선순위가 어느 것이 이기는지 결정합니다. firewall 정책은 순서가 있는 규칙 목록입니다 — 엔진은 그것을 우선순위 순으로 순회하고, 매치하는 첫 번째에서 멈추고, 그 판정을 적용합니다. 순서를 맞추면 광범위한 가드와 좁은 예외가 깔끔하게 공존합니다; 틀리면 광범위한 규칙이 깎아내려던 예외를 삼킵니다. 이 페이지는 순서 지정에 대한 집중 레퍼런스입니다. 전체 규칙 문법은 Firewall Rules를; 규칙이 생성할 수 있는 판정은 Verdicts를 참조하세요.

​
1. 순서: 우선순위 오름차순, 첫 매치 승리

정책 내에서, 규칙은 priority ASC, id ASC 순으로 평가됩니다:
  1. 낮은 priority가 먼저 실행됩니다. priority: 0인 규칙이 priority: 10인 것보다 먼저 검사됩니다. 강도 점수가 아니라 큐 위치로 생각하세요 — 더 작은 숫자가 먼저 말합니다.
  2. 동점은 규칙 id로 깨집니다. 같은 priority의 두 규칙은 생성 순서(오름차순 규칙 id)로 실행되므로, 더 오래된 규칙이 동점을 이깁니다. 순서가 실제로 중요할 때는 id 동점 깨기에 기대기보다 구별되는 우선순위를 사용하세요.
  3. 첫 매치가 이깁니다. 엔진은 조건이 모두 성립하는 첫 규칙에서 멈추고 그 판정을 적용합니다. 목록 아래의 규칙은 그 호출에 대해 결코 참조되지 않습니다.
  4. 매치 없음 → 기본 판정. 아무것도 매치하지 않으면, 정책의 default_verdict이 적용됩니다 — 변경하지 않았다면 audit.
규칙은 모든 선언된 조건이 한 번에 성립할 때만 매치합니다: 표면, 툴 이름 glob, 선택적 skill glob, 선택적 인자 절, 그리고 egress 범위(egress 규칙만). 부분 매치는 매치가 아니고, 평가는 다음 규칙으로 이동합니다.

​
2. 하나의 구체적인 예: 구체적인 것을 광범위한 것 앞에

정전(canonical) 순서 지정 작업은 좁은 allow가 광범위한 deny에서 살아남게 하는 것입니다. 구체적인 규칙을 더 낮은 우선순위에 두어 먼저 도달되게 하세요: 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
shell.echo에 대한 호출은 Rule A(우선순위 10)에 먼저 부딪혀, 매치하고, 허용됩니다 — 엔진은 Rule B에 결코 도달하지 않습니다. shell.exec에 대한 호출은 A를 빠져나가(glob가 매치 안 함), Rule B에 부딪혀, 거부됩니다. 우선순위를 뒤집으면 우선순위 10의 광범위한 shell.* deny가 shell.echo을 먼저 잡고, 우선순위 20의 allow은 죽은 코드가 됩니다. 경험칙: 가장 구체적인 것 먼저, 가장 광범위한 것 마지막.
이를 위해 id 동점 깨기에 의존하지 마세요. allow과 deny가 같은 priority를 공유하면, 승자는 먼저 생성한 규칙입니다 — 규칙을 삭제하고 다시 생성하면 조용히 뒤집히는 취약한 순서. 구체적인 규칙에 더 낮은 priority를 주면 의도가 명시적입니다.

​
3. 의존하기 전에 순서 확인

종이 위에서 우선순위를 추론하는 것은 정책에 규칙이 몇 개를 넘으면 오류가 나기 쉽습니다. Test 샌드박스는 샘플 툴 호출에 대해 실제 엔진을 실행하고 판정뿐 아니라 어느 규칙이 이겼는지도 알려줍니다 — 그래서 예상한 규칙이 실제로 발동했는지 확인할 수 있습니다:
1

정책의 Test 탭 열기

콘솔에서, 정책을 열고 Test로 전환합니다(Developer+).
2

샘플 호출 제출

툴 이름(그리고 규칙이 검사하면 인자)을 입력하고 실행합니다. 아무것도 디스패치되지 않고 아무것도 영속화되지 않습니다 — dry run입니다.
3

매치된 규칙 읽기

결과는 판정, 매치된 규칙(레이블/id로), 그리고 이유를 명명합니다. 좁은 것을 예상한 곳에서 광범위한 규칙이 이겼으면, 좁은 규칙의 priority를 낮추고 다시 테스트하세요.
전체 샌드박스는 규칙 테스트를, 규칙 순서를 제자리에서 편집하는 것은 정책 관리를 참조하세요.

​
4. Skill 강제가 위에 올라탑니다

규칙 우선순위는 이긴 규칙의 판정을 결정합니다 — 하지만 그것이 항상 최종 답은 아닙니다. 툴 호출이 통제되는 skill에 의해 소유되면, skill의 강제 모드가 첫 매치 해석 후 이긴 판정 위에 적용됩니다:
Skill 모드이긴 판정에 대한 효과
allow변경 없음 — 규칙 판정 유지.
quarantinedeny에 미치지 않는 모든 것을 pending_approval로 격상; 기존 deny는 그대로 둠.
block규칙 판정과 무관하게 deny를 강제.
그래서 quarantine skill은 규칙의 allow을 보류된 호출로 바꿀 수 있고, block skill은 어떤 규칙도 그 툴을 지명하지 않을 때조차 호출을 거부합니다. Quarantine은 격상만 합니다 — deny를 더 부드러운 것으로 결코 강등하지 않습니다. 이것이 위험으로 자동 탐지된 skill이 규칙이 아무리 허용적이어도 검토할 때까지 격리된 채로 유지되는 이유입니다.
Skill 모드는 규칙이 아니므로, priority가 없고 규칙에 상대적으로 재정렬할 수 없습니다. 그것은 항상 이긴 판정이 선택된 후에 평가됩니다. 통제되는 skill의 모드가 허용을 예상한 호출을 차단하고 있으면, 더 높은 우선순위 allow 규칙을 추가하는 것이 아니라 skill에서 고치세요 — 규칙은 모드를 재정의할 수 없습니다.

​
5. 첫 매치를 타지 않는 것들

몇 가지 메커니즘은 규칙별 우선순위 순회 밖에 위치합니다 — 그것들을 정렬하려 하지 않도록 어디에 떨어지는지 아세요:
상한 미만의 cap_cost 규칙은 비매칭으로 취급되므로, 그것이 허가로서 첫 매치로 이기게 하기보다 평가가 다음 규칙으로 계속됩니다. 상한 초과면 deny로 해석됩니다. 그것은 도달되었다는 것만으로 더 낮은 우선순위 규칙을 결코 단락하지 않습니다.
시퀀스 규칙은 시간 윈도우에 걸친 호출의 체인에 매치하므로, 체인을 완성하는 단일 호출이 아니라 비동기 매처에 의해 반응적으로 강제됩니다. 그것은 이벤트 피드를 켜지만 개별 호출에 대해 첫 매치 순회를 이기지 않습니다.
Shadow mode는 어느 규칙이 이기는지를 변경하지 않습니다 — 첫 매치 해석 후 이긴 강제 판정을 audit로 강등합니다(이유에 [shadow] would … 접두), 그래서 정책이 트래픽을 변경하기 전에 그 영향을 측정할 수 있습니다.

​
6. 종합하기

임의의 툴 호출에 대해 전체 해석은:
  1. 정책 해석 — 호출하는 키에 연결된 것, 또는 워크스페이스 기본값. 범위 참조.
  2. priority ASC, id ASC로 규칙 순회 — 첫 매치가 이김; 매치 없음 → default_verdict.
  3. Skill 강제 적용 — 통제되는 skill의 모드가 이긴 판정 위에 올라탐(block은 deny 강제, quarantine은 격상).
  4. Shadow mode 적용 — 켜져 있으면, 강제 판정을 audit로 강등.
  5. 이벤트 기록 — 판정, 표면, 툴, 그리고 매치된 규칙이 이벤트 피드에 떨어짐.
규칙의 우선순위를 편집하면 정책에 연결된 모든 키에 대해 다음 호출에 효력을 발휘합니다 — 재배포 없음, 에이전트 코드 변경 없음. 재정렬 후 라이브 트래픽이 그것에 의존하기 전에 Test 샌드박스를 다시 실행하여 새 승자를 확인하세요.

​
다음으로 갈 곳

Verdicts

각 이긴 판정이 실제로 하는 일.

Glob 구문

툴 이름 매칭이 규칙이 후보인지조차 어떻게 결정하는가.

규칙 테스트

정책을 dry-run하고 어느 규칙이 이기는지 보세요.

툴 허용 목록

순서에 가장 강하게 기대는 기본 거부 패턴.
규칙 뒤의 매칭 언어는 전체 Firewall Rules 레퍼런스를; skill이 위에 어떻게 계층화되는지는 Firewall Skills와 강제 모드를 참조하세요.