메인 콘텐츠로 건너뛰기
모델이 응답할 때, 텍스트만 반환하는 것이 아닙니다 — tool_calls를 발행합니다: 실제의, 모델이 선택한 인자를 가진 구체적인 호출. 에이전트 firewall의 response 표면은 모델을 떠나는 그 순간 그리고 에이전트 루프에 도달하기 전에, 정확히 그것들을 검사합니다. 그것은 모델이 실제로 하기로 결정한 것을, 실제로 고른 인자로 필터링하는 표면입니다. 이 페이지는 response 표면에서 필터링하는 사용 사례를 다룹니다 — inbound 대신 언제 그것을 사용하는지, 그것이 추가하는 하나의 판정 트위스트, 그리고 스트림에서 어떻게 동작하는지. 전체 규칙 어휘와 판정 의미는 규칙 스키마와 Verdicts를 참조하세요.

​
1. 인자가 범위 안에 있는, LLM 툴 응답 호출 필터링

inbound 스테이지는 광고하는 툴을 봅니다 — 이름만, 아직 호출 시점 인자 없음. response 스테이지는 모델이 발행하는 tool_calls를 보며, 그것은 모델이 선택한 인자를 담습니다. 그것이 여기서 필터링하는 온전한 이유입니다: 클라이언트 실행(비-MCP) 툴에 대해 실제 호출 + 인자를 보는 유일한 표면이므로, 인자 절, 시퀀스, 그리고 실행 상태 규칙이 모두 response에 떨어집니다. 한 줄로 보는 구별:
Stage보는 것사용처
inbound광고된 툴 정의모델에게 툴을 보이지 않게 함
response발행된 tool_calls + 인자모델이 실제로 한 호출을 필터링
그래서 inbound은 어떤 툴이 존재하는지에 답하고; response는 모델이 그것으로 무엇을 했는지에 답합니다. 툴이 일부 요청에 정당하게 나타나지만 그것의 특정 호출이 위험할 때 — 또는 광고된 툴셋이 아니라 에이전트 루프만 통제할 때 — response를 사용하세요(또는 둘 다 커버하려면 stage를 비워두세요).
stage가 없는 규칙은 response을 포함한 모든 표면에서 실행됩니다. 규칙이 발행된 호출만 검사해야 할 때만 response에 고정하세요 — 예를 들어 inbound 표면에서 어차피 매치할 것이 없는 인자 절. Stages 참조.

​
2. 하나의 구체적인 예

shell.exec을 일반적으로 허용하되, 그 command 인자가 파괴적으로 보이는 순간 모델의 응답에서 그것을 벗겨냅니다. 워크스페이스 콘솔에서, 정책을 열고(또는 하나 생성) response 표면에 고정된 규칙을 추가합니다: 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
인자 매처는 args_match_json에 존재합니다 — {"clauses":[…]}를 담은 JSON 문자열로, 각 절은 path / op / value 3중항(op은 eq, contains, regex, gt, lt 중 하나)입니다. 콘솔 폼이 그것을 구축해 줍니다; 필드 이름이 모호하지 않도록 원시 형태를 여기 보여줍니다. 툴은 광고된 채로 유지됩니다 — 모델은 여전히 shell.exec을 제안할 수 있습니다 — 하지만 발행된 호출이 파괴적 command를 담으면, firewall은 에이전트가 보기 전에 그 tool_call을 응답에서 제거합니다. 무해한 shell.exec(가령 ls -la)은 손대지 않은 채로 통과합니다. 이것이 response 표면이 존재하는 “툴을 허용, 호출을 게이트” 패턴입니다; 인자 절이 그것을 가능하게 합니다.
규칙은 우선순위 순으로 평가되며, 첫 매치가 이깁니다. 좁은 allow 예외를 광범위한 deny보다 낮은 priority 숫자에 두어 예외가 먼저 실행되게 하세요. 규칙 우선순위 참조.

​
3. response 표면에서 판정이 하는 일

