Перейти к основному содержанию
Кодинг-агент — самая высокорычажная и одновременно самая опасная вещь в вашем рабочем пространстве. Он запускает shell.exec, редактирует файлы, извлекает URL и загружает community-навыки — любое из этого может сделать rm -rf на томе, прочитать .env или эксфильтрировать на хост злоумышленника. Этот рецепт ограничивает эту поверхность с помощью Firewall: запретить деструктивный shell, валидировать аргументы вызовов, которые вы всё же разрешаете, огородить egress и удержать действительно рискованные операции на человека. Ничто из этого не касается кода вашего агента — политика живёт в шлюзе и применяется на следующем вызове.
Всё ниже настраивается в консоли (Firewall → Posture / Policies). Эти маршруты управления используют вашу консольную сессию, а не ключ ретрансляции. Только вызовы /v1/*, которые делает ваш агент, несут ключ sk-orca-…. Редактирование политик требует роли Developer.

​
1. Начните с наблюдения, а не блокировки — базис безопасного кодинг-агента

Не пишите правила вслепую. Дайте агенту его ключ sk-orca-…, затем откройте Firewall → Posture и примените уровень автономии balanced (уровень автономии). В одной транзакции это аудирует каждый вызов инструмента, флагирует PII и запрещает деструктивный shell — так что худшее действие уже огорожено, пока вы изучаете остальное поведение агента из реального трафика. Дайте ему поработать, затем прочитайте Firewall → Discovered tools: каждый инструмент, который видело рабочее пространство, помеченный covered (применяется правило) или gap (ничего не применяется). Этот список — черновик вашего allow-list. Когда лента выглядит правильно, переходите к tight (default-deny) или создайте целевую политику ниже.
balanced — рекомендуемая стартовая позиция; permissive ничего не блокирует, но всё равно всё логирует; tight — это default-deny плюс пресеты секретов и SSRF. См. базис для точного описания того, что материализует каждый.

​
2. Запретите деструктивный shell — непереговариваемый пол

Единственное самое важное правило для кодинг-агента — никакого деструктивного shell. Уровни автономии balanced и tight уже поставляют это как пресет Block destructive shell, который материализует реальные, редактируемые правила deny, покрывающие как имена инструментов рабочего пространства напрямую (shell.*, bash, cmd.*, powershell.*, exec.*), так и MCP-неймспейсные формы, которые выставляет зарегистрированный сервер (*.shell.*, *.cmd.*, …). Если вы предпочитаете ограничить это плотнее, чем «запретить весь shell», создайте одно правило, которое запрещает только деструктивные команды и аудирует остальные. Правило сопоставляется по глобу имени инструмента плюс опциональному предикату аргумента (JSONPath против аргументов вызова):
В Firewall → Policies добавьте правило выше вашего default:
  • Глоб инструмента: shell.exec
  • Args match (клауза JSONPath):
{
  "clauses": [
    { "path": "$.command", "op": "regex", "value": "(?i)\\brm\\s+-[a-z]*[rf]" }
  ]
}
  • Вердикт: deny
Операторы аргументов — закрытый набор: eq, contains, regex, in, cidr_match, gt, lt. Вызов, чей $.command совпадает с regex, блокируется; всё остальное проваливается к следующему правилу.
Запрещённый вызов на поверхности inbound возвращает HTTP 400 с кодом ошибки firewall_blocked и сообщением, называющим инструмент и причину. Вызов, диспетчеризованный через MCP-шлюз, возвращается как ошибка инструмента (firewall deny: …), так что модель может среагировать, а не упасть. Блокировки inbound срабатывают до вышестоящего вызова модели, так что они не стоят токенов модели.
См. Правила firewall для полного языка сопоставления (глобы инструментов, клаузы аргументов, последовательности, кост-капы).

​
3. Валидируйте аргументы на инструментах, которые оставляете

Разрешить инструмент — не то же самое, что разрешить каждый его аргумент. Тот же предикат JSONPath, что ограничивает deny, позволяет вам ограничить форму разрешённого вызова — так что db.query не может нести DROP, а file.write не может выйти за пределы директории.

Заблокировать SQL DROP

Глоб db.query, клауза {"path":"$.sql","op":"regex","value":"(?i)\\bdrop\\b"}, вердикт deny.

Отредактировать секрет в аргументах

Вердикт sanitize редактирует совпавшие подстроки из аргументов вызова инструмента перед его пересылкой. Он никогда не касается того, что инструмент возвращает; на поверхности inbound (где ещё нет аргументов времени вызова) он эскалирует до блокировки.
Firewall очищает аргументы вызовов инструментов, а не результаты инструментов. Чтобы вообще не дать секрету попасть в запрос с самого начала, привяжите guardrail Secrets Blocker к ключу — он проверяет сам текст промпта до того, как его увидит модель. Две плоскости сочетаются: guardrails проверяют текст, Firewall управляет действием.

​
4. Контролируйте egress — огородите, куда агент может дотянуться

Кодинг-агент, который может извлекать URL, может быть направлен в SSRF (попадание в облачные метаданные или на внутренний хост 10.x) или использован для эксфильтрации. Уровень автономии tight поставляет пресет SSRF, который запрещает fetch-образные имена инструментов (http_fetch, web_search, fetch_url, request и их формы <server>.*) целиком. Для контроля на уровне назначения создайте правило egress. Egress-правила ограничивают по host или CIDR с записями allow / deny, вычисляемыми на поверхности egress: 
{ "deny": ["169.254.169.254", "10.0.0.0/8", "*.internal"] }
Это срабатывает на любом исходящем назначении, сообщённом инструментом, которое попадает в приватный диапазон, IP облачных метаданных или внутреннее имя хоста — пропуская публичные назначения и огораживая опасные.
Ни один пресет не поставляет egress-правил на основе CIDR — пресет SSRF сопоставляет fetch-образные имена инструментов. Deny-список host/CIDR выше — тот, что вы пишете сами. См. Остановите эксфильтрацию для полного паттерна.

​
5. Удержите рискованные операции на человека (HITL)

Некоторые операции не должны быть авто-разрешены или авто-запрещены — деплой, git push, деструктивная миграция. Для них используйте вердикт pending_approval. Вызов удерживается, агент получает ответ «held» с id подтверждения, и ревьюер разрешает его вне основного канала:
  1. Создайте правило (например, глоб deploy.*, вердикт pending_approval).
  2. Удержанный вызов возвращает HTTP 400 firewall_approval_pending с id подтверждения.
  3. Ревьюер одобряет его из консоли (Developer+) или через подписанный HMAC вебхук-колбэк.
  4. Агент опрашивает подтверждение, затем повторно отправляет исходный вызов с одноразовым заголовком X-OrcaRouter-Firewall-Approval — и шлюз пропускает его этот один раз.
Выкатывайте любую новую политику сначала в shadow-режиме. Политика вычисляется и логируется ровно так, как делала бы в production, но каждый применяющий вердикт понижается до audit с причиной [shadow] would … — так что вы можете доказать, что она срабатывает на ожидаемом, прежде чем она сможет сломать сборку.

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

Кодинг-агенты подтягивают возможности во время выполнения — community-навыки, свои MCP-серверы. Firewall управляет обоими в шлюзе:
  • Навыки сканируются в полосу риска с режимом применения (allow / quarantine / block). Автообнаруженный навык карантинируется — удерживается на подтверждение — пока ревьюер его не очистит. См. Навыки.
  • MCP-серверы, которые вы регистрируете, диспетчеризуют каждый tools/call через шлюз, который вычисляет каждый на поверхности mcp до диспетча. Учётные данные хранятся зашифрованными; health-проба сообщает ok / degraded / down. См. MCP-серверы и Защитите MCP-агента.

​
7. Проверьте и наблюдайте

Прежде чем полагаться на политику, прогоните её вхолостую. Вкладка Test вычисляет образец вызова инструмента против текущей политики и показывает вердикт, совпавшее правило и причину — ничего не диспетчеризуется, ничего не сохраняется. После запуска в production Firewall → Events / Runs — это запись каждого вычисления, фильтруемая по вердикту, поверхности, инструменту и прогону, а лента аномалий флагирует всплески частоты/стоимости против обученного базиса рабочего пространства, retry_loop и никогда ранее не виданные пути инструментов.

​
Резюме

Справочник Firewall

Полная плоскость политик — поверхности, вердикты, разрешение, автономия.

Правила Firewall

Язык сопоставления: глобы, клаузы аргументов, egress, последовательности.

Опасные вызовы инструментов

Угроза, от которой защищает этот рецепт.

Избыточная агентность

Почему сверх-привилегированные агенты — основной риск агента.

Рецепт автономного агента

Ограничьте полностью автономный цикл агента от начала до конца.

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

Паттерны egress и «летальной триады» в глубину.