Укротите автономного долгоживущего агента

Долгоживущий автономный агент — самое трудное для защиты. Он зацикливается сам по себе на часы, выбирает собственные инструменты, извлекает собственные URL и всё это время тратит ваши деньги. Режимы отказа — это не единственный плохой промпт, это цикл повторов, сжигающий $400 за ночь, вызов инструмента, который вы никогда не проверяли, ключ, который вы выпустили для недельного эксперимента и который всё ещё работает полгода спустя. Этот рецепт настраивает четыре контроля вокруг именно этой формы агента. Вы настраиваете их все в консоли (или REST API) — агент продолжает вызывать https://api.orcarouter.ai/v1/... ровно как раньше.

Новичок здесь? Сначала примените базис balanced и понаблюдайте, что делает ваш агент в течение дня. Эта страница — следующий шаг: превращение наблюдения в применение для агента, за которым вы не можете присматривать.

1. Рецепт безопасного автономного агента

Безопасному автономному агенту нужны четыре вещи, которых нет у чат-бота:

Жёсткий потолок стоимости

Правило cap_cost запрещает прогон, как только его накопленные траты пересекают ваш кап, — предохранитель для цикла, который не остановится.

Детектирование всплесков

Детектирование аномалий обучается нормальной форме агента по часу недели и флагирует всплески частоты и стоимости, которые проскальзывают мимо статических правил.

Подтверждение на опасных вызовах

Вердикт pending_approval удерживает деструктивные или необратимые вызовы инструментов на человека, вместо того чтобы доверять агенту быть осторожным.

Ключ, который истекает

Ограничьте ключ агента сроком истечения и кредитным потолком, чтобы забытый эксперимент не мог работать — или тратить — вечно.

Каждое соответствует одной политике Firewall или полю ключа. Ничто не касается кода вашего агента.

2. Ограничьте стоимость каждого прогона

Первое, что взрывает убегающий цикл, — это ваш бюджет. Правило cap_cost — это строгий потолок стоимости на предпроверке: когда оно совпадает, шлюз оценивает стоимость запроса и запрещает до диспетча, как только накопленные траты прогона превысили бы кап, — так что вызов сверх бюджета никогда не достигает провайдера. Кап ограничен прогоном. Шлюз суммирует предыдущие траты по всему прогону агента, так что долгий прогон, уже сжёгший большую часть бюджета, запрещается даже когда следующий отдельный вызов дёшев. Именно это делает его предохранителем, а не лимитом на запрос. Добавьте одно wildcard-правило в вашу политику firewall:

{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}

Это ограничивает прогон в $10 (cap_cost_cents в центах USD). Вердикт разрешается в allow, пока под бюджетом, и deny, как только оценка пересекла бы его. Большинство встроенных шаблонов firewall (Coding, Support, RAG, Data, DevOps, Browser) поставляют пер-прогонный кост-кап ровно такой — примените один и отредактируйте кап.

Накопление по прогону требует включённого захвата request-log для рабочего пространства. С выключенным свёртка предыдущих трат читается как ноль, и кап деградирует до пер-запросного — всё ещё безопасно, но не поймает медленную капельницу из 500 вызовов. См. denial-of-wallet.

3. Детектируйте всплески против обученного базиса

Кап останавливает катастрофу; детектирование аномалий ловит странное до того, как оно ею станет. Firewall обучается нормальной форме использования инструментов каждого рабочего пространства — 14-дневное скользящее среднее, разбитое по часу недели, так что трафик вторник-14:00 сравнивается с историей вторник-14:00, а не с плоским дневным средним, — и выводит отклонения на читаемой ленте:

rate_spike — инструмент срабатывает намного выше своей нормы

Объём вызовов по каждому инструменту, оценённый относительно обученного базиса. «143 вызова db.query за час против базиса в 8» всплывает даже когда каждый отдельный вызов разрешён.

burn_spike — стоимость, перелезающая обученные траты

Тот же базис, применённый к тратам вместо счёта, — прогон, который вдруг сжигает намного больше, чем этот час обычно.

retry_loop — агент, долбящий сбойный инструмент

Сигнатура автономного агента, застрявшего на повторах одного и того же сломанного вызова. См. избыточную агентность.

novel_path — переход инструментов, невиданный ранее

Хоп от инструмента к инструменту, который это рабочее пространство никогда не делало, — форма агента, идущего куда-то новое.

