메인 콘텐츠로 건너뛰기
툴을 허용 목록에 넣는 것은 에이전트가 어떤 툴을 호출할 수 있는지에 답합니다. 그것은 어떤 인자로에는 답할 수 없습니다. shell.exec는 ls에는 괜찮습니다; rm -rf /에는 재앙입니다. db.query는 레플리카에 대해서는 괜찮습니다; prod에 대해서는 책임입니다. 그 차이는 인자에 존재하며, 툴 이름 규칙은 그것을 볼 수 없습니다. Firewall의 인자 절(args_match_json)이 그 갭을 메웁니다. 그것은 모델이 툴 호출에 대해 선택한 구체적인 인자를 검사하고 그 값으로부터 판정을 결정합니다 — 그래서 툴을 폭넓게 허가하면서 그것이 취할 수 있는 한 가지 위험한 형태를 거부할 수 있습니다. 이 페이지는 그 절을 작성하는 데 집중한 가이드입니다; 전체 규칙 어휘는 Firewall rules를, 그 주변의 정책 모델은 Firewall을 참조하세요.
인자 값은 모델이 툴을 호출하는 방식을 선택한 후에만 존재하므로, 인자 절은 response와 mcp 스테이지에 속합니다. inbound에서는 — 에이전트가 툴 정의만 광고하는 곳 — 검사할 호출 시점 인자가 없습니다.

​
1. 언제 툴 호출 인자를 검증하는가

툴이 일반적으로는 안전하지만 특정 형태에서 위험할 때마다 인자 절을 사용하세요:

파괴적 명령

shell.exec을 허용하되, 명령이 rm -rf, mkfs, 또는 dd if=에 매치할 때 거부.

프로덕션 폭발 반경

db.query을 허용하되, 연결 대상이 prod일 때 거부(또는 승인 대기).

내부 목적지

fetch 툴을 허용하되, 그 url/ip 인자가 RFC-1918 범위나 클라우드 메타데이터 IP 안에 떨어질 때 거부.

과대 연산

벌크 툴을 허용하되, limit이나 count 인자가 수치 상한을 초과할 때 거부.
규칙은 여전히 먼저 툴 이름에 매치합니다; 절은 그것을 어떤 툴에서 어떤 호출로 좁힙니다.

​
2. 절 집합의 형태

args_match_json은 JSON으로 인코딩된 문자열이며, 그 디코딩된 값은 clauses 목록을 담은 객체입니다. 각 절은 { path, op, value } 3중항이고, 모든 절이 함께 AND됩니다 — 규칙은 모든 절이 참일 때만 발동합니다. 디코딩하면, 값은 다음과 같이 보입니다: 
{
  "clauses": [
    { "path": "$.command",    "op": "regex",      "value": "rm -rf|drop table" },
    { "path": "$.connection", "op": "in",         "value": ["prod", "replica"] },
    { "path": "$.ip",         "op": "cidr_match", "value": "10.0.0.0/8" }
  ]
}
규칙 본문에서 그 필드는 그 JSON을 단일 이스케이프 문자열로 담습니다 — 예: "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}". 비어 있거나 없는 args_match_json은 공허하게 참입니다 — 규칙은 이름만 있는 규칙이 하는 것과 정확히 같이, 자신의 툴 이름 glob만으로 매치합니다.

​
3. 연산자

일곱 연산자가 닫힌 어휘를 구성합니다. 콘솔은 저장 시 연산자와 그 값 형태를 검증하므로, 잘못 형성된 절은 결코 영속화되지 않습니다.
연산자매치하는 경우
eq스칼라 동등성(숫자는 수치적으로 비교; 타입 불일치는 매치 안 함).
contains부분 문자열 — 두 피연산자 모두 문자열이어야 함.
regexGo RE2 패턴이 문자열 값에 매치(선형 시간, 역참조 없음).
in값이 주어진 JSON 배열의 요소임.
cidr_match문자열 IP가 주어진 CIDR 안에 떨어짐.
gt / lt수치 초과 / 미만(문자열은 강제 변환되지 않음).

​
4. Path 구문

절의 path는 툴의 인자 객체에 대한 작은 JSONPath 부분집합입니다:
최상위 또는 중첩 객체 필드를 이름으로 읽습니다.
배열로 인덱싱하고, 선택적으로 요소의 필드로 계속합니다.
전체 인자 blob에 대해 매치합니다(contains나 regex로 거친 스캔에 유용).
와일드카드, 필터, 슬라이스, 또는 재귀 하강이 없습니다 — 문법은 의도적으로 작으므로 매칭이 핫 패스에서 선형 시간이고 예측 가능하게 유지됩니다.

​
5. 작동하는 예

