Что делать, если AI-агент удалил не тот деплой
Автор под псевдонимом mirusser опубликовал на Medium колонку с вопросом, который платформенные команды раньше обсуждали как гипотетический: что делать, если AI-агент с доступом к CI/CD удаляет не тот деплой. Конкретного инцидента, компании или инструмента в тексте нет — колонка ставит вопрос и предлагает общую логику ответа.
Краткий ответ
Если AI-агент удалил не тот деплой, первый шаг — восстановление системы по заранее готовому плану, а не разбор причин на лету. После этого стоит урезать права агента до необходимого минимума, вынести деструктивные операции под подтверждение человека и вести отдельный журнал действий автоматизации, чтобы разбирать такие инциденты быстрее.
Что происходит, когда агент получает широкие права
Агентный AI в DevOps — это инструменты с прямым доступом к kubectl, Terraform, CI/CD-пайплайнам и облачным API. Такие агенты запускают деплой, чистят ресурсы, откатывают релизы самостоятельно, без промежуточного шага, на котором человек видит операцию и подтверждает её.
Автор колонки не описывает конкретный инцидент — это постановка вопроса, а не разбор случившегося. Компания, инструмент и дата в тексте не названы. На момент подготовки материала первоисточник был недоступен для повторной сверки формулировок, поэтому дальше мы опираемся на саму постановку вопроса, а не на прямые цитаты автора.
У агента нет того контекста, который есть у инженера: он действует в рамках выданных прав и полученной инструкции, а не по интуитивному пониманию, какой ресурс трогать нельзя. Это общий риск агентных систем, который в отрасли обсуждают шире, чем в одной конкретной публикации.
Где обычно ломается автономия агента
Инциденты такого рода почти всегда сводятся к нескольким типовым точкам отказа — это наблюдение о внедрении агентного AI в CI/CD в целом, а не пересказ колонки.
Сервисный аккаунт агента получает доступ ко всем окружениям сразу: prod и staging различаются только тегом, а не отдельным контуром доступа. Деструктивные операции — удаление, откат, terminate — выполняются без подтверждения человека. Действия агента редко попадают в отдельный журнал, поэтому их сложно отличить от обычных вызовов CI/CD при разборе инцидента.
Каждая причина по отдельности управляема. Вместе они создают условия, при которых одна неточная инструкция агенту приводит к потере продакшен-ресурса.
Как ограничить ущерб от AI-агента
Первоисточник на момент подготовки материала был недоступен для точной проверки, поэтому неясно, в какой структуре автор формулирует практические шаги. Дальше — реконструкция типовых практик ограничения ущерба, принятых в DevOps и platform engineering и применимых к любому агентному AI с доступом к инфраструктуре, а не пересказ конкретных рекомендаций колонки.
Принцип наименьших привилегий. Сервисный аккаунт агента получает только права, нужные для конкретной задачи. Прямой доступ к продакшену — только если задача явно его требует.
Разделение окружений. Prod и staging разделяются отдельными учётными данными и сетевыми контурами, а не только тегами. Тег легко проигнорировать, отдельный аккаунт — сложнее.
Approval gate для деструктивных операций. Удаление ресурса, откат релиза, изменение продакшен-конфигурации требуют подтверждения человека перед выполнением. Рутинные обратимые действия можно оставить автоматическими.
Журнал действий агента. Без отдельного лога разбор инцидента превращается в угадывание: журнал стоит завести до того, как агент получает доступ к реальной инфраструктуре.
Дополнительно помогает прогон типовых сценариев ошибок в изолированной среде до выдачи агенту прав на production — это общая практика проверки автоматизации, применимая и к агентам с моделью внутри.
Почему это важно
Агентный AI добавляет платформенным командам новый класс инцидентов. Ошибку скрипта или пайплайна разбирают по коду — там логика явная и воспроизводимая. Проверить логику решения модели сложнее: она не оставляет пошагового следа рассуждений, только результат вызова.
По нашей оценке, чем больше прав получают AI-агенты в проде, тем быстрее approval gate для деструктивных операций перестаёт быть формальностью и становится обязательным элементом эксплуатации. Пока колонки вроде этой — отдельные сигналы, а не статистика инцидентов. Но вопрос, кто отвечает за ошибку автоматизации и как быстро её исправить, становится практическим раньше, чем команды успевают выстроить процессы.
Что проверить у себя
Четыре вопроса, которые стоит задать до следующего деплоя с участием AI-агента.
Какие права выданы сервисным аккаунтам агентов — и нужны ли они все для текущих задач? Есть ли approval gate для delete, rollback и terminate в продакшене? Ведётся ли отдельный журнал действий агента, по которому можно разобрать инцидент? Прогонялись ли типовые сценарии ошибок в изолированной среде до выдачи прав на production?
Если хотя бы одного пункта нет, вопрос из заголовка колонки — что делать теперь — рано или поздно возникнет не как гипотетический.
FAQ
Что такое агентный AI в DevOps?
Это AI-инструменты с прямым доступом к CI/CD и облачным API: они запускают деплой, меняют инфраструктуру, удаляют ресурсы по инструкции — без промежуточного шага, на котором человек видит и подтверждает операцию.
Как ограничить права AI-агента в CI/CD?
Выдавать сервисному аккаунту агента только права, нужные для конкретной задачи, разделять окружения отдельными учётными данными и сетевыми контурами, а деструктивные операции держать под ручным подтверждением.
Нужен ли approval gate для всех операций AI-агента?
Нет. Рутинные обратимые действия можно оставить автоматическими. Approval gate нужен там, где операция деструктивна или её сложно отменить: удаление ресурса, откат релиза, изменение продакшен-конфигурации.
Что делать сразу после того, как автоматизация удалила не тот ресурс?
Сначала восстановление системы по заранее готовому плану, и только после этого разбор журнала действий агента, чтобы понять, какие права и правила позволили ошибке случиться.
Как проверить агента до выдачи прав на production?
Прогнать типовые сценарии в изолированной среде: попытка удалить не тот ресурс, выход за пределы назначенного окружения, деструктивная операция без явного разрешения. Если агент не останавливается там, где должен, доступ к production стоит отложить.