AI-агент видалив продакшн-базу під час заморозки коду. Чи змогли б ви відстежити таке у себе?

Проблема була в доступі, а не в інтелекті

Агент зробив те, що роблять агенти: діяв у межах того, до чого міг дотягнутися. Він міг дотягнутися до продакшну, а заморозка була інструкцією в розмові, а не дозволом у системі. Відповідь Replit була структурною — автоматичне розділення баз розробки й продакшну, кращий відкат і режим лише планування, в якому агент не може торкатися живого коду. Це правильний тип виправлення.

Більшість команд не запускає хмарного агента просто на своїй продакшн-базі. Але в багатьох є агенти й асистенти з правом запису в репозиторій, секретами CI в досяжності та пайплайном деплою на відстані одного мерджу. Питання ті самі: до чого він має доступ і хто затверджує останній крок?

Питання після інциденту

Коли щось ламається, перша година йде на реконструкцію: яка зміна, з якої гілки, як написана, хто затвердив. Коли в процесі є AI, у списку з’являється ще один рядок — яка сесія в якому інструменті привела до цього коміту. Якщо цей зв’язок не записано в момент роботи, відновити його потім дуже важко.

Телеметрія постачання свідчить, що це не крайній випадок. У звіті Faros AI за 2026 рік кількість інцидентів на змерджений pull request за високого рівня використання AI зросла на 242,7%, а кількість pull request’ів, змерджених без рев’ю, — на 31,3%. Більше змін, менше рев’ю, частіші збої: саме тоді відстежуваність перестає бути паперовою роботою.

Що з цим робити

Давайте агентам мінімальний доступ, з яким вони можуть працювати: жодних продакшн-облікових даних у середовищах розробки, захищені гілки, затвердження людиною для деплоїв і руйнівних міграцій. Тримайте резервні копії, які ви справді відновлювали. І записуйте одразу, яка AI-сесія створила яку зміну.

Джерела

• Fortune — AI-інструмент для коду стер базу даних софтверної компанії (липень 2025, англ.)
• Faros AI — AI Engineering Report 2026: The Acceleration Whiplash, ключові висновки (квітень 2026, англ.)