에이전트가 shell.exec을 자유롭게 실행하게 하되, 재귀적 강제 삭제는 결코 셸에 도달해서는 안 됩니다. 명령 인자가 파괴적으로 보일 때만 shell.exec을 거부하는 하나의 response 스테이지 규칙을 작성하세요.
1

규칙 편집기 열기

콘솔에서, 에이전트의 키에 연결된 firewall 정책(또는 워크스페이스 기본값)을 열고 규칙을 추가합니다. 정책 편집은 Developer+ 액션입니다 — Member는 정책을 읽을 수 있지만 쓸 수는 없습니다.
2

response 스테이지에서 툴 매치

스테이지를 response로, 툴 glob를 shell.exec으로 설정합니다. response 스테이지는 절이 필요로 하는, 모델이 선택한 인자를 담습니다.
3

인자 절 추가

$.command에 하나의 regex 절을 추가한 다음, 판정을 deny로 설정합니다:
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm\\\\s+-rf|mkfs|dd\\\\s+if=\"}]}"
}
args_match_json은 JSON으로 인코딩된 문자열입니다; 그 디코딩된 값은 §2에 표시된 { "clauses": [ … ] } 객체입니다.
4

의존하기 전에 dry-run

Test 탭을 사용해 샘플 shell.exec 호출에 대해 규칙을 평가합니다. 판정, 매치된 규칙, 이유를 반환합니다 — 아무것도 디스패치되지 않고 아무것도 영속화되지 않습니다.
이제 "command": "ls -la"인 shell.exec은 이전과 같이 통과하고, "command": "rm -rf /var"은 거부됩니다. response의 deny는 모델이 툴 오류를 보고 반응하게 합니다 — 다른 툴 선택, 사용자에게 질문, 또는 중단 — 크래시 대신.
호출을 허가하되 차단하는 대신 누출된 값을 벗겨내고 싶나요? 판정을 sanitize로 바꾸세요. Sanitize는 절이 매치한 것을 가리지 않습니다 — 인자 문자열에 대해 별도의 리댁터(openai_key, anthropic_key, ssn_us 같은 이름 있는 프리셋과 자체 커스텀 regex)를 실행하고, 각 히트를 [redacted:…] 토큰으로 교체하고, 정화된 호출을 전달합니다. args_match_json 절은 여전히 규칙이 발동하는지를 결정합니다; 새니타이저는 무엇이 지워지는지를 결정합니다. 인자 정화 참조. Sanitize는 툴 호출 인자만 가립니다 — 툴이 반환하는 콘텐츠는 결코 아닙니다.

​
6. 절은 페일 클로즈됩니다 — 요청이 아니라 규칙이

절을 평가할 수 없으면 — path가 해석되지 않거나, 인자가 잘못 형성되었거나, regex / CIDR가 유효하지 않으면 — 절은 false로 평가되고 규칙은 그저 발동하지 않습니다. 호출은 다음 규칙이나 정책의 default_verdict로 떨어집니다. 깨진 절은 결코 자동 거부하지 않고 결코 릴레이를 방해하지 않습니다.
평가할 수 없는 절은 그 규칙을 매치하지 않게 만들므로, 결코 절이 특정 방식으로 실패하는 것에 기대지 마세요. “위험한 모든 것을 잡는” 규칙은 자체 툴 glob를 가진 명시적 deny로 작성하고, 인자 절은 허가를 좁히는 데 사용하세요 — 최후의 방어선으로가 아니라.

​
7. 절을 규칙의 나머지와 결합하기

인자 절은 규칙이 표현하는 다른 모든 것과 함께 쌓입니다 — 그것은 여러 개 중 하나의 AND된 조건입니다:
결합 대상효과
tool_name_glob절은 툴 이름이 매치한 후에만 실행됩니다 — 이름 먼저, 인자 다음.
skill_name_glob소유 skill별로 같은 툴의 인자를 다르게 게이트(예: community.*에 더 엄격).
verdict절을 deny뿐 아니라 sanitize, pending_approval, 또는 cap_cost와 짝지음.
다중 절모두 성립해야 함 — regex 명령 검사를 in 환경 검사와 결합해 deny를 좁게 범위 지정.
각 짝짓기가 생성하는 정확한 판정 의미는 Verdicts를; 보류된 호출이 어떻게 해석되는지는 Approvals를 참조하세요.

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

Firewall rules

완전한 규칙 레퍼런스 — glob, 절, 새니타이저, egress, 그리고 시퀀스.

인자 쿡북

흔한 위험 형태를 위한 복사-붙여넣기 args_match_json 레시피.

Firewall 스테이지

인자 절이 왜 inbound이 아니라 response와 mcp에 존재하는가.

툴 차단

어떤 인자도 안전하지 않을 때 툴을 통째로 거부합니다.
더 넓은 그림은 위험한 툴 호출과 OrcaRouter가 검사하는 방식을 참조하세요.