Этот инцидент заставил задуматься команду, которая построила всю свою модель доступа к AWS на убеждении, что ключи доступа к продакшну могут иметь только внимательные люди. Теперь, когда ИИ-агенты встроены в рабочий процесс каждого разработчика, это убеждение оказалось ложным. В ответ компания внедрила «брокер доступа» (access broker), который заставляет любую операцию на уровне продакшна проходить через этап подтверждения человеком (human-in-the-loop).

Как произошел инцидент

Инженер дал запрос ИИ-агенту для написания кода, чтобы тот сгенерировал скрипт конвейера (pipeline script). Агент унаследовал IAM-роль инженера для продакшна — идентификатор AWS, который может создавать, изменять и удалять стеки CloudFormation. Скрипт запустился, создал стек в живой среде и тут же удалил его в качестве шага «очистки» (cleanup). Поскольку операция прошла в обход стандартного CI/CD-конвейера, механизм политик, который обычно контролирует такие изменения, ее не заметил.

Платформа мониторинга, настроенная на оповещение о любой роли, выполняющей привилегированные действия вне утвержденного конвейера, подняла тревогу в тот момент, когда стек был удален. Никакие сервисы не упали, но сигнал тревоги высветил сценарий, при котором опечатка в имени ресурса или ошибочный промпт для ИИ могли привести к удалению критически важной инфраструктуры.

Команда осознала: обнаружение — это не предотвращение. Если бы ИИ удалил не тот стек, это привело бы к катастрофе.

Почему старая модель учетных данных не сработала

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

Проблема «фоновых учетных данных» (ambient credentials) привела к тому, что IAM-роль продакшна фактически «закрепилась» на рабочей станции разработчика. ИИ-агент, работающий как подпроцесс в той же оболочке (shell), наследовал те же права и мог воздействовать на ресурсы продакшна так же, как и человек.

Брокер доступа: новый страж

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

Поток запроса

  1. Веб-портал — инженер открывает портал самообслуживания, выбирает необходимый уровень доступа (только чтение, разработчик или администратор) и указывает обоснование.
  2. Одобрение в Slack — запрос отправляется в выделенный канал Slack, где назначенный лицо, одобряющее запросы, должен явно предоставить разрешение.

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

Уровни доступа

  • Read-only (Только чтение) — пользователи могут просматривать ресурсы и логи, но не могут ничего изменять.
  • Developer (Разработчик) — предназначен для задач поддержки и настройки инфраструктуры; этот уровень блокирует деструктивные действия, такие как удаление стека или прямой доступ к данным клиентов.
  • Administrator (Администратор) — полные привилегии, зарезервированные для экстренных вмешательств и предоставляемые только после проверки на более высоком уровне.

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

Что на самом деле предотвращает брокер

Основная цель брокера — остановить использование фоновых учетных данных (ambient credentials), которые ИИ-агенты могут незаметно эксплуатировать. Даже если человек одобряет запрос, это осознанное решение; ИИ не может подделать этот шаг. В результате:

  • Непреднамеренные удаления — ИИ больше не может отдавать команду на удаление, если человек явно не авторизовал сессию.
  • Разрастание учетных данных — ключи продакшна больше не хранятся на машинах разработчиков, что сокращает поверхность атаки для злонамеренных инсайдеров и внешних субъектов, которые могут скомпрометировать ноутбук.

Команда подчеркивает, что система не устраняет человеческий фактор; ошибочное одобрение все еще может нанести ущерб. Однако она устраняет «скрытый» риск автономного кода, действующего с ресурсами продакшна без какого-либо контроля со стороны человека.

Выводы

Когда ИИ-агенты получают те же неограниченные права доступа, что и инженеры, они наследуют возможность вывести из строя продакшн — зачастую так, что никто этого не заметит. Централизуя привилегированный доступ через брокера, который требует отдельного канала подтверждения человеком, команда может предотвратить скрытое нанесение ущерба со стороны автономных скриптов, хотя человеческая ошибка все еще может стать причиной проблем. Настоящая победа в области безопасности заключается в устранении фоновых учетных данных, а не в контроле каждого отдельного решения.