Перейти к основному содержанию
Когда агент вызывает инструмент, аргументы, которые он передаёт, так же рискованны, как промпт, который их произвёл — ключ sk-…, оброненный в поле command, SSN клиента, вставленный в body, внутренний токен в заголовке запроса. Вердикт sanitize firewall ловит этот материал в аргументах вызова инструмента, заменяет его типизированным токеном редактирования и пересылает очищенный вызов — так что действие всё равно выполняется, но секрет никогда не покидает шлюз.
«Очистка вывода инструмента» означает аргументы вызова, а не результат инструмента. Люди ищут sanitize tool output, ожидая, что firewall вычистит то, что инструмент возвращает. Вердикт sanitize не трогает результаты инструмента — он редактирует аргументы, которые ваш агент отправляет в вызов инструмента. Если вам нужно проверить текст, который возвращает инструмент или модель, это работа стадии вывода Guardrails, а не правила sanitize firewall.
Это один вердикт в языке сопоставления firewall. О полном наборе см. Вердикты и справочник правил; эта страница — сфокусированное руководство по созданию sanitize и рассуждению о нём.

​
1. Что делает sanitize — и чего никогда не трогает

Правило с verdict: sanitize запускает движок редактирования над аргументами вызова инструмента до того, как вызов диспетчеризуется. Каждое совпадение заменяется каноническим токеном, и вызов продолжается с очищенными аргументами — инструмент всё равно выполняется, просто без сырого секрета внутри.

Редактирует

JSON-аргументы выданного моделью tool_call или MCP tools/call — command, body, headers, любое строковое поле, куда попал секрет или PII.

Никогда не редактирует

Содержимое, которое возвращает инструмент, промпт, текст ответа модели. Sanitize — редактор только аргументов. Проверка текста — забота Guardrail.
Редактор заменяет каждое совпадение типизированным токеном: совпадение с пресетом становится [redacted:<preset>] (например, [redacted:openai_key]), а совпадение с кастомным шаблоном становится [redacted:custom]. Форма аргумента сохраняется — меняется только чувствительная подстрока — так что инструмент, ожидающий валидный JSON, всё равно получает валидный JSON.

​
2. Встроенные пресеты детекторов

Правило sanitize называет один или несколько пресетов (хорошо известные формы секрета/PII) и/или кастомные regex-шаблоны. Встроенные пресеты:
ПресетЛовит
aws_access_keyAWS access key id (AKIA… / ASIA… + 16 символов)
aws_secret_key40-символьный AWS-секрет (с учётом границ)
openai_keysk- + ≥32 символов
anthropic_keysk-ant- + ≥40 символов
bearer_tokenBearer + токен ≥16 символов (ключевое слово сохраняется)
emailАдрес электронной почты
ssn_usUS SSN в форме 3-2-4
credit_cardПоследовательность из 13–19 цифр, проходящая проверку Луна
Правило sanitize должно объявить хотя бы один пресет или кастомный шаблон — пустой sanitizer отклоняется, когда вы сохраняете правило. Совпадение credit_card дополнительно проверяется по Луну, так что число той же длины, не являющееся валидной картой, оставляется нетронутым, а не пере-редактируется.

​
3. Один конкретный пример

Создайте это в консольном редакторе правил. Пример редактирует ключ OpenAI и любой email из аргументов любого вызова инструмента http.*, который выдаёт ваш агент, затем пересылает очищенный вызов: 
{
  "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" } }
шлюз пересылает его с телом, переписанным в key=[redacted:openai_key] user=[redacted:email] — запрос всё равно выполняется, секрет и адрес никогда не покидают шлюз.
Привяжите правило к стадии response (выданные моделью tool_calls) или оставьте стадию пустой, чтобы также покрыть поверхность mcp. Это поверхности, которые несут аргументы времени вызова, а это и есть то, что редактирует sanitize.

​
4. На поверхности inbound sanitize эскалирует до deny

Поверхность inbound вычисляет инструменты, которые агент рекламирует в запросе — определения инструментов, которые несут пока никаких аргументов времени вызова. Редактировать там нечего, так что вердикт sanitize на поверхности inbound эскалирует до deny (fail-closed): запрос блокируется с firewall_blocked, а не пересылается неотредактированным.
Не создавайте правило sanitize, ожидая, что оно очистит inbound-рекламу инструмента — оно заблокирует её. Если вы хотите, чтобы определение инструмента исчезло из запроса, используйте явный deny. Резервируйте sanitize для поверхностей response и mcp, где существуют реальные аргументы.

​
5. Sanitize против других способов обработать секрет

Три слоя могут подействовать на секрет, который агент собирается утечь — выбирайте по что и где:
Удаляет секрет из аргументов вызова инструмента и всё равно выполняет вызов. Используйте, когда действие законно, но агент поместил что-то чувствительное в поле. Только на уровне аргументов.
Останавливает вызов целиком. Используйте, когда опасно само действие, а не только аргумент. Это также то, чем sanitize становится на поверхности inbound. См. блокировку инструментов.
Guardrails Secrets Blocker и PII проверяют текст запроса или ответа (включая, на стадии вывода, сгенерированное моделью содержимое). Это слой для «того, что возвращает инструмент или модель» — того, что sanitize не делает.
Тестируйте до применения. Sanitize переписывает аргументы живого вызова на поверхностях response и mcp. Сначала создавайте свои правила sanitize под shadow-режимом и наблюдайте за лентой событий, чтобы подтвердить, что они совпадают с тем, что вы ожидаете, до того как какой-либо аргумент реально переписан.

​
6. Где sanitize появляется в вашем следе

Как и каждый вердикт, вычисление sanitize записывается как событие firewall — фильтруемое по вердикту, поверхности, инструменту и прогону в журнале событий и свёрнутое в аналитике. В shadow-режиме вердикт sanitize (как каждый применяющий вердикт) понижается до audit, а причина получает префикс [shadow] would …, так что вы можете измерить влияние до того, как какой-либо аргумент реально переписан.

​
Куда двигаться дальше

Все вердикты

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

Проверять аргументы

Сопоставить вызов по тому, что в его аргументах — грамматика клауз JSONPath.

Блокировать инструменты

Когда проблема в самом действии, отклоните весь вызов.

Firewall + Guardrails

Проверить текст, который возвращает инструмент или модель — слой, который sanitize не покрывает.
Об угрозах, которые sanitize помогает сдержать, см. эксфильтрацию данных и опасные вызовы инструментов. О полной грамматике правил за вердиктом см. справочник правил firewall.