Перейти к основному содержанию
Вы подключили MCP-сервер, и теперь хотите, чтобы шлюз вычистил утёкший секрет из вызова инструмента, прежде чем он достигнет реального сервера — и чтобы то, что этот инструмент возвращает, не протащило учётные данные (или полезную нагрузку инъекции) обратно в модель. Это две разные задачи, обрабатываемые двумя разными контролями, и честная версия важна: если вы предполагаете, что одна ручка покрывает обе, вы поставите с пробелом. Эта страница — сфокусированное руководство по очистке mcp-вывода на OrcaRouter — что вердикт firewall sanitize на самом деле редактирует, что он не делает, и какой контроль управляет контентом, который возвращает инструмент.
Вердикт sanitize редактирует аргументы вызова инструмента, никогда не результат, который возвращает инструмент. Он переписывает то, что ваш агент отправляет в инструмент. Чтобы управлять тем, что инструмент отправляет обратно, вы используете guardrail выходной стадии на ответе модели — см. §3.

​
1. Что означает «sanitize» на поверхности mcp

Когда агент вызывает инструмент через MCP-шлюз, каждый tools/call оценивается на поверхности mcp перед диспетчем. Совпавшее правило может нести один из авторируемых вердиктов firewall — allow, audit, deny, sanitize, pending_approval или cap_cost. Вердикт sanitize — это редактирующий:
  • Он прогоняет набор детекторов формы секретов по аргументам вызова (JSON, который модель передала в инструмент).
  • Каждое совпадение заменяется каноническим токеном вроде [redacted:openai_key], и переписанные аргументы — это то, что пересылается на сервер.
  • Инструмент всё равно запускается — sanitize — это неблокирующий, пропускающий вердикт. Агент не падает; он просто никогда не передаёт сырой секрет инструменту.
Встроенные детекторы покрывают хорошо известные формы секретов (ключи доступа AWS, API-ключи в стиле sk-, токены Bearer, US SSN, номера карт, валидные по Луну, email), и правило может добавить пользовательские регулярные выражения, чьи совпадения отображаются как [redacted:custom].
На поверхности inbound — рекламируемый tools[], который объявляет запрос, до того как вызван любой инструмент — нет аргументов времени вызова для редактирования, так что вердикт sanitize там закрывается (fail closed) и эскалируется до deny. Sanitize осмыслен только там, где есть живая полезная нагрузка аргументов для переписывания: поверхности mcp и response.

​
2. Одно конкретное правило

Допустим, вы хотите, чтобы любой вызов инструмента, чьи аргументы содержат ключ в стиле OpenAI, пересылался с вычищенным ключом, а не блокировался. Напишите правило на поверхности mcp с вердиктом sanitize, настроенным на обнаружение этой формы секрета. Сделайте это из консоли (Firewall → политика → правила); запись требует Developer+. Правило, концептуально:
ПолеЗначение
Поверхностьmcp
tool_name_glob* (или ограничить одним сервером, например github.*)
Вердиктsanitize
Пресеты sanitizeдетекторы секретов для включения
Во время вызова полезная нагрузка аргументов вроде: 
{ "note": "use key sk-AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH for the upstream" }
пересылается на сервер как: 
{ "note": "use key [redacted:openai_key] for the upstream" }
Вызов успешен; секрет никогда не достигает сервера. Событие firewall записывает вердикт sanitize, поверхность и совпавшее правило.
Обращайтесь к sanitize, когда инструменту легитимно нужна большая часть аргумента, но в свободном тексте иногда едет секрет. Когда весь вызов опасен, используйте deny (или pending_approval) вместо этого — см. Список разрешённых MCP-инструментов.

​
3. Результаты инструментов недоверенные — управляйте ими на ответе модели

Вот часть, которую большинство настроек «очистки вывода» делают неправильно. Вердикт sanitize касается только аргументов. Результат инструмента — текст или JSON, который возвращает MCP-сервер — никогда не переписывается вердиктом firewall. OrcaRouter относится к контенту результата инструмента как к недоверенному входу для модели. Скомпрометированный или отравленный MCP-сервер может вернуть секрет, запись PII или полезную нагрузку prompt-injection, наряженную под данные. Контроль для этого контента — это guardrail на стадии output — ответ модели, оцениваемый после того, как модель включила результат инструмента.
Прикрепите guardrail с пресетом Secrets & API-Key Blocker (категория secrets). Он блокирует учётные данные в стиле AWS / OpenAI / GitHub; сочетайте его с Private Keys & Cloud Tokens для PEM-ключей, токенов Slack/Stripe, ключей Google и JWT. Блок выходной стадии возвращает guardrail_blocked (HTTP 400) и возвращает (refunds) квоту запроса.
Пресет PII Shield маскирует типизированные сущности — [EMAIL], [SSN], [CREDIT_CARD], … — отображая совпавшие значения как теги. Маскирование входной стадии живо на каждом запросе (потоковом или нет): оно маскирует запрос до того, как модель его увидит. Маскирование выходной стадии переписывает ответ модели только на непотоковых ответах; внутриполосное переписывание потокового ответа в дорожной карте, так что правило маскирования пока не редактирует потоковый ответ.
Отравленный результат может нести текст в стиле «игнорируй предыдущие инструкции». Безопасный пресет Prompt-Injection Basics (ключевое слово/регулярное выражение) плюс правило llm_judge, оценивающее намерение инъекции, — это контроли здесь. См. Отравление MCP-инструментов и Prompt injection.
Применение на выходе и потоковая передача. Блок выходной стадии применяется как на потоковых, так и на непотоковых ответах — на потоке блок обрывает поток при совпадении и выдаёт обобщённое уведомление о блокировке. Маскирование выходной стадии применяется только к непотоковым ответам; внутриполосное переписывание потокового ответа в дорожной карте, так что правило маскирования пока не редактирует потоковый ответ.

​
4. Где живёт каждый контроль

Компактная карта двух поверхностей, чтобы вы подключили правильную ручку к правильному риску:
Вы хотите управлять…КонтрольГде
Секретами в аргументах вызова инструментаВердикт firewall sanitize (поверхность mcp)Правила Firewall
Секретами / PII / инъекцией в результате инструментаGuardrail на стадии outputGuardrails
Не пытайтесь заставить sanitize покрывать результаты инструмента — он не может их видеть. И не предполагайте, что guardrail входной стадии перехватит то, что инструмент возвращает посреди разговора; контент результата инструмента управляется на ответе модели, который является стадией output.

​
5. Прикрепление и наблюдение

Оба контроля ограничены рабочим пространством, именованы и упорядочены, и оба прикрепляются одними и теми же двумя способами:
  • На ключ — установите firewall_policy_id (для правила sanitize) и guardrail_id (для выходной политики) на ключе, который использует агент.
  • По умолчанию для рабочего пространства — отметьте политику / guardrail как значение по умолчанию для рабочего пространства, чтобы каждый ключ его наследовал.
Настройте всё это из консоли вашей сессией/access-токеном (маршруты управления используют UserAuth, не relay-ключ). Записи firewall требуют Developer+; записи guardrail требуют Developer+. Как только это активно, совпадения sanitize показываются как события firewall (вердикт, поверхность, совпавшее правило), а совпадения guardrail показываются в ленте совпадений guardrail. У них разные шлюзы чтения: лента событий firewall требует Developer+, тогда как лента совпадений guardrail читаема любым участником рабочего пространства. По умолчанию совпадение записывает свой тип, действие и стадию, но не сырой совпавший контент; включайте Log raw content только когда вам нужна подстрока для триажа.

​
6. Куда идти дальше

Список разрешённых MCP-инструментов

Default-deny для сервера и разрешите только инструменты, которые вы проверили.

Правила Firewall

Полный DSL правил — вердикты, глобы, args-match, конфигурация sanitize.

Guardrails

Контентные политики, пресеты, PII-сущности и применение выходной стадии.

Отравление MCP-инструментов

Угроза, которая в первую очередь делает результаты инструментов недоверенными.
Впервые видите разделение между этими двумя слоями? Прочитайте Guardrails vs. firewall, затем Эксфильтрацию данных для пути утечки, который sanitize и выходные guardrails закрывают вместе.