Grok Build 0.2.66: glob-паттерны для deny-листов sandbox и защита на уровне ядра — что операторы обязаны проверить

В Grok Build 0.2.66 (25 июня 2026 года) sandbox-контроль получил два структурных обновления: поддержку glob-паттернов в deny-листах и kernel-level deny для кастомных sandbox-профилей. Для операторов, запускающих Grok Build агентов в продакшн или маршрутизирующих их через модельный роутер, это не косметические изменения — они напрямую влияют на то, как пишутся, применяются и принудительно исполняются политики доступа к файловой системе.

Что изменилось в Grok Build 0.2.66

Релиз содержит три изменения, актуальных для операторского управления sandbox:

Deny-листы sandbox теперь поддерживают glob-паттерны. Раньше при написании deny-правил операторы перечисляли точные пути к файлам. С версии 0.2.66 deny-листы принимают shell glob-паттерны — например, **/*.pem блокирует все PEM-сертификаты в любом каталоге. Подход к написанию политик меняется: от перечисления путей к сопоставлению с паттерном.

Кастомные sandbox-профили теперь могут применять kernel-deny к конкретным файлам и каталогам. Ранее sandbox-профили блокировали пути на уровне приложения; в 0.2.66 для кастомных профилей появился механизм kernel-deny. Операции чтения и записи в kernel-protected пути блокируются на уровне ОС, а не перехватываются процессом Grok Build. Разница с точки зрения безопасности принципиальна: deny-листы на уровне приложения можно обойти, если агентский процесс способен запустить дочерний процесс, не наследующий deny-контекст; kernel-level deny — нет.

Локальные MCP-серверы теперь автоматически восстанавливаются после разрыва соединения или истечения сессии. Раньше разрыв соединения с локальным MCP-сервером (из-за сбоя процесса или истечения OAuth-токена) переводил Grok Build агента в деградированный режим, требующий ручного вмешательства. Автовосстановление означает, что агент продолжает работу после повторного подключения сервера.

В том же релизе исправлена регрессия аутентификации: теперь при наличии обоих факторов session-метод корректно имеет приоритет перед API-ключом. Это устраняет проблему некорректного auth-routing в двух-credential окружениях, где агенты долгое время непреднамеренно аутентифицировались через API-ключ вместо session-токена, обходя тем самым session-scoped политики доступа.

Почему glob-паттерны меняют подход к deny-листам

Переход от точных путей к glob-паттернам напрямую снижает затраты на сопровождение политик. Deny-листы на точных путях растут линейно вместе с числом защищаемых файлов; glob-паттерны позволяют выразить тот же охват значительно меньшим количеством правил.

Практическое следствие для операторов: существующие конфиги с точными путями продолжают работать, но команды должны проаудировать, можно ли выразить ту же защиту более надёжно через глобы. Конфиг, перечисляющий пятнадцать конкретных .env-файлов, не превращается автоматически в правило **/.env — миграцию надо выполнить явно. Риск бездействия: ложное ощущение полноты защиты, когда deny-лист закрывает известные чувствительные файлы, но пропускает новые секреты, добавленные в репозиторий позже.

Для операторов, чей модельный роутер принудительно задаёт sandbox-конфигурацию при запуске агента, поддержка глобов также меняет логику валидации. Роутер, ранее проверявший deny-листы по списку разрешённых путей, теперь должен обрабатывать glob-паттерны: **/*.key — это не путь, а выражение политики. Если ваш gateway-слой передаёт sandbox-конфиг в агент как статический JSON-объект, убедитесь, что сериализация и валидация этого объекта корректно обрабатывают строки с glob-символами (*, ?, [, ]) без экранирования.

Kernel-deny vs. application-layer deny: разница в governance

Добавление kernel-level deny для кастомных профилей в Grok Build 0.2.66 отражает тенденцию, складывающуюся на платформах coding-агентов: sandboxing на уровне приложения необходим, но недостаточен для high-trust-деплоев.

Application-layer deny-листы работают, перехватывая файловые операции внутри процесса агента. Если агентский код соблюдает список, файл не читается. Но если subagent, shell-команда или MCP-инструмент, вызванный Grok Build, обойдёт основной процесс — например, через прямой exec, запускающий неотслеживаемый дочерний процесс — deny-правило на уровне приложения может не сработать.

Kernel-deny работает на уровне syscall, ниже любой процессной границы. Файл или каталог, защищённый kernel-deny, недоступен для любого процесса, наследующего sandbox — включая subagent'ов, запущенных через помеченные GROK_AGENT=1 терминальные команды (добавлено в 0.2.68), и MCP-вызовы.

Рекомендации по выбору: application-layer deny — для общей гигиены: предотвращение случайного доступа к конфигам, ограничение области записи файлов. Kernel-level deny — для секретов, credentials и аудиторски значимых данных, где нужна гарантия на уровне ОС, а не на уровне соглашения агентского кода. Смешанный подход — application-layer для широкого охвата, kernel-deny для наиболее чувствительных путей — обеспечивает оптимальный баланс между гибкостью и безопасностью в enterprise-деплоях.

MCP-автовосстановление и управление сессиями

Изменение MCP-автовосстановления в 0.2.66 устраняет точку трения, влиявшую на то, как операторы проектируют и мониторят production Grok Build.

До 0.2.66 разрыв соединения с локальным MCP-сервером переводил агента в деградированный режим с обязательным ручным рестартом. Это создавало неявное требование к операторам: либо поддерживать high-availability MCP-инфраструктуру, либо мириться с необходимостью вмешательства после любого connectivity-события.

Автовосстановление снимает это требование. Агент переподключается автоматически при возврате сервера. Это актуально для routing-конфигураций, где набор MCP-инструментов, доступных агенту, определяет, какой downstream-провайдер или модель подходят: агент, лишившийся MCP-инструментов в середине сессии, мог маршрутизироваться нецелесообразно или давать output сниженного качества без ведома оператора.

Что следует проверить операторам TheRouter

Если вы маршрутизируете Grok Build через TheRouter или совместимый AI gateway, после выхода 0.2.66 стоит провести три аудита конфигурации:

Формат политики deny-листов. Убедитесь, используют ли ваши sandbox deny-листы точные пути и можно ли применить glob-паттерны для более надёжного выражения тех же правил. Руководство по конфигурации охватывает написание sandbox-политик для coding-агентов, деплоимых через модельный роутер. Наивысший приоритет при миграции: приватные ключи, сертификаты и credential-файлы (**/*.pem, **/*.key, **/*.env).

Кандидаты на kernel-deny в кастомных профилях. Если вы используете кастомные sandbox-профили Grok Build, определите, какие категории файлов и каталогов требуют kernel-уровня защиты вместо application-уровня. Стандартные кандидаты: credential-хранилища, signing-ключи и каталоги audit-логов. Kernel-deny стоит резервировать для данных, где нужны OS-enforced гарантии, а не соглашения агентского кода.

Алертинг на сбои MCP-сессий. Если у вас настроен алертинг, опирающийся на то, что агент останавливается с ошибкой при разрыве MCP-соединения, логику мониторинга необходимо обновить. С автовосстановлением агент продолжит работу молча после реконнекта. В зависимости от настройки observability, тихий реконнект может маскировать проблемы со стабильностью MCP-сервера.

Релиз Grok Build /goal с автономными агентами раскрывает, как двухмодельный pipeline Grok Build меняет routing surface для агентских verification-задач. Sandbox-изменения из 0.2.66 находятся на уровень ниже: они определяют, к чему агенту разрешён доступ на уровне инфраструктуры, независимо от того, какая модель или pipeline исполняется сверху.