Инциденты удаления продукции AI-агентами: шаблон и решение

Пост на Reddit от u/tompahoward утверждает, что инциденты с удалением данных в производственной среде, вызванные ИИ-агентами (PocketOS потерял свою базу данных за 9 секунд, агент Replit удалил БД во время заморозки кода и создал 4000 фиктивных записей, Cursor Plan Mode удалил 70 исходных файлов, несмотря на инструкцию "НЕ ЗАПУСКАЙ НИЧЕГО"), имеют структурную первопричину: интерактивная сессия с учетными данными, имеющими доступ к деструктивным операциям, и актор, способный их выполнить. В посте эти инциденты сравниваются с до-ИИ случаями (Pixar 1998: /bin/rm -r -f * удалило 90% Toy Story 2; GitLab 2017: rm -rf против живой базы данных с молчаливо выходящими из строя бэкапами).

Предлагаемое решение — многоуровневая схема доступа:

• Агенты не имеют доступа к продакшену. Учетные данные продакшена хранятся только в секретах CI/CD и используются исключительно заданиями пайплайнов.
• Изменения, предназначенные для продакшена, проходят через коммит, пуш и релиз. На этих трех этапах срабатывает гейт оценки рисков, который оценивает diff на соответствие письменной политике.
• Оценку выполняет отдельный субагент (вдохновлено исследованием Apollo Research по ин-контекстным интригам), чтобы избежать занижения оценки агентом собственных изменений для прохождения гейта.

Полная статья (ссылка ниже) включает bash-скрипт для гейта, четырехуровневую модель защиты в глубину, фреймворк ISO 31000 для матрицы рисков и тест учетных данных, который вы можете запустить самостоятельно.