메인 콘텐츠로 건너뛰기
에이전트가 툴을 호출할 때, 그것이 전달하는 인자는 그것을 생성한 프롬프트만큼이나 위험합니다 — command 필드에 떨어진 sk-… 키, body에 붙여넣은 고객 SSN, 요청 헤더 안의 내부 토큰. firewall sanitize 판정은 그 자료를 툴 호출 인자에서 잡아, 타입이 지정된 리댁션 토큰으로 교체하고, 정화된 호출을 전달합니다 — 그래서 액션은 여전히 실행되지만, 시크릿은 결코 게이트웨이를 떠나지 않습니다.
“툴 출력 정화”는 툴 결과가 아니라 호출 인자를 의미합니다. 사람들은 firewall이 툴이 반환하는 것을 지울 것이라 기대하고 sanitize tool output을 검색합니다. sanitize 판정은 툴 결과를 건드리지 않습니다 — 에이전트가 툴 호출에 보내는 인자를 가립니다. 툴이나 모델이 반환하는 텍스트를 스크리닝해야 한다면, 그것은 firewall sanitize 규칙이 아니라 Guardrails 출력 스테이지의 일입니다.
이것은 firewall의 매칭 언어에서 하나의 판정입니다. 전체 집합은 Verdicts와 규칙 레퍼런스를 참조하세요; 이 페이지는 sanitize를 작성하고 추론하는 데 집중한 가이드입니다.

​
1. sanitize가 하는 일 — 그리고 결코 건드리지 않는 것

verdict: sanitize 규칙은 호출이 디스패치되기 전에 툴 호출 인자에 대해 리댁션 엔진을 실행합니다. 각 매치는 정전(canonical) 토큰으로 교체되고 호출은 정화된 인자로 진행합니다 — 툴은 여전히 실행되며, 그저 그 안에 원시 시크릿이 없을 뿐입니다.

가림

모델이 발행한 tool_call이나 MCP tools/call의 JSON 인자 — command, body, headers, 시크릿이나 PII가 떨어진 모든 문자열 필드.

결코 가리지 않음

툴이 반환하는 콘텐츠, 프롬프트, 모델의 응답 텍스트. Sanitize는 인자 전용 리댁터입니다. 텍스트 스크리닝은 Guardrail 관심사입니다.
리댁터는 각 매치를 타입이 지정된 토큰으로 교체합니다: 프리셋 매치는 [redacted:<preset>]이 되고(예: [redacted:openai_key]), 커스텀 패턴 매치는 [redacted:custom]이 됩니다. 인자의 형태는 보존됩니다 — 민감한 부분 문자열만 변경됩니다 — 그래서 유효한 JSON을 기대하는 툴은 여전히 유효한 JSON을 받습니다.

​
2. 내장 검출기 프리셋

sanitize 규칙은 하나 이상의 프리셋(잘 알려진 시크릿/PII 형태) 및/또는 커스텀 regex 패턴을 명명합니다. 내장 프리셋:
Preset잡는 것
aws_access_keyAWS 액세스 키 id(AKIA… / ASIA… + 16자)
aws_secret_key40자 AWS 시크릿(경계 인식)
openai_keysk- + ≥32자
anthropic_keysk-ant- + ≥40자
bearer_tokenBearer + ≥16자 토큰(키워드 유지)
email이메일 주소
ssn_us3-2-4 형태의 US SSN
credit_cardLuhn 검사를 통과하는 13–19자리 연속
sanitize 규칙은 최소 하나의 프리셋이나 커스텀 패턴을 선언해야 합니다 — 빈 새니타이저는 규칙을 저장할 때 거부됩니다. credit_card 매치는 추가로 Luhn 검사되므로, 유효한 카드가 아닌 같은 길이의 숫자는 과도하게 가려지기 보다 손대지 않은 채로 남습니다.

​
3. 하나의 구체적인 예

