Сгенерированное ИИ задание cron менее чем за десять секунд удалило все активные подписки Stripe в одном стартапе, сократив ежемесячную регулярную выручку (MRR) компании до 38 долларов. Этот инцидент показывает, что опасность кроется в конвейере развертывания, а не в языковой модели, которая написала код.

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

На прошлой неделе команда BridgeMindAI обнаружила на дашборде ежемесячную регулярную выручку (MRR) всего в 38 долларов. ИИ-модель создала одну строку кода, которую планировщик запустил автоматически. Эта строка вызывала эндпоинт Stripe для отмены подписки для каждой записи клиента. Вызов завершился за семь секунд и полностью стер клиентскую базу.

Скрипт ошибочно интерпретировал пустую очередь на удаление как сигнал к удалению всего. Паттерн «пусто = всё» существует в продакшн-коде с 1980-х годов, задолго до появления генеративного ИИ.

Почему модель не является виновником

Люди быстро обвинили ИИ-модель в ненадежности. Замена модели не предотвратила бы очистку данных, так как ошибка заключалась в логике, написанной человеком, а не в галлюцинации или предвзятости.

Настоящие сбои были архитектурными:

  • Скрипт хранил рабочий API-ключ Stripe для продакшн-среды, который позволял отменять подписки.
  • Он запускался без какого-либо контроля во время выполнения.
  • Между генерацией кода и его выполнением не было контрольной точки с участием человека.

Эти пробелы позволили одной ошибке уничтожить поток доходов за считанные секунды.

Три вопроса безопасности для любого автономного конвейера

  1. Какие операции необратимы? Отмену подписки, удаление записи или возврат средств невозможно отменить. Они требуют большей защиты, чем запросы только для чтения.

  2. Какими учетными данными обладает агент? Предоставление мастер-ключа Stripe автономному процессу дает неограниченную власть. Применяйте принцип наименьших привилегий: используйте ограниченные ключи, которые могут выполнять только необходимую задачу.

  3. Где контрольная точка с участием человека? Одной проверки кода недостаточно. Вставьте шлюз после генерации кода и перед любым деструктивным действием.

Практические меры предосторожности

  • Шлюз предварительного запуска (Dry-run) — Перед любым вызовом удаления или отмены зафиксируйте целевые объекты в логах. Если список пуст или необычно велик, прервите операцию и оповестите человека.
  • Ограниченные учетные данные — По умолчанию используйте ключи только для чтения. Если задача требует отмены подписки, создайте ограниченный ключ, который может действовать только с одним ID клиента за раз.
  • Запрос с участием человека — Отправьте короткое сообщение в канал (например, Slack), вроде: «Я собираюсь отменить 47 подписок. Подтвердить?». Затраты ничтожны, а выигрыш в безопасности огромен.

Эти меры работают независимо от того, какая модель пишет код, потому что они защищают среду выполнения, а не генератор.

Чек-лист для автономных агентов в продакшне

  • Классифицируйте каждую операцию как чтение, обратимая или необратимая.
  • Требуйте явного одобрения человеком для всех необратимых действий.
  • Ограничивайте учетные данные минимальными правами, необходимыми для выполнения задачи.
  • Устанавливайте лимиты на количество итераций в циклах, которые удаляют или изменяют записи.
  • Сначала запускайте агентов в песочнице, которая имитирует продакшн-данные; подтверждайте результат, прежде чем прикасаться к реальным данным.
  • Перед выполнением записывайте план агента простым языком, чтобы проверяющий мог мгновенно понять намерение.

Следование этому чек-листу превращает скрипт типа «запустил и забыл» в контролируемый рабочий процесс, который можно проверить и остановить, если что-то пойдет не так.

Урок очевиден: доверяйте процессу, а не модели.