메인 콘텐츠로 건너뛰기
에이전트가 위험한 무언가를 하는 것을 멈추는 가장 빠른 방법은 툴을 명명하고 거부하는 것입니다. 툴 이름 glob에 대한 deny 판정은 에이전트 firewall의 거부 목록 기본형입니다: 규칙 하나, glob 하나, 판정 deny, 키에 연결됨 — 그 후로 게이트웨이는 모든 호출에서 그 툴을 거부하며, 에이전트 코드에 변경이 없습니다. 이 페이지는 거부 목록 사용 사례와 그것이 강제하는 하나의 결정을 다룹니다: 어느 표면에서 차단하는가 — 광고하는 툴(inbound)인가 모델이 발행하는 툴 호출(response)인가. 전체 매칭 어휘와 판정 의미는 규칙 스키마와 Verdicts를 참조하세요.

​
1. AI 에이전트가 만드는 툴 호출 차단

거부 목록 규칙은 firewall 정책이 표현할 수 있는 가장 간단한 것입니다: 이름으로 툴을 매치하고, deny를 반환합니다. 인자와 무관하게, 주어진 키에 대해 툴이 결코 발동해서는 안 될 때 사용하세요 — shell.exec, *.delete, 신뢰하지 않는 커뮤니티 플러그인. 워크스페이스 콘솔에서, 정책을 열고(또는 하나 생성) 규칙을 추가합니다: 
{
  "label": "block destructive shell",
  "tool_name_glob": "*.exec",
  "verdict": "deny"
}
tool_name_glob은 작고 대소문자 구분 glob입니다 — shell.*은 전체 패밀리를 잡고, *.delete는 서버 전반의 동사를 잡고, *은 모든 것을 잡습니다. 인자 절은 필요 없습니다: 맨 glob + deny는 툴을 무조건 차단합니다. 일반적으로는 툴을 허용하되 한 형태의 호출만 거부하고 싶을 때만 인자 절을 추가하세요.
엔진은 정책의 규칙을 우선순위 순으로 순회하고 첫 매치가 이깁니다. 좁은 allow 예외를 더 낮은 priority 숫자에(먼저 실행됨) 두고 광범위한 deny를 그 아래에 두세요 — 예: 신뢰하는 builtin.* skill에서 shell.exec을 허용하고, 그 외 모든 곳에서 거부합니다. 규칙 우선순위 참조.

​
2. Inbound 대 response: 표면 고르기

deny는 요청 수명 주기의 두 가지 다른 지점에 떨어질 수 있으며, 그 차이가 중요합니다. stage 필드로 규칙을 고정하거나, 비워두어 둘 다 커버하세요.

inbound

에이전트가 요청에서 모델에게 광고하는 툴(툴 정의). 여기서의 deny는 모델이 선택조차 하기 전에 툴을 벗겨냅니다 — 모델은 그것을 옵션으로 결코 보지 못합니다.

response

모델이 응답에서 발행하는 tool_calls. 여기서의 deny는 모델이 이미 하기로 결정한 호출을, 툴에 도달하기 전에 잡습니다.
툴이 보이지 않기를 원할 때는 **inbound**를 선호하세요 — 모델은 제공된 적 없는 것을 호출할 수 없으므로, 모델이 툴을 고르기만 하고 거부당하는 낭비된 턴을 피합니다. 툴이 일부 요청에서 정당하게 나타나고 실제 발행된 호출을 잡고 싶을 때, 또는 광고된 툴셋이 아니라 에이전트 루프만 통제할 때는 **response**를 사용하세요(또는 stage를 비워두세요).
stage가 없는 규칙은 모든 표면에 적용됩니다 — 같은 deny가 툴이 광고되든, 발행되든, MCP를 통해 디스패치되든 커버합니다. 그것이 안전벨트-멜빵 기본값입니다; deny가 하나에 범위 지정되어야 할 때만 표면을 고정하세요. Stages 참조.

​
3. 정책을 연결하고 발동하는 것을 보기