Лента сообщает имена инструментов, отредактированные id токенов и счётчики — никогда сырые аргументы. Чтение открыто любому Member; Developer+ может отложить (snooze) ленту на срок до 7 дней, пока расследует. Сочетайте ленту с правилом cap_cost, чтобы всплеск, который также сверх бюджета, был остановлен, а не просто замечен.

4. Удержите опасные вызовы на человека

Вы не можете проверять каждый вызов, который делает автономный агент, — но вы можете заставить его остановиться и спросить перед той горсткой, что важна. Вердикт pending_approval удерживает вызов инструмента вне основного канала:

Агент выпускает, скажем, вызов payments.transfer. Правило совпадает, и движок возвращает HTTP 400 firewall_approval_pending с id подтверждения — вызов никогда не достигает инструмента.
Ревьюер разрешает его из консоли (Developer+), или ваша собственная система разрешает его через подписанный HMAC вебхук-колбэк к POST /api/v1/firewall/approvals/:id/callback.
Агент опрашивает GET /api/v1/firewall/approvals/:id; после одобрения он повторно отправляет исходный вызов с одноразовым заголовком X-OrcaRouter-Firewall-Approval, и шлюз пропускает его этот один раз.

Правило, которое удерживает записи на деструктивную поверхность:

{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}

Выкатывайте это сначала в shadow-режиме — pending_approval понижается до audit, так что вы видите, какие вызовы удержались бы, не блокируя при этом вашего агента. Выключите shadow, когда лента выглядит правильно.

5. Дайте агенту ключ, который истекает

Контроль, переживающий каждую политику, — это сам ключ. Автономный агент должен получить ограниченный ключ, а не ваш дефолтный. Задайте эти поля при его выпуске (консоль → keys или token API):

Поле	Установите в	Зачем
`expired_time`	Unix-таймстамп	Эксперимент заканчивается; ключ умирает с ним. `-1` означает никогда — не используйте это здесь.
`credit_limit_usd`	долларовый потолок	Кап трат на ключе, независимый от капа прогона. `0` означает без лимита.
`firewall_policy_id`	ваша политика выше	Привязывает правила cap_cost + approval к этому ключу.
`allow_ips`	egress-IP агента	Утёкший ключ бесполезен откуда-либо ещё.

Задайте также тег environment, чтобы ключ — и всё, что он делает в Events и Matches — был атрибутируем этому агенту. Истекающий, кредитно-ограниченный, IP-закреплённый ключ — последняя линия: даже если бы каждую политику как-то обошли, радиус поражения ограничен временем и долларами.

Конфигурация ключа — это действие консоли / token-API и защищено ролью. Чтение plaintext ключа firewall-gateway требует Admin+.

6. Соберите всё вместе

Защищённый автономный агент в итоге получает одну политику firewall и один ограниченный ключ:

Слой	Контроль	Ловит
Бюджет	Правило `cap_cost`, ограниченное прогоном	Убегающие циклы, denial-of-wallet
Поведение	Лента аномалий (rate / burn / retry / novel)	Странное-но-разрешённое
Доверие	`pending_approval` на деструктивных инструментах	Необратимые действия
Область	Истекающий, кредитно-ограниченный, IP-закреплённый ключ	Забытые или утёкшие ключи

Создайте правила бюджета и подтверждения вместе, задайте пер-прогонный кап с правилами firewall и прочитайте остаток справочника Firewall о поверхностях, вердиктах и наблюдаемости. О связанных угрозах, от которых защищает этот рецепт, см. избыточную агентность, опасные вызовы инструментов и denial-of-wallet.

7. Дальнейшие шаги

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

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

Остановите эксфильтрацию

Egress-правила для агента, который извлекает собственные URL.

Режимы применения

Observe → shadow → enforce, безопасная выкатка.

Правила Firewall

Язык сопоставления за каждым правилом выше.

​1. Рецепт безопасного автономного агента

Жёсткий потолок стоимости

Детектирование всплесков

Подтверждение на опасных вызовах

Ключ, который истекает

​2. Ограничьте стоимость каждого прогона

​3. Детектируйте всплески против обученного базиса

​4. Удержите опасные вызовы на человека

​5. Дайте агенту ключ, который истекает

​6. Соберите всё вместе

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

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

Остановите эксфильтрацию

Режимы применения

Правила Firewall

1. Рецепт безопасного автономного агента

2. Ограничьте стоимость каждого прогона

3. Детектируйте всплески против обученного базиса

4. Удержите опасные вызовы на человека

5. Дайте агенту ключ, который истекает

6. Соберите всё вместе

7. Дальнейшие шаги