response 표면은 발행된 각 tool_call을 검사하고 응답을 제자리에서 다시 씁니다. 유지된 호출은 바이트 단위로 전달됩니다; 매치된 호출만 변합니다:
매치된 tool_call이 에이전트에 도달하기 전에 모델의 응답에서 제거됩니다. 코드 firewall_blocked와 함께 HTTP 400을 반환하는 inbound deny와 달리 — response 표면 deny는 요청을 실패시키지 않습니다; 응답의 나머지(다른 툴 호출, 모든 텍스트)는 문제의 호출이 그저 부재한 채로 통과합니다.
호출의 인자에서 매치된 부분 문자열이 엔진의 가려진 인자로 교체되고 정화된 호출이 전달됩니다 — 툴은 괜찮지만 모델이 인자에 시크릿이나 PII 값을 넣었을 때 유용. Sanitize는 툴 호출 인자만 가립니다; 툴이 반환하는 콘텐츠는 결코 건드리지 않습니다. 엔진이 치환할 것이 없으면, 호출이 벗겨집니다(페일 클로즈). 응답 정화 참조.
Human-in-the-loop 보류는 response가 아니라 inbound 표면에서 열립니다. 따라서 발행된 호출에 먼저 매치하는 pending_approval 규칙은 벗겨집니다(페일 클로즈) — 그것을 유지하면 사람 결정 없이 검토되지 않은 호출을 전달하게 됩니다. HITL 보류는 inbound에서 발동하도록 작성하세요; Approvals 참조.
allow과 audit 둘 다 호출을 전달합니다; audit은 일반적인 default_verdict입니다 — 강제할 준비가 될 때까지 모든 것을 기록하고 아무것도 차단하지 않음.
cap_cost와 pending_approval은 이 표면에서 inbound 개념입니다. cap_cost는 response에서 비활성이고(모델이 이미 실행됨), pending_approval은 보류가 아니라 벗겨내기로 해석됩니다. 비용 상한과 HITL 보류는 inbound 표면에 두세요 — Cap cost와 Approvals 참조.

​
4. 스트리밍: 보류된 다음, 필터링됨

비스트림 응답에서는 전체 응답이 한 번에 파싱되고 필터링됩니다. 스트림에서는, 모델의 tool_calls가 많은 SSE 프레임에 걸쳐 인덱스별 델타로 도착합니다 — 그리고 델타가 일단 전달되면, 에이전트가 이미 그것을 가지고 있고 철회할 수 없습니다. 그래서 게이트웨이는 툴 호출 프레임을 보류합니다: 그것들은 스트림 중간에 결코 전달되지 않습니다. 스트림 끝에 firewall은 각 호출(이름 + 완전한 인자)을 조립하고, 평가하고, 살아남은 호출만 발행합니다.
콘텐츠 프레임은 여전히 정상적으로 스트리밍됩니다 — 텍스트 토큰은 도착할 때 클라이언트에 도달합니다. tool_call 프레임만 평가를 위해 보류되므로, 거부되거나 정화된 호출은 조립된 툴 호출이 전달되기 전에 필터링됩니다. 판정과 규칙 의미는 비스트림 표면과 동일합니다. 프레임 수준 세부사항은 스트리밍 내부와 프로바이더 스트리밍을 참조하세요.

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

콘솔 Test 탭은 샘플 툴 호출에 대해 정책을 실행하고 판정, 매치된 규칙, 이유를 반환합니다 — 아무것도 디스패치되지 않고, 아무것도 영속화되지 않습니다. 키를 연결하기 전에 glob와 인자 절이 의도한 호출에 매치하는지 확인하세요. 규칙 테스트 참조.
shadow mode를 켜면 모든 강제 판정 — response 표면 deny 포함 — 이 이유에 [shadow] would …가 접두된 audit로 강등됩니다. 단일 응답을 변경하기 전에 규칙이 실제 트래픽에 대해 무엇을 벗겨낼지 정확히 측정합니다.
모든 평가는 판정, 표면, 툴, 매치된 규칙과 함께 firewall 이벤트를 씁니다. 이벤트 로그를 표면 response로 필터링하여 규칙이 예상한 발행된 호출에 발동하는 것을 보세요. 분석 참조.

​
6. 정책 연결과 누가 구성할 수 있는가

정책은 키가 그것으로 해석되기 전까지 아무것도 하지 않습니다. 키에 firewall_policy_id를 설정하여 콘솔에서 연결하거나, 정책을 워크스페이스 기본값으로 만드세요. 해석은: 키의 연결된 정책(존재하고 활성화된 경우), 그렇지 않으면 워크스페이스 기본값 — 그리고 비활성화된 연결 정책은 워크스페이스 기본값으로 폴백합니다. 정책 관리 참조. 모든 구성은 세션하에 콘솔에서(/api/workspace/firewall/*) 실행됩니다:
액션역할
정책, 프리셋, discovered tools, Simulate 읽기Member
dry-run(Test), 이벤트 로그 및 실행 집계 읽기Developer+
규칙 및 정책 생성 / 편집 / 삭제Developer+

​
관련

인자 검증

response 표면 필터링을 정밀하게 만드는 인자 절.

응답 정화

호출을 벗겨내는 대신 그 인자에서 시크릿을 가립니다.

Firewall 스테이지

response가 inbound, mcp, egress와 어떻게 비교되는가.

툴 차단

inbound 대응: 모델에게 제공되기 전에 툴을 거부.

위험한 툴 호출

response 필터링이 다루는 위협.

Firewall 레퍼런스

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