정책은 키가 그것으로 해석되기 전까지 아무것도 하지 않습니다. 키에 firewall_policy_id를 설정하여 콘솔에서 연결하거나, 정책을 워크스페이스 기본값으로 만드세요. 해석은: 키의 연결된 정책(존재하고 활성화된 경우), 그렇지 않으면 워크스페이스 기본값. (비활성화된 연결 정책은 기본값으로 폴백합니다 — 정책 관리 참조.) 연결되면, inbound 표면의 거부된 호출은 오류 코드 firewall_blocked와 툴을 명명하는 이유와 함께 HTTP 400을 반환합니다 — 예: tool "shell.exec" blocked by firewall. 오류는 skip-retry로 표시되고(동일한 호출을 다시 실행하면 그저 다시 차단될 뿐), inbound block은 업스트림 호출 전에 발동하므로 모델 토큰을 들이지 않습니다. MCP 게이트웨이를 통해 디스패치된 deny는 대신 툴 오류로 나타나므로, 모델이 거부를 보고 반응할 수 있습니다.
inbound 표면의 deny는 모델에게 제공되는 것에서 툴을 제거합니다. 에이전트 프레임워크가 광고한 툴이 호출 가능하기를 요구하면, 그것을 inbound로 차단하는 것이 루프를 혼란스럽게 할 수 있습니다 — 그 경우 대신 **response**에서 차단하여, 툴은 광고된 채로 두되 실제 호출은 거부하세요. 롤아웃하기 전에 차이를 테스트하세요(§5 참조).

​
4. Deny는 여러 판정 중 하나입니다

Deny는 거부 목록에서 가장 무딘 도구입니다. 하드 block이 과할 때, 같은 glob가 더 부드러운 판정을 담을 수 있습니다:
Verdictdeny 대신 언제 사용하는가
audit툴이 발동하는 것을 보고 싶지만 아직 차단하지는 않을 때.
sanitize툴은 괜찮지만 그 인자가 시크릿/PII를 담을 수 있을 때 — 인자를 가림, 툴 결과는 결코 아님.
pending_approval사람이 각 호출을 대역 외에서 승인해야 할 때.
cap_cost에이전트 실행의 지출이 센트 상한을 넘을 때까지 허용.
이들 모두는 Verdicts에 문서화되어 있습니다. 거부 목록은 그저 판정이 deny인 부분집합입니다. 허용 목록 자세(모든 것을 거부, 명명된 집합을 허가)에는 정책의 default_verdict를 deny로 뒤집고 좁은 allow 규칙을 추가하세요 — 툴 허용 목록 참조.

​
5. 안전하게 롤아웃하기

콘솔 Test 탭은 샘플 툴 호출에 대해 정책을 dry-run하고 판정, 매치된 규칙, 이유를 반환합니다 — 아무것도 디스패치되지 않고, 아무것도 영속화되지 않습니다. 키를 연결하기 전에 glob가 의도한 툴(그리고 오직 그 툴)에 매치하는지 확인하세요. 규칙 테스트 참조.
정책에 shadow mode를 켜면 모든 강제 판정 — deny 포함 — 이 이유에 [shadow] would …가 접두된 audit로 강등됩니다. 실제 트래픽에 대해 deny가 무엇을 차단할지 정확히 측정한 다음, shadow를 꺼서 강제하세요.
glob할 정확한 툴 이름이 확실하지 않나요? Discovered Tools 뷰는 워크스페이스가 본 모든 툴을 covered 또는 gap으로 플래그하여 나열합니다. 실제로 나타난 이름에서 바로 deny를 작성하세요. 분석 참조.
모든 평가는 판정, 표면, 툴, 매치된 규칙과 함께 firewall 이벤트를 씁니다. 강제한 후, 이벤트 로그를 판정 deny로 필터링하여 규칙이 예상한 호출에 발동하는 것을 보세요.

​
6. 누가 무엇을 할 수 있는가

모든 거부 목록 구성은 세션하에 콘솔에서(/api/workspace/firewall/*) 실행됩니다:
액션역할
정책, 프리셋, discovered tools, Simulate 읽기Member
정책 dry-run(Test)Developer+
규칙 및 정책 생성 / 편집 / 삭제Developer+
이벤트 로그 및 실행 집계 읽기Developer+
deny 규칙을 작성하거나 변경하는 것은 Developer+ 쓰기이며, 콘솔 Test dry-run도 마찬가지입니다. 정책 읽기와 읽기 전용 Simulate(“if” 가정) 뷰는 모든 멤버에게 개방됩니다.

​
관련

Glob 구문

shell.*, *.exec, *.shell.*이 정확히 어떻게 매치하는가.

툴 허용 목록

역 자세: 기본 거부, 명명된 집합을 허가.

인자 검증

전체 툴이 아니라 호출의 한 형태만 거부.

위험한 툴 호출

거부 목록이 다루는 위협.

Verdicts

deny와 더 부드러운 형제들이 와이어에서 하는 일.

Firewall 레퍼런스

전체 규칙 + 매칭 레퍼런스.