Цей інцидент змусив команду, яка побудувала всю свою модель доступу до AWS на переконанні, що продуктивні ключі мають лише уважні люди, переглянути свої підходи. Оскільки тепер AI-агенти інтегровані в робочий процес кожного розробника, це переконання виявилося хибним. У відповідь компанія впровадила «брокера доступу», який змушує будь-яку операцію на рівні продуктивного середовища проходити етап схвалення за участю людини (human-in-the-loop).

Як стався інцидент

Інженер надав запит AI-агенту для написання коду, щоб згенерувати скрипт конвеєра. Агент успадкував IAM-роль інженера — ідентифікатор AWS, який може створювати, змінювати та видаляти стеки CloudFormation. Скрипт запустився, створив стек у живому середовищі та негайно видалив його як крок «очищення». Оскільки операція оминула стандартний CI/CD-конвеєр, механізм політик, який зазвичай контролює такі зміни, її не помітив.

Платформа моніторингу, налаштована на сповіщення про будь-яку роль, що виконує привілейовану дію поза межами схваленого конвеєра, підняла тривогу в момент видалення стека. Жодні сервіси не відмовили в роботі, але сигнал тривоги підсвітив сценарій, за якого помилка в імені ресурсу або некоректний запит до AI могли б стерти критично важливу інфраструктуру.

Команда зрозуміла: виявлення — це не запобігання. Якби AI видалив не той стек, це призвело б до катастрофи.

Чому стара модель облікових даних не спрацювала

Попередній підхід організації базувався на короткочасних сесіях, захищених багатофакторною автентифікацією (MFA). Теоретично розробник запитував сесію, виконував завдання, і облікові дані автоматично анулювалися. На практиці ж, щойно сесія запускалася на ноутбуці, вона залишалася активною протягом усього часу роботи машини. Кожен процес — тестові набори, фонові скрипти, а тепер і AI-агенти — повторно використовував ці облікові дані без будь-якої додаткової перевірки.

Ця проблема «фонових облікових даних» призвела до того, що продуктивна IAM-роль закріпилася на робочій станції розробника. AI-агент, що запускався як підпроцес у тому ж терміналі, успадковував ті самі дозволи і міг діяти з продуктивними ресурсами так само, як і людина.

Брокер доступу: новий охоронець

Щоб розірвати ланцюг фонових облікових даних, команда змінила архітектуру того, хто може приймати продуктивні ролі. Замість того, щоб дозволяти будь-якій ідентичності розробника безпосередньо приймати привілейовану роль, вони запровадили єдину, суворо контрольовану сутність: внутрішній брокер доступу.

Процес запиту

  1. Вебпортал – інженер відкриває портал самообслуговування, обирає необхідний рівень доступу (тільки для читання, розробник або адміністратор) і надає обґрунтування.
  2. Схвалення в Slack – запит надсилається у спеціальний канал Slack, де призначений одовувач має явно надати дозвіл.

Крок у Slack виступає як другий фактор на платформі, відмінній від термінала, у якому працює AI-агент. Оскільки схвалення має відбуватися в окремому інтерфейсі, автономний скрипт не може самостійно завершити робочий процес.

Рівневий доступ

  • Тільки для читання – користувачі можуть переглядати ресурси та логи, але не можуть нічого змінювати.
  • Розробник – призначений для завдань підтримки та налаштування інфраструктури; цей рівень блокує деструктивні дії, такі як видалення стека або прямий доступ до даних клієнтів.
  • Адміністратор – повні привілеї, зарезервовані для екстрених втручань і надаються лише після перевірки вищого рівня.

Спрямувавши весь доступ до продуктивного середовища через брокера, команда зосередила ризики в одному суворо захищеному сервісі, замість того щоб розкидати привілейовані облікові дані по всіх ноутбуках.

Що насправді запобігає брокер

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

  • Непередбачені видалення – AI більше не може видавати команду на видалення, якщо людина явно не авторизувала сесію.
  • Розростання облікових даних – продуктивні ключі більше не зберігаються на машинах розробників, що зменшує поверхню атаки для зловмисних інсайдерів та зовнішніх гравців, які можуть скомпрометувати ноутбук.

Команда наголошує, що система не усуває людський фактор; помилкове схвалення все ще може завдати шкоди. Проте вона усуває «тихий» ризик автономного коду, що діє з продуктивними ресурсами без жодного контрольного пункту з боку людини.

Висновок

Коли ШІ-агенти отримують такі ж необмежені облікові дані, як і інженери-люди, вони отримують можливість вивести з ладу продакшн — часто непомітно для оточуючих. Централізуючи привілейований доступ через брокера, який вимагає окремого каналу підтвердження людиною, команда може запобігти тому, щоб автономні скрипти непомітно сіяли хаос, хоча людська помилка все одно може спричинити проблеми. Справжня перевага в безпеці полягає в усуненні фонових облікових даних, а не в контролі над кожним окремим рішенням.