Перейти к основному содержанию
Агент, который может дотянуться до сети, может быть превращён в канал данных. Внедрённые инструкции велят ему собрать секреты, строки или PII инструментами, которые он уже держит, и сделать POST на хост злоумышленника — или прозондировать внутренние сервисы (SSRF). Агент никогда «не решает» эксфильтровать; он исполняет то, что выглядит для него легитимной инструкцией. Этот рецепт настраивает три контроля, которые замыкают петлю от начала до конца, — egress allow-list, который ограничивает, куда могут идти исходящие вызовы, guardrail Secrets Blocker, который останавливает учётные данные до того, как они достигнут модели, и очиститель аргументов, который удаляет секреты из вызовов инструментов, которые модель всё же выдаёт. Всё это живёт в шлюзе, так что вы настраиваете это один раз в консоли с нулевыми изменениями в коде вашего агента. О полной анатомии атаки читайте Эксфильтрация данных по сети; эта страница — шаги сборки.
Всё здесь привязывается к вашему рабочему пространству и настраивается из консоли. Ваш агент продолжает вызывать https://api.orcarouter.ai/v1/... с тем же ключом sk-orca-... — меняется только политика в шлюзе. Действия по конфигурации требуют ролей, указанных на каждом шаге; вызовы ретрансляции используют ограниченный ключ. Firewall видит egress только для назначений, маршрутизированных через шлюз (путь MCP-диспетча или хук evaluate), — маршрутизируйте ваши сетевые вызовы инструментов через него, и они управляемы.

​
1. Три слоя, которые предотвращают эксфильтрацию данных ИИ

Каждый слой ловит атаку в разной точке жизненного цикла запроса. Сложите все три — они независимы и взаимодополняющи.

Учётные данные в промпте

Секрет, вставленный (или подтянутый) в запрос, ловится на стадии input guardrail’ом Secrets Blocker — до того, как его увидит любая модель.

Секреты в аргументах инструментов

Модель, выдающая вызов инструмента, несущий учётные данные, очищается правилом firewall sanitize, которое редактирует совпавший аргумент.

Исходящее назначение

Сам сетевой шаг ограничен egress allow-list — проходят только перечисленные хосты; всё остальное запрещается.
Этот рецепт использует обе плоскости: Guardrails для текста в запросе, Firewall для действий и сети. О том, где проходит граница, см. guardrails vs firewall.

​
2. Остановите учётные данные на промпте — guardrail Secrets Blocker

Первое, что нужно ограничить, — это сам учётный данные. Guardrail Secrets & API-Key Blocker работает на стадии input и сканирует запрос на паттерны учётных данных — access-ключи в стиле AWS, ключи OpenAI, JWT и подобные токены — до того, как запрос покинет шлюз. На совпадении запрос блокируется: учётные данные никогда не достигают модели и никогда не приземляются в вызов инструмента. В консоли откройте Guardrails → New guardrail (роль Developer; чтения и песочница Test открыты любому участнику), назовите его exfil-shield и примените пресет Secrets & API-Key Blocker из библиотеки шаблонов (категория secrets). Пресет засеивает три regex-block-правила стадии input, по одному на каждую форму учётных данных — AWS access-ключи, ключи в стиле OpenAI и токены GitHub: 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
Чтобы расширить покрытие, добавьте правило pii на встроенных сущностях — набор детектора покрывает email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt и bitcoin_address. Выберите mask (редактировать в типизированный тег вроде [EMAIL]) или block для каждой сущности через entity_actions. Маскирование на стадии input работает; оно переписывает запрос до того, как его увидит модель.
Заблокированный запрос возвращает HTTP 400 guardrail_blocked, не стоит никакой квоты (блок стадии input срабатывает до учёта) и помечается skip-retry. Докажите это во вкладке Test — вставьте образец AWS-ключа, выберите стадию input и подтвердите вердикт — прежде чем привязать ключ.

​
3. Очистите секреты из аргументов вызовов инструментов

Guardrail проверяет промпт; он не видит вызовы инструментов, которые выдаёт модель. Когда модель производит tool_call, чьи аргументы несут учётные данные, правило firewall sanitize его ловит. Sanitize редактирует совпавшие подстроки из аргументов вызова инструмента и пересылает очищенный вызов — инструмент запускается, но с удалённым секретом. В Firewall → Policies → New policy (роль Developer) назовите её exfil-firewall и добавьте правило sanitize на поверхности response — tool_calls, которые модель выдаёт в своём ответе: 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
Sanitize редактирует только аргументы вызовов инструментов — никогда контент, который инструмент возвращает. Это защита на исходящей форме вызова, а не на входящих результатах инструмента. На поверхности inbound (где ещё нет аргументов времени вызова) вердикт sanitize эскалирует до deny. См. полный язык сопоставления в Правилах firewall.

​
4. Ограничьте исходящие назначения — egress allow-list