콘솔 규칙 편집기에서 이것을 작성하세요. 예는 에이전트가 발행하는 모든 http.* 툴 호출의 인자에서 OpenAI 키와 모든 이메일을 가린 다음, 정화된 호출을 전달합니다: 
{
  "label": "strip secrets from http tool args",
  "stage": "response",
  "tool_name_glob": "http.*",
  "verdict": "sanitize",
  "sanitize_json": "{\"presets\":[\"openai_key\",\"email\"],\"custom\":[]}"
}
모델이 다음과 같은 호출을 발행하면: 
{ "name": "http.post", "arguments": { "url": "…", "body": "key=sk-AAAA…BBBB user=jo@acme.com" } }
게이트웨이는 body가 key=[redacted:openai_key] user=[redacted:email]로 다시 쓰여진 채로 그것을 전달합니다 — 요청은 여전히 실행되고, 시크릿과 주소는 결코 게이트웨이를 떠나지 않습니다.
규칙을 response 스테이지(모델이 발행한 tool_calls)에 고정하거나 스테이지를 비워두어 mcp 표면도 커버하세요. 그것들이 sanitize가 가리는, 호출 시점 인자를 담는 표면입니다.

​
4. inbound 표면에서, sanitize는 deny로 격상됩니다

inbound 표면은 에이전트가 요청에서 광고하는 툴 — 호출 시점 인자가 아직 없는 툴 정의 — 을 평가합니다. 거기에는 가릴 것이 없으므로, inbound 표면의 sanitize 판정은 deny로 격상됩니다(페일 클로즈): 요청은 가리지 않고 전달되기보다 firewall_blocked로 차단됩니다.
inbound 툴 광고를 정화할 것이라 기대하고 sanitize 규칙을 작성하지 마세요 — 그것은 그것을 차단합니다. 툴 정의가 요청에서 사라지기를 원하면, 명시적 deny를 사용하세요. sanitize는 실제 인자가 존재하는 response와 mcp 표면을 위해 남겨두세요.

​
5. Sanitize 대 시크릿을 다루는 다른 방법

세 계층이 에이전트가 누출하려는 시크릿에 대해 행동할 수 있습니다 — 무엇과 어디서로 고르세요:
툴 호출의 인자에서 시크릿을 벗겨내고 여전히 호출을 실행합니다. 액션은 정당하지만 에이전트가 필드에 민감한 것을 넣었을 때 사용하세요. 인자 계층 전용.
호출을 전적으로 멈춥니다. 인자만이 아니라 액션 자체가 위험할 때 사용하세요. 이는 또한 inbound 표면에서 sanitize가 되는 것입니다. 툴 차단 참조.
Secrets Blocker와 PII guardrails는 요청이나 응답의 텍스트(출력 스테이지에서는 모델 생성 콘텐츠 포함)를 스크리닝합니다. 그것이 “툴이나 모델이 반환하는 것”을 위한 계층입니다 — sanitize가 하지 않는 것.
강제하기 전에 테스트하세요. Sanitize는 response와 mcp 표면에서 라이브 호출의 인자를 다시 씁니다. sanitize 규칙을 먼저 shadow mode하에서 작성하고 이벤트 피드를 보아 어떤 인자가 실제로 다시 쓰이기 전에 그것들이 예상한 것에 매치하는지 확인하세요.

​
6. sanitize가 흔적에 어디에 나타나는가

모든 판정처럼, sanitize 평가는 firewall 이벤트로 기록됩니다 — 이벤트 로그에서 판정, 표면, 툴, 실행으로 필터링 가능하고 분석에서 롤업됩니다. shadow mode에서 sanitize 판정은(모든 강제 판정처럼) audit로 강등되고 이유에 [shadow] would …가 접두되므로, 어떤 인자가 실제로 다시 쓰이기 전에 영향을 측정할 수 있습니다.

​
다음으로 갈 곳

모든 verdict

allow, audit, deny, sanitize, pending_approval, cap_cost.

인자 검증

호출을 그 인자 안에 있는 것으로 매치 — JSONPath 절 문법.

툴 차단

액션 자체가 문제일 때, 전체 호출을 거부합니다.

Firewall + Guardrails

툴이나 모델이 반환하는 텍스트를 스크리닝 — sanitize가 커버하지 않는 계층.
sanitize가 봉쇄를 돕는 위협은 데이터 유출과 위험한 툴 호출을 참조하세요. 판정 뒤의 전체 규칙 문법은 firewall 규칙 레퍼런스를 참조하세요.