Перейти к основному содержанию
Агент, имеющий доступ к сети, может быть превращён в канал утечки данных. Злоумышленник помещает инструкции в документ, который читает агент — веб-страницу, извлечённый чанк, результат инструмента — и эти инструкции направляют агента POST’ить чувствительные данные на хост, контролируемый злоумышленником, или зондировать внутренние сервисы (SSRF). Агент никогда не «решает» эксфильтрировать; он выполняет то, что выглядит для него как законная инструкция. На этой странице рассказывается, как Agent Firewall и Guardrails в OrcaRouter позволяют защититься от эксфильтрации данных ИИ — без изменений в коде агента.
Firewall видит egress только для адресов назначения, маршрутизируемых через шлюз через путь диспетча MCP или хук evaluate. Инструмент, который ваш агент выполняет целиком внутри собственного процесса, находится вне поля его зрения. Маршрутизируйте сетевые вызовы инструментов агента через шлюз — и они будут управляться.

​
1. Как работает атака

Канонический путь через агента проходит в три шага:
  1. Инъекция — агент читает недоверенный контент, содержащий встроенные инструкции (веб-страница, полученный документ, заметка в CRM).
  2. Сбор — внедрённые инструкции говорят агенту собрать чувствительный материал — API-ключи, строки базы данных, PII пользователей — используя уже имеющиеся инструменты.
  3. Эксфильтрация — агенту говорят отправить этот материал через fetch-образный инструмент: http_fetch, web_search, fetch_url или request. Адрес назначения контролируется злоумышленником.
SSRF имеет ту же форму, направленную внутрь: вместо внешнего хоста агент направляется к 169.254.169.254 (облачные метаданные), внутреннему порту Redis или другому приватному сервису. См. Prompt injection для шага инъекции; эта страница фокусируется на сетевом шаге.

​
2. Allow-list egress — блокировка исходящих адресов назначения

Наиболее долговечная защита — allow-list egress: перечислите хосты, к которым ваши агенты законно разрешены обращаться, и запретите всё остальное. Правило egress использует stage: egress и поле egress. Вердикт контролирует полярность — allow пропускает перечисленные адреса назначения; deny с меньшим приоритетом блокирует всё остальное: 
[
  {
    "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 или имя хоста без учёта регистра. Имена хостов best-effort разрешаются и повторно проверяются против записей IP/CIDR, так что адрес назначения вроде 169.254.169.254, возвращённый DNS, всё равно перехватывается записью deny CIDR 10.0.0.0/8. Заблокированный вызов возвращает HTTP 400 с кодом ошибки firewall_blocked. Чтобы запрещать известно-плохие диапазоны без явного allow-листа, напишите целевое правило deny egress, перечисляющее эндпоинт облачных метаданных (169.254.169.254) и RFC-1918 приватные диапазоны (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Накладывайте allow-list поверх с меньшим номером приоритета, чтобы правила deny оценивались первыми.

​
3. Блокировка fetch-образных инструментов на уровне имени

Ещё до оценки egress-адреса назначения вы можете полностью убрать возможность. Уровень автономии tight запрещает http_fetch, web_search, fetch_url и request по glob имени инструмента как backstop SSRF и эксфильтрации. Если вашему агенту не нужен ни один из этих инструментов, tight убирает поверхность атаки за один шаг: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
Чтобы запретить fetch-инструменты без принятия полной позиции tight, напишите правило deny на поверхности inbound. inbound блокирует инструмент до того, как модель сможет его выбрать — агент никогда не получает возможность в своём списке инструментов: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
Повторите для каждого fetch-образного имени инструмента, которое использует ваш агентный стек.

​
4. Guardrail Secrets Blocker — остановка учётных данных на уровне промпта

Guardrail Secrets Blocker работает на входной стадии, сканируя промпт на ключи доступа в стиле AWS, ключи OpenAI, ключи Anthropic, GitHub-токены и аналогичные паттерны учётных данных до выхода запроса из шлюза. Если секрет обнаружен, запрос блокируется — учётные данные никогда не достигают модели и никогда не появляются в вызове инструмента. Включите его из панели Guardrails или как часть уровня автономии tight. Он независим от правил egress firewall.
УгрозаСлой, который её останавливает
Промпт несёт API-ключSecrets Blocker (входной guardrail)
Агент вызывает fetch-инструмент в направлении хоста злоумышленникаПравило allow/deny egress
Fetch-образный инструмент рекламируется моделиПравило deny inbound или автономия tight
Агент достигает облачных метаданных или RFC-1918Правило deny egress, перечисляющее эти CIDR

​
5. Выкатывание с shadow mode

Если вы не уверены, к каким хостам ваш агент законно обращается сегодня, начните в shadow mode перед применением:
  1. Создайте правила egress с вашим предполагаемым allow-листом и установите shadow_mode: true на политике.
  2. Наблюдайте ленту Events — вызовы, которые были бы заблокированы, появляются как [shadow] would deny с адресом назначения.
  3. Корректируйте список allow до тех пор, пока только достижимые злоумышленником адреса назначения были бы запрещены, затем отключите shadow mode для начала применения.
Пока shadow mode включён, трафик не блокируется.

​
6. Дальнейшие шаги

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

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

Обзор Agent Firewall

Политики, поверхности, уровни автономии и наблюдаемость.

Prompt injection

Шаг инъекции, направляющий агентов к эксфильтрации.

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

Вредоносные инструменты MCP, регистрирующие fetch-образные возможности.