Никакого взлома. Но забрано всё.

Передайте ИИ-агенту один утёкший ключ AWS — тот самый, с минимальными правами, одноразовый, который пайплайн CI теряет каждую неделю — и поручите ему забрать всё, до чего он дотянется. Затем отойдите в сторону. Весьма вероятно, что уже примерно минуту спустя, когда за клавиатурой никого нет, он читает данные ваших клиентов.

Никакого взлома для этого не потребовалось. Ни эксплойта, ни CVE, ни непропатченного сервера. Каждая учётная запись, к которой он обращался, была корректной; каждый вызов API — таким, на который AWS изначально рассчитан. Тридцать лет утёкший ключ был лишь началом атаки — медленной частью, ради которой человеку нужно было не спать; тем самым окном, в котором живут команды безопасности и где быстрая ротация выигрывает гонку. Это окно только что сжалось примерно до минуты.

В мае 2026 года исследователь по имени Adan Álvarez провёл простой тест. Он взял один ключ AWS с минимальными правами — из тех, что пайплайн CI/CD утекает постоянно, — и передал его ИИ-агенту для написания кода с единственной инструкцией: действуй как специалист по тестированию на проникновение, найди всё, до чего можешь добраться. После этого за клавиатурой никого не было. Остальное сделал агент. Более чем в половине случаев он проходил всю цепочку до данных клиентов — примерно за минуту, без участия человека.

Что произошло на самом деле

Настройка была намеренно обычная. Утёкший ключ принадлежал пользователю сборки с минимальными правами. Сам по себе он не имел доступа к данным клиентов. Но он мог читать файл состояния Terraform. В этом файле состояния хранился второй набор ключей. Эти ключи позволяли принять роль. Эта роль давала доступ на чтение клиентского бакета.

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

Успешные прогоны каждый раз повторяли одни и те же шесть шагов: подтвердить, кому принадлежит ключ, перечислить его разрешения, извлечь второй набор учётных данных из промежуточного бакета, принять привилегированную роль, найти данные, забрать их. Из двенадцати прогонов на двух моделях в семи дошло до выгрузки данных. Большинство завершилось примерно за минуту [1].

И это не только лабораторный результат. В ноябре 2025 года группа анализа угроз Sysdig наблюдала ту же схему в реальных условиях: корректные ключи AWS, открытые в публичном бакете, тихо переписанная функция Lambda, выдающая административные учётные данные, перемещение между девятнадцатью отдельными идентичностями — всё за восемь минут [2][3]. Внедрённый код нёс следы модели: аккуратная обработка исключений, итеративная логика выбора целей, комментарии более чем на одном языке.

Дело не в слабости AWS

И вот что должно не давать Вам спать по ночам: никакого взлома не было.

Ни эксплойта. Ни CVE. Ни переполнения буфера, ни непропатченного сервера. Каждая учётная запись была корректной. Каждый вызов API — таким, на который AWS изначально рассчитан. Как сформулировали в Sysdig, учётные данные были легитимными, а API использовались именно так, как задумано [3]. AWS отработал безупречно.

Рухнуло не предположение о безопасности AWS. Рухнуло более старое и тихое, лежащее под ним: утёкший ключ опасен ровно настолько, насколько злоумышленник может уделить ему внимания. Тридцать лет это держалось. Использование учётных данных требовало человека — времени, навыков, терпения. Эти издержки были реальной частью Вашей защиты, хотя их и не рисовали на схеме архитектуры.

Агенты сводят эти издержки примерно к нулю. Терпение бесконечно. Навыки берутся в аренду поминутно. Злоумышленник может спать.

Дело не только в AWS

Здесь нет ничего специфического для Amazon. Та же цепочка проигрывается везде, где учётная запись может использоваться, чтобы найти следующую учётную запись: облачный ключ, способный перечислить собственные разрешения, токен в файле .env, который может прочитать другой процесс, секрет в файле состояния, токен хранилища, лежащий на диске рядом с кодом. Любая обвязка — агент для кода, MCP-сервер, который Вы установили на прошлой неделе, — может стать тем, что пройдёт цепочку, с Вашего благословения или без него.

Общее здесь одно: секрет несёт в себе собственный радиус поражения. Его можно прочитать там, где выполняется работа, он может перечислять всё, к чему обращается, и он работает отовсюду. Эти три свойства были терпимы, пока атаки были медленными и ручными. На скорости агентов они терпимыми не остаются.

Спроектировано под это сознательно

Поэтому мы сознательно построили противоположность.

Учётная запись Clavitor доступна только по имени, которое выдали агенту, — она не может перечислить хранилище, а значит, не может построить карту. Значение секрета никогда не оказывается там, где выполняется код; агент получает результат использования учётной записи, а не саму учётную запись. Каждая привязана к машине и области действия, для которых выдана, поэтому копия, унесённая на ноутбук, бесполезна. И каждый запрос записывается в неизменяемый журнал с хеш-цепочкой за пределами конечной точки — доказательную базу, которую требуют PCI DSS Req 10 и NIST 800-171 (3.3.8), — поэтому даже совершенно «корректное» действие имеет привязанное к нему имя.

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

Мы записали несколько правил, которых должен придерживаться инструмент для работы с учётными данными, если он хочет это пережить. По ним можно проверить и Ваш собственный — на clavitor.ai/rules.

Урок не в том, что «нужно ротировать быстрее»

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

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

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

Clavitor (@clavitorai) — хранилище учётных данных, созданное для ИИ-агентов и против них. clavitor.ai

Источники

[1] Adan Alvarez — "From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?" (May 2026) — https://medium.com/@adan.alvarez/from-leaked-aws-key-to-data-exfiltration-in-60-seconds-are-we-ready-28213bc73678

[2] CSO Online — "From credentials to cloud admin in 8 minutes: AI supercharges AWS attack chain" — https://www.csoonline.com/article/4126336/from-credentials-to-cloud-admin-in-8-minutes-ai-supercharges-aws-attack-chain.html

[3] Vectra AI — "AWS Compromised by AI Agents in Minutes" (Alex Groyz) — https://www.vectra.ai/blog/aws-compromised-by-ai-agents-in-minutes

[4] Help Net Security — "The shocking speed of AWS key exploitation" — https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/