Перейти к основному содержанию
Единственный вызов инструмента может выглядеть совершенно невинно. Прочитать одну запись CRM: разрешено. Вызвать инструмент экспорта: разрешено. Попасть на внешний хост: разрешено. Форма прогона — пятьдесят чтений, затем экспорт, затем egress на хост, который вы никогда не видели, в 3 часа ночи в воскресенье — это и есть атака. Per-call вердикты судят каждый вызов в изоляции и никогда её не видят. Эта страница покрывает два механизма firewall, которые наблюдают за прогоном во времени вместо одного вызова за раз: правила последовательностей (упорядоченная цепочка, которую вы создаёте) и поведенческое детектирование аномалий (отклонение от обученного нормального для вашего рабочего пространства). Вместе они — то, чем вы обнаруживаете цепочку атак агента, которую не может поймать ни одно правило allow/deny.
Всё здесь настраивается в консоли (Security → Firewall), чьи управляющие маршруты используют вашу сессию / access-токен — не ретрансляционный ключ sk-orca-…. Вызовы вашего агента /v1/* не меняются.

​
1. Почему per-call правила пропускают цепочку

Глобы инструментов и клаузы аргументов firewall по дизайну без состояния и детерминированы — они решают один вызов, быстро, на горячем пути. Это ровно то, что вам нужно для «заблокировать shell.exec rm -rf». Это ровно неправильно для медленной эксфильтрации, где каждый отдельный вызов легален. Два взаимодополняющих инструмента заполняют пробел:

Правила последовательностей

Правило, которое вы создаёте и которое совпадает с упорядоченной цепочкой вызовов в окне времени — «массовое чтение → экспорт → egress». Вы называете паттерн.

Детектирование аномалий

Firewall обучается нормальной форме использования инструментов каждого рабочего пространства и флагирует отклонения — циклы повторов, невиданные ранее пути инструментов и всплески объёма/стоимости. Правило создавать не нужно.

​
2. Правила последовательностей: назовите цепочку атак

Правило sequence живёт внутри политики firewall как любое другое правило, но вместо единственного tool_name_glob оно несёт упорядоченный список шагов. Каждый шаг — это глоб инструмента с опциональным min_count и опциональным egress: true; шаги должны происходить по порядку (чередование с несвязанными вызовами — нормально), и вся цепочка должна завершиться в пределах window_seconds. 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
Это срабатывает, когда агент читает 50+ записей crm.*, затем вызывает любой инструмент *.export, затем делает любой egress-вызов — всё внутри десяти минут. Каждый вызов сам по себе прошёл бы; сигнал — это паттерн.
Последовательность вычисляется на вызове, который её завершает. Inline цикл правил пропускает chain-правила (один вызов не может удовлетворить многошаговую цепочку); совпадение выполняется, когда вызов мог бы быть финальным шагом цепочки, в этот момент firewall подтягивает недавние события этого принципала и тестирует цепочку. verdict, который вы задали на правиле, — это то, что затем происходит с завершающим вызовом: audit записывает его и пропускает, pending_approval удерживает его для человеческого разбора, а deny блокирует его. Так что цепочка может остановить свой финальный вызов в реальном времени — выберите вердикт под задачу. Используйте audit, когда хотите только детектировать и оповещать; используйте pending_approval или deny (или сочетайте с per-call deny / egress-правилом), когда вам нужна жёсткая остановка.
Полный синтаксис поля sequence — window_seconds: 0 для отсутствия временной границы, дефолты min_count, семантика упорядочивания шагов — в схеме правил. Создавайте правила последовательностей в консольном редакторе правил; сохранение — действие Developer+.

​
3. Детектирование аномалий: отклонение от обученного нормального

Где правила последовательностей спрашивают «случился ли этот конкретный паттерн», детектирование аномалий спрашивает «есть ли что-нибудь в этом прогоне ненормальное для этого рабочего пространства». Ему не нужно правило — firewall строит базис из вашего собственного трафика и оценивает живую активность против него. Всплывают четыре вида:
Объём вызовов на (инструмент, ключ), оценённый против обученного базиса для этого часа недели. Строка всплывает, когда счётчик преодолевает абсолютный пол и идёт высоко относительно базиса, или когда его z-score пересекает статистический порог. Так «100 вызовов db.query в 3 часа ночи в воскресенье» выделяется, даже если всплеск того же размера во вторник в 14:00 — нет.
Та же идея, применённая к тратам: инструмент, сжигающий кратное своему обученному базису стоимости для этого часа недели. Раннее предупреждение denial-of-wallet — сочетайте его с правилом cap_cost, чтобы применить жёсткий потолок.
Группа (conversation, tool, arguments), которая повторяется много раз в тесном окне — агент, застрявший на вызове того же сбойного инструмента с теми же аргументами снова и снова, а не медленный законный опрос.
Переход tool_a → tool_b, который это рабочее пространство никогда раньше не делало. В первый раз, когда агент идёт от read_file прямо к http_fetch, это ребро загорается, даже если оба инструмента по отдельности разрешены.

​
Базис по часу недели

Базис — это 14-дневное скользящее среднее, сгруппированное по часу недели (weekday × 24 + hour), так что вторник-14:00 сравнивается именно с историей прошлых вторников-14:00 — а не с плоским средним за всё время, которое размыло бы ваш реальный дневной и недельный ритм. Совершенно новое рабочее пространство без обученной нормы всё равно ловит очевидный поток через абсолютный пол, так что вы защищены с первого дня.
Лента сообщает имена инструментов, отредактированные id ключей, счётчики и z-score — никогда сырой материал ключа. Каждая аномалия несёт предлагаемое исправление (rate_limit, review или block_tool), так что следующий шаг — один клик, а не догадка.

​
4. Один конкретный разбор

Предположим, скомпрометированный промпт загоняет одного из ваших агентов в тесный цикл сбоя, затем зондирует путь экспорта, которого он никогда не касался. Вот что вы видите — без правила, созданного заранее:
1

Агент ведёт себя плохо

Внедрённые инструкции толкают агента повторять сбойный db.query с идентичными аргументами, затем вызвать report.export, за которым следует исходящее извлечение — путь, который это рабочее пространство никогда не выполняло.
2

Откройте ленту аномалий

В Security → Firewall → Anomalies прогон всплывает с retry_loop на db.query и novel_path на ребре report.export → http_fetch. Чтение ленты — действие Member — любой в команде может провести триаж.
3

Подтвердите в трассировке событий

Перейдите в журнал событий и аналитику прогонов, чтобы увидеть точную последовательность вызовов, коррелированную с прогоном и диалогом агента. Лента аномалий читаема для Member, но журнал событий и трассировка прогона несут происхождение вызовов инструментов и требуют Developer+.
4

Превратите находку в правило

Теперь, когда вы увидели цепочку, закодируйте её: deny на опасный экспорт, egress allow-list на извлечение или правило последовательности, которое аудирует весь паттерн в следующий раз. Детектирование аномалий находит неизвестное; правило фиксирует известное.
Если лента шумна, пока вы настраиваете — скажем, законная пакетная задача, которая искренне даёт всплеск каждое воскресенье — отложите (snooze) ленту аномалий на срок до 7 дней, пока расследуете. Откладывание — действие Developer+; окно ограничено сервером, так что детектирование всегда возвращается само.

​
5. Правила последовательностей против детектирования аномалий

Они решают смежные проблемы — выберите то, что совпадает с тем, что вы знаете:
Правило последовательностиДетектирование аномалий
Вы создаётеТочную цепочкуНичего — оно обучается
ЛовитИзвестный многошаговый паттернНеизвестное / ненормальное
ДействуетПрименяет вердикт правила к завершающему вызову (audit / pending_approval / deny)Всплывает на ленте
Зрелое рабочее пространство запускает оба: детектирование аномалий — это радар, который всплывает цепочки, которых вы не предвидели — только всплытие, никогда блокировка; правила последовательностей — то, чем вы кодифицируете те, что у вас есть, так что они помечены, отслеживаются и (с вердиктом pending_approval или deny) способны ограничить завершающий вызов. Для жёсткой остановки одного вызова независимо от любой цепочки тянитесь за per-call вердиктом.

​
6. RBAC и маршруты за лентой

Лента аномалий и правила последовательностей сидят под управляющими маршрутами firewall рабочего пространства — ваша сессия / access-токен, никогда ретрансляционный ключ:
Метод и путьРольНазначение
GET /api/workspace/firewall/anomaliesMemberПрочитать ленту аномалий (?window=).
POST /api/workspace/firewall/anomalies/snoozeDeveloper+Отложить ленту ({until}, ограничено 7 днями).
POST /api/workspace/firewall/rulesDeveloper+Создать правило последовательности (или любое) под политикой.
POST /api/workspace/firewall/testDeveloper+Прогон политики вхолостую против образца вызова, прежде чем полагаться на неё.
Чтения ленты открыты каждому Member, так что вся команда может провести триаж; создание правил и откладывание ленты — записи Developer+, согласованные с остальной моделью RBAC firewall.

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

Схема правил

Полное поле sequence — шаги, min_count, window_seconds и каждое другое поле правила.

Журнал событий

Где приземляются совпавшие последовательности и аномалии — фильтруйте по прогону, поверхности и вердикту.

Cap cost

Превратите сигнал burn_spike в жёсткий потолок трат на прогон.

Контроль egress

Остановите финальный шаг эксфильтрации цепочки на сетевой границе.
О playbook’ах злоумышленника, которым противостоят эти механизмы, см. цепочечные атаки, эксфильтрацию данных и избыточную автономию. О глубоком справочнике firewall см. Правила Firewall.