Kestra 2.0: как дать AI доступ к инфраструктуре и не отдать ему ключи

Самое интересное тут не в AI, а в границе доступа

Когда агенту дают shell, URL базы и облачные ключи, вопрос уже не в том, «умный» он или нет. Вопрос в том, сколько он успеет сломать, если ошибётся на одном шаге. И вот здесь Kestra, судя по описанию, пытается перевернуть привычную схему: не пускать модель в инфраструктуру напрямую, а дать ей только разрешённые действия.

Что произошло

Автор пишет, что весь год использует AI coding assistants для написания кода, но доверяет им не до конца — ограничение не в модели, а в доступе. Если агент добирается до реальной инфраструктуры, он получает слишком много полномочий: shell access, database URL, cloud key.

Kestra предлагает другой подход. Операция описывается в YAML в Git, а агенту отдают не секреты, а список flows, которые ему можно запускать. Каждый вызов возвращается как обычное execution, которое можно открыть и прочитать. В источнике отдельно сказано, что Kestra 2.0 уже вышла, а core остаётся под Apache 2.0.

“Kestra делает это наоборот. Операция описывается в YAML в Git, а agent получает список flows, которые ему разрешено запускать, вместо credentials.”

Что здесь неочевидно

Первое: это не про «ещё один AI-ассистент для разработчиков», а про контроль ущерба. В реальной компании проблема обычно не в том, что агент не умеет написать код, а в том, что ему слишком легко дать лишнее. И потом уже разбираться, кто именно удалил таблицу или уронил окружение.

Второе: такой подход хорошо ложится на команды, где уже есть дисциплина вокруг Git и workflow. Если у вас всё живёт в чатах, ручных доступах и «ну я потом дам права», магии не будет. Kestra тут скорее усиливает порядок, чем заменяет его.

Третье: формат execution как читаемого следа — это, по сути, нормальный аудит для людей. Для бизнеса это важнее красивого демо: можно понять, что агент сделал, где ошибся и кто это вообще разрешил.

Что это значит для бизнеса в России

Для наших компаний идея довольно приземлённая. Если вы хотите пускать AI в автоматизацию, лучше начинать не с «пусть он сам всё делает», а с режима, где он запускает заранее описанные сценарии без прямого доступа к секретам. Это особенно полезно там, где есть 1С, CRM, телефония, облака и несколько подрядчиков, а доступы раздаются по старой доброй схеме «на всякий случай».

По доступности из РФ я сам не проверял именно этот релиз, но сама логика инструмента не завязана на какой-то экзотический стек. Если нужен аналогичный подход, я бы смотрел в сторону связки с Git, оркестрацией задач и локальными/корпоративными моделями — хоть через GigaChat или YandexGPT, хоть через self-hosted модель, если вопрос в данных и контроле доступа.

И да, 152-ФЗ тут всплывает не из-за моды, а когда агент начинает видеть персональные данные, клиентские базы и внутренние документы. Тогда уже важно не «какой AI красивее», а где лежат данные и кто может их трогать.

Что бы я сделал на этой неделе

Если у вас уже есть автоматизации, я бы взял один процесс — например, выгрузку отчёта, создание заявки или запуск интеграции — и перевёл его в режим, где AI может только инициировать заранее описанный flow, но не получает ключи и прямой доступ к базе.

Сам ещё не гонял именно Kestra 2.0 в бою, как проверю — напишу. Но сама идея мне нравится: сначала ограничить радиус ошибки, а уже потом расширять полномочия. В AI-автоматизации это обычно и есть взрослая версия внедрения.