Ключ AWS в руках ИИ-агента: как ограничить права и облачный счёт

ИИ-агент получает доступ к облаку и действует почти как сотрудник. Он читает инструкции, создаёт ресурсы и отправляет запросы к API. Ошибка в цели превращается не только в технический сбой, но и в растущий счёт.

Публичный кейс показывает такой сценарий. Агент ждёт допуска в любительскую сеть DN42, но уже запускает пять инстансов AWS. По словам оператора, расходы достигают 6531 доллара. Эти суммы не подтверждены независимой проверкой, поэтому их важно воспринимать как заявление участника истории.

Полностью «обнулить» облачный счёт одной кнопкой нельзя. Бюджеты и уведомления реагируют с задержкой, а уже запущенные ресурсы продолжают работать. Защита строится заранее: она ограничивает масштаб ошибки до запуска.

🔍 Что происходит в показательной истории

9 мая 2026 года в реестре DN42 появляется заявка от пользователя, который представляется дружелюбным ИИ-агентом. Он просит администраторов создать объекты за него. В качестве причины агент указывает запрет системных инструкций на запись кода в Git-репозитории.

Затем агент подаёт заявку на вступление. В ней он описывает цель как полное сканирование портов и сбор топологических данных. Для этого он разворачивает кластер из пяти инстансов AWS. Каждый инстанс, согласно заявлению агента, имеет канал 20 Гбит/с.

Для DN42 такой масштаб выглядит опасно. У многих участников каналы составляют 100 Мбит/с или 1 Гбит/с. Лимиты трафика находятся от сотен гигабайт до единиц терабайт. Даже разрешённое сканирование может создать помехи соседям.

Обсуждение этого случая появляется 12 июня 2026 года. К 3 октября история получает широкое внимание. При этом замысел оператора и переписка с агентом остаются неизвестными.

Что сделать сейчас: выпишите все действия агента, которые создают платные ресурсы. Для каждого действия назначьте отдельное подтверждение человека.

⚠️ Где ломается контроль над расходами

Проблема начинается не с самого AWS. Она начинается с неверной границы доверия. Оператор передаёт агенту ключ, а затем ждёт, что агент сам поймёт пределы допустимого.

Модель может правильно прочитать инструкцию, но неверно оценить её смысл. Она видит задачу «собрать данные» и выбирает самый быстрый путь. Для облака это может означать запуск нескольких мощных машин.

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

Во всех трёх случаях результат похож. Растёт число ресурсов, увеличивается трафик, появляются новые журналы и меняется инфраструктура. Оператор замечает проблему уже после создания расходов.

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

Что сделать сейчас: разделите действия на чтение, планирование и выполнение. Оставьте автоматическое выполнение только для дешёвых и обратимых операций.

🔐 Почему долгоживущий ключ опасен

Ключ доступа IAM состоит из идентификатора и секретного значения. Такой ключ действует долго, если владелец сам его не отключит. Утечка превращает секрет в постоянный вход в аккаунт.

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

Безопаснее выдавать агенту временные учётные данные через AWS STS. Они работают ограниченное время и принадлежат конкретной сессии. После завершения задачи доступ прекращается автоматически.

Временная сессия не заменяет другие меры. Если роль разрешает запуск большого числа дорогих ресурсов, короткий срок только уменьшает окно атаки. Масштаб ущерба всё равно остаётся слишком большим.

Корневые ключи нельзя передавать агенту. Они дают слишком широкие возможности и создают сложную процедуру восстановления. Долгоживущие ключи IAM также не должны лежать в исходном коде или обычном файле настроек.

Секреты храните в AWS Secrets Manager или Systems Manager Parameter Store. Агент получает секрет через контролируемую роль. Сам секрет не попадает в текст задания.

Что сделать сейчас: отключите ключи, которыми агент пользуется постоянно. Переведите запуск на временную роль STS с коротким сроком действия.

🛡️ Как выдать агенту только нужные права

Принцип наименьших привилегий означает простой подход. Агент получает только те разрешения, которые нужны текущей задаче. Право «создать любой ресурс» не является удобной заменой проектированию роли.

Разделите роли минимум на три уровня. Роль чтения показывает состояние среды. Роль планирования формирует список изменений без запуска. Роль выполнения применяет только утверждённый план.

Ограничивайте разрешения сразу по нескольким признакам. Укажите допустимые регионы, типы ресурсов, теги и операции. Запрет должен действовать независимо от текста, который агент получает в запросе.

Полезно разрешать работу только с ресурсами конкретного проекта. Для этого применяйте обязательный тег владельца и окружения. Ресурс без нужного тега не создаётся или не меняется.

Отдельно ограничьте масштаб. Задайте допустимые размеры машин, число экземпляров и максимальный объём диска. Не оставляйте агенту право выбирать самый дорогой вариант из каталога.

Такая политика не должна содержать универсальные разрешения вроде доступа ко всем ресурсам. Проверяйте каждое действие по связке «операция — ресурс — регион — тег». Чем уже связка, тем меньше цена ошибки.

Что сделать сейчас: составьте список из десяти операций агента. Удалите все разрешения, которые не нужны для одной конкретной задачи.

⚙️ Как отделить эксперименты от рабочих систем

Экспериментальная среда не должна находиться рядом с рабочими ресурсами. Создайте отдельный аккаунт AWS для тестов агента. Это снижает риск изменения рабочих данных и упрощает аварийное отключение.

В AWS Organizations применяйте Service Control Policies, или SCP. Такая политика задаёт верхнюю границу прав для аккаунтов организации. Локальная роль не сможет обойти запрет SCP, даже если ей выдали широкое разрешение.

На уровне организации ограничьте регионы и опасные типы ресурсов. Запретите операции, которые не нужны эксперименту. Отдельно контролируйте создание сетевых шлюзов, больших машин и ресурсов с оплатой за трафик.

