Перейти к основному содержанию
Самая безопасная позиция для автономного агента — default-deny: блокировать каждый инструмент по умолчанию, затем явно разрешить только ту горстку, которую ваш агент должен использовать. Всё новое, что агент подхватывает — community-навык, неправильно настроенный MCP-сервер, инструмент, на который jailbreak уговорил модель, — отклоняется, потому что вы его не разрешали, а не потому что вы вспомнили его заблокировать. Эта страница — паттерн allow-листинга инструментов для агентов на api.orcarouter.ai: default-вердикт deny плюс одно или несколько правил allow, привязанных к tool_name_glob. О полном языке сопоставления за этими правилами см. Правила Firewall.
Allow-листы создаются в консоли под Security → Firewall или через управляющие маршруты /api/workspace/firewall/* (ваша сессия / access-токен — не ретрансляционный ключ sk-orca-…). Только вызовы /v1/* вашего агента используют ретрансляционный ключ. Создание или редактирование политики — действие Developer+.

​
1. Почему default-deny для агентов

Block-list («deny shell.exec, deny db.delete, …») всегда настолько полон, насколько полна последняя угроза, о которой вы подумали. Allow-list переворачивает бремя доказательства: шлюз отклоняет всё, что политика явно не разрешает, так что неизвестный инструмент закрыт по построению.

Default-вердикт = deny

Пол политики. Когда ни одно правило не совпадает, каждый вызов инструмента блокируется.

Allow-правила возвращают инструменты обратно

Каждое правило allow называет инструменты, которые вы реально используете — по точному имени или по глобу.
Движок проходит правила политики в порядке приоритета, и побеждает первое совпадение; если ничего не совпало, он откатывается к default_verdict политики. Так что allow-list — это просто: высокоприоритетные правила allow для ваших реальных инструментов, с полом deny, ловящим всё остальное.

​
2. Один пример: allow-list инструментов исследовательского агента

Допустим, вашему агенту нужно только искать в вебе и читать из базы знаний — инструменты с именами web.search и kb.read. Всё остальное (shell, запись файлов, мутации базы данных, любой инструмент, который может вызвать к жизни prompt-injection) должно быть отклонено. Постройте политику как default deny + два правила allow:
1

Создайте политику с default deny

Security → Firewall → Policies → New policy. Назовите её, оставьте Enabled включённым и установите default-вердикт в deny. Это закрытый пол — см. Создание политики.
2

Добавьте allow-правило на семейство инструментов

В редакторе правил добавьте два правила, оба verdict = allow:
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search — точное совпадение; kb.* — это префиксный глоб, который разрешает kb.read, kb.search и любой будущий инструмент kb.* без переписывания политики.
3

Привяжите её к ключу вашего агента

Установите firewall_policy_id ключа на эту политику (или сделайте её default рабочего пространства). Тело запроса вашего агента не меняется.
Теперь web.search и kb.read проходят; вызов shell.exec не совпадает ни с одним allow-правилом, попадает на пол deny и возвращается как HTTP 400 с кодом firewall_blocked на поверхности inbound — см. как выглядит блокировка.
Создавайте allow-правила как точные имена или узкие префиксы (kb.*), не широкие суффиксы. Свободный *.read разрешил бы kb.read и secrets.read — противоположность того, для чего нужен allow-list. Держите глоб настолько узким, насколько позволяет именование инструментов.

​
3. Глоб на одном экране

tool_name_glob — это маленькая, чувствительная к регистру грамматика — без regex, линейное время. Формы, которые важны для allow-list:
ШаблонРазрешает
web.searchРовно этот инструмент.
kb.*Префикс — kb.read, kb.search (не голый kb).
*.searchСуффикс — web.search, kb.search и голый search.
*.tools.*Инфикс — byo.tools.fetch и подобные.
О полной грамматике (правила инфикса, краевые случаи, глобы имён навыков) см. Синтаксис глобов и справочник Правил Firewall.
Глоб *.suffix также совпадает с голым, без пространства имён глаголом — *.search разрешает инструмент, буквально названный search, не только web.search. Провайдеры и MCP-серверы без пространств имён выставляют инструменты под голыми глаголами, так что allow-листнутый суффикс шире, чем выглядит. Предпочитайте точные имена или префиксы, когда хотите узкий allow-list.

​
4. Разверните его, не сломав агента

Default-deny — это позиция, наиболее вероятно блокирующая инструмент, который вы забыли, что вам нужен. Разворачивайте поэтапно:
Включите shadow-режим. Политика вычисляет и логирует ровно так, как вживую, но понижает каждый deny до audit с причиной с префиксом [shadow] would …. Прогоните реальный трафик, затем прочитайте ленту событий.
Discovered tools перечисляет каждый инструмент, который видело рабочее пространство, помеченный covered или gap. События «would-deny» shadow-режима плюс пробелы говорят вам ровно, какие allow-правила вам ещё нужны.
Песочница Test прогоняет политику вхолостую против образца вызова инструмента и возвращает вердикт, совпавшее правило и причину — ничего не диспетчеризуется, ничего не сохраняется. Подтвердите, что web.search разрешает, а shell.exec отклоняет, затем выключите shadow.
Отклонённый inbound-вызов не стоит токенов модели — он блокируется до запуска вышестоящей модели — и помечается skip-retry, так что заблокированный инструмент не сожжёт бюджет повторов, перезаблокировавшись. См. Вердикты.

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

Блокировать конкретные инструменты

Обратное — держать пол default-allow и отклонять названные инструменты.

Проверять аргументы

Разрешить инструмент, но только с безопасными аргументами (db.query, но не DROP TABLE).

Приоритет правил

Как first-match-wins ставит ваши allow-правила выше пола deny.

Вердикты

allow, audit, deny, sanitize, pending_approval, cap_cost.
Об угрозе, которую решает этот паттерн, см. избыточную автономию и опасные вызовы инструментов. О том, почему default-deny — это базовый уровень для агента, см. почему нулевое доверие.