Самая прочная защита — это сама сетевая граница: перечислите хосты, к которым вашим агентам легитимно разрешено дотягиваться, и запретите всё остальное. Egress-правило использует stage: egress и поле egress; вердикт задаёт полярность — allow пропускает перечисленные назначения, а deny-catch-all меньшего приоритета блокирует остальное. Добавьте эти правила в ту же политику exfil-firewall: 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": ["api.openai.com", "api.anthropic.com", "api.orcarouter.ai"]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Записи совпадают как CIDR, IP-литерал или регистронезависимое имя хоста. Чтобы остановить SSRF к внутренним сервисам без явного allow-list, напишите собственное egress-deny-правило, перечисляющее endpoint облачных метаданных (169.254.169.254) и приватные диапазоны RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Запрещённый вызов возвращает HTTP 400 firewall_blocked.
Ни один пресет не поставляет CIDR egress-правил — вы пишете записи allow и deny host/CIDR сами. Уровень автономии tight (уровень автономии) — соседний быстрый путь: он запрещает fetch-образные имена инструментов (http_fetch, web_search, fetch_url, request) целиком, убирая сетевую возможность до того, как назначение вообще вычислится. Используйте его, когда вашему агенту эти инструменты вообще не нужны.

​
5. Привяжите один ограниченный ключ

Политика применяется только на ключах, которые к ней разрешаются. Дайте агенту его собственный ключ, ограниченный минимумом, который ему нужен, — никогда не ваш ключ уровня аккаунта. В API Keys → New key (роль Developer):
Выберите exfil-shield из выпадающего списка Guardrail (устанавливает guardrail_id) и exfil-firewall из выпадающего списка Firewall policy (устанавливает firewall_policy_id). Обе привязки живут на ключе в шлюзе. Явная привязка guardrail никогда не откатывается молча — её отключение и есть off-переключатель. Отключённая firewall-политика, в противоположность, откатывается к default-политике рабочего пространства.
Установите credit_limit_usd на разумный потолок (0 = без лимита), чтобы скомпрометированный ключ не мог вычерпать квоту, и allow_ips на egress-IP вашего бэкенда, если агент вызывает с фиксированного сервера. Установите expired_time для временных ключей (-1 = никогда не истекает).
Ключ маскируется при отображении после создания — скопируйте его один раз. Ваш агент теперь прогоняет каждый запрос через exfil-shield, а каждый вызов инструмента через exfil-firewall без какого-либо кода, осознающего, что происходит применение.

​
6. Выкатывайте в shadow-режиме, затем наблюдайте

Если вы пока не знаете каждый хост, к которому ваш агент легитимно дотягивается, не применяйте вслепую — сначала наблюдайте. См. режимы применения для полного пути observe → shadow → enforce.
1

Запустите egress-правила в shadow

Установите shadow_mode: true на exfil-firewall. Каждый применяющий вердикт понижается до audit и логируется как [shadow] would deny с назначением. Пока shadow-режим включён, трафик не блокируется.
2

Наблюдайте за лентами

Firewall → Events / Runs (Developer+) показывает каждый вызов инструмента и egress-назначение, на которое попал ваш агент, и что было бы запрещено. Guardrails → Matches (любой Member) показывает каждый секрет, который поймал input-guardrail. Настраивайте egress-список allow, пока запрещались бы только достижимые злоумышленником хосты.
3

Применяйте

Выключите shadow_mode. Самый следующий запрос управляется — учётные данные заблокированы на промпте, секреты удалены из аргументов инструментов, исходящие вызовы ограничены вашим allow-list. Без изменений приложения.
Лента Matches записывает совпавшую подстроку только когда для guardrail включено Log raw content (выключено по умолчанию — консервативная по приватности позиция). Отметьте ложное срабатывание (Admin), чтобы настроить политику. Каждое изменение guardrail пишет строку истории версий, которую можно сравнивать diff и откатывать; изменения политики firewall записываются в журнал аудита.

​
7. Покрытие с одного взгляда

Шаг эксфильтрацииСлой, который его останавливает
Учётные данные входят в запросGuardrail Secrets Blocker (input)
Модель выдаёт вызов инструмента, несущий секретПравило firewall sanitize (поверхность response)
Инструмент дозванивается до хоста злоумышленникаEgress-правило allow / deny
Агент дотягивается до облачных метаданных или RFC-1918Egress-deny-правило, перечисляющее эти CIDR
Fetch-образный инструмент предложен моделиУровень автономии tight (deny имён инструментов)

​
8. Куда дальше

Справочник правил Firewall

Полный язык сопоставления — egress-списки, CIDR, очистители и все вердикты.

Угроза эксфильтрации данных

Анатомия атаки, от которой защищает этот рецепт, от начала до конца.

Защитите MCP-агента

Управляйте каждым tools/call, который агент диспетчеризует через MCP-сервер.

PII-безопасное логирование

Держите чувствительные данные вне ваших request-логов и ленты Matches.