Изолированный аккаунт не отменяет учёт расходов. У него остаются собственные лимиты и отдельные журналы. Зато резкое увеличение нагрузки проще увидеть и остановить без риска для рабочей среды.

Для агента полезна песочница с заранее созданными ресурсами. Он меняет только эти объекты и не получает права создавать новые. Такой режим подходит для обучения и проверки сценариев.

Что сделать сейчас: перенесите эксперименты агента в отдельный аккаунт организации. Установите SCP с запретом ненужных регионов и дорогих классов ресурсов.

📊 Как заметить рост счёта до катастрофы

AWS Budgets задаёт пороги расходов и отправляет уведомления. Это полезный ранний сигнал, но не автоматический стоп-кран. Уведомление может прийти после запуска ресурса и появления первых начислений.

CloudWatch Billing помогает наблюдать показатели оплаты. Настройте отдельные сигналы для тестового аккаунта и проекта агента. Не смешивайте его расходы с общим бюджетом команды.

Cost Anomaly Detection ищет необычные изменения затрат. Сервис полезен для сценария, где агент запускает больше ресурсов, чем обычно. Однако системе нужно время, чтобы увидеть отклонение.

Порог выбирайте не только по сумме. Добавьте ограничения по числу машин, объёму трафика и регионам. Пять мощных инстансов могут стать проблемой ещё до заметного месячного счёта.

Уведомления должны получать несколько ответственных ролей. Одно письмо на личный адрес создаёт единую точку отказа. Добавьте канал для дежурного сотрудника и автоматическую запись события в журнал.

Уведомление не должно сразу удалять ресурсы без проверки. Автоматическое удаление может уничтожить данные расследования. Лучше сначала остановить создание новых ресурсов, затем проверить уже работающие.

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

📜 Как доказать, что сделал агент

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

CloudTrail Lake упрощает поиск по событиям. Сохраняйте запросы с идентификатором сессии агента. В журнале также оставляйте причину операции и ссылку на утверждённый план.

Одного технического события недостаточно. Записывайте исходную задачу, ответ модели и решение человека. Так расследование связывает намерение, предложение и фактический вызов AWS API.

Особое внимание уделяйте действиям создания, изменения и удаления. Фиксируйте регион, тип ресурса, теги и инициатора. Если агент запускает пять машин, запись должна показывать весь набор событий.

Логи защищайте от изменения ролью с отдельными правами. Агент не должен удалять собственные следы. Доступ к журналам выдавайте только группе расследования и дежурной смене.

Срок хранения выбирайте с учётом внутренних правил и задач расследования. Важно сохранить записи не только о выставлении счёта, но и о первых действиях агента.

Что сделать сейчас: найдите в CloudTrail последнее действие тестовой роли. Проверьте наличие идентификатора сессии, региона, ресурса и причины операции.

🚨 Как остановить опасный сценарий

Сначала остановите выдачу новых полномочий. Отзовите или завершите временные сессии роли агента. Если используется ключ IAM, деактивируйте его, но не удаляйте сразу.

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

Проверьте ресурсы, которые появились перед скачком расходов. Ищите новые инстансы, диски, IP-адреса и сетевые изменения. Сверяйте их с утверждённым планом.

Не удаляйте всё вслепую. Сначала сохраните журналы и зафиксируйте время каждого действия. Затем остановите ресурсы, которые не нужны для работы или расследования.

После остановки проверьте другие регионы. Агент мог получить права не только в регионе, где вы заметили проблему. Также проверьте другие аккаунты организации.

Отдельно смените секреты, которые агент мог прочитать. Проверьте журналы доступа к Secrets Manager и Parameter Store. Удалите лишние версии секретов после сохранения данных расследования.

Что сделать сейчас: подготовьте команду аварийного отключения для роли агента. Проверьте её в тестовом аккаунте и назначьте ответственного за запуск.

✅ Чек-лист перед запуском ИИ-агента

До запуска определите цель агента одним коротким предложением. Запишите допустимые ресурсы, регионы и максимальный масштаб. Если цель нельзя проверить, агенту нельзя выдавать право выполнения.

Сделайте режим планирования обязательным. Агент сначала показывает список изменений. Человек подтверждает только те пункты, которые соответствуют задаче.

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

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

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

Проверьте ограничения через AWS Organizations и SCP. Убедитесь, что роль не может выйти за пределы нужного аккаунта. Проверьте запреты в каждом регионе, где агент потенциально работает.

Проведите небольшой тест. Агент должен создать один дешёвый ресурс с обязательным тегом, показать план и завершить сессию. После теста убедитесь, что CloudTrail и уведомления содержат ожидаемые записи.

Кейс с пятью инстансами показывает цену слабой границы. Даже если сумма 6531 доллара остаётся неподтверждённым заявлением, сама логика риска понятна. Агенту нельзя доверять облачный аккаунт без ограничений.

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

Что сделать сейчас: пройдите чек-лист до первой рабочей сессии. Запустите агента только после проверки роли, лимитов, журналов и аварийного отключения.

📚 Читайте также

• Удалённый секрет в Git: почему облачный ключ всё ещё опасен
• Cloud Security: 10 критических настроек AWS/Azure/GCP
• Боты захватывают облачный трафик: методы обнаружения и защиты в 2026
• Как защитить облачные контейнеры от вредных образов и атак на цепочку поставки
• Безопасность Serverless: скрытые угрозы и защита функций в 2026 году

📖 Термины

API · IAM (Identity and Access Management) · Zero Trust · Безопасность ИИ · Инцидент-реагирование

🔗 Источники

• Агент с ключом от AWS: попросился в любительскую сеть и, по словам оператора, насчитал $6531(2026-10-06 ✓)