По описанию Financial Times, инженер AWS попросил AI-агента Kiro починить баг в Cost Explorer. Агент оценил ситуацию и определил, что оптимальный путь - удалить окружение и пересоздать с нуля.
13 часов даунтайма. Клиентский сервис лёг.
Amazon оспаривает эту интерпретацию и называет первопричиной неверно выданные права доступа: «user access control issue, not an AI autonomy issue».
Обе версии, если вдуматься, одинаково тревожные. Но по порядку.
Мандат
Что подтверждено: 24 ноября 2025 года внутреннее письмо за подписями двух SVP - Peter DeSantis (AWS Utility Computing) и Dave Treadwell (eCommerce Foundation) - устанавливает Kiro стандартным AI-инструментом для кодинга в Amazon. Цель: 80% инженеров используют Kiro еженедельно. К концу года. Отслеживается как корпоративный OKR. Источник - CNBC и Financial Times, несколько сотрудников подтвердили на условиях анонимности.
Kiro - внутренний AI-кодинг-агент Amazon. Запущен в июле 2025, маркетинг обещал «built to reason, execute, and refine continuously across development and operations». Агент умеет читать код, писать код, запускать команды, работать с инфраструктурой. Автономно - то есть без обязательного подтверждения перед каждым действием.
Что следует из косвенных признаков: примерно 1500 инженеров написали на внутренних форумах, что Claude Code работает лучше на их задачах. Что они уже выстроили workflow вокруг другого инструмента. Что 80% - это не метрика качества, а метрика лояльности.
Менеджмент продавил. Это не редкость - в любой компании бывают мандаты на внутренние инструменты. Вопрос не в мандате, а в том, что было дальше.
Delete and recreate
Декабрь 2025, точная дата не раскрыта. FT описывает инцидент так: инженеры AWS дали Kiro автономный доступ для решения софтверной проблемы в Cost Explorer.
Технически это означает: агент получил operator-level permissions в рамках данного окружения. Здесь важно, чего НЕ было. Не было обязательного peer review перед деструктивными операциями - стандартной практики для изменений в проде, которую Amazon давно применяет для людей (so-called «two-person approval»). Не было human-in-the-loop чекпоинта, который бы требовал подтверждения перед необратимыми действиями типа удаления окружения. И не было blast-radius limiter - механизма, который бы ограничивал масштаб возможного ущерба.
Агент оценил проблему и определил оптимальный путь: удалить окружение, пересоздать с нуля.
Аутейдж продлился 13 часов. Пострадал Cost Explorer в одном из китайских регионов AWS. Amazon уточняет: compute, storage, базы данных и AI-сервисы не затронуты. По их словам - ноль клиентских обращений.
Позиция Amazon: это «user access control issue» - инженеры выдали агенту слишком широкие права, виноват не AI, а настройка. «A coincidence that AI tools were involved.»
Позиция FT (четыре источника): агент действовал автономно и выбрал деструктивное решение как оптимальное. Отдельный инцидент с Amazon Q Developer тоже вызвал сбой при похожих обстоятельствах.
Кто прав - я не знаю. Но обе версии сходятся в одном: агент получил необратимые права без checkpoint.
Тут надо отступление
У меня самого был момент, когда Claude Code решил «оптимизировать» конфиг nginx и уронил dev-окружение. Не прод - dev-сервер на DigitalOcean. Но ощущение, когда агент сделал что-то, о чём ты не просил, запоминается. Ты вроде доверял, а он решил по-своему.
Разница в том, что мой dev-сервер стоит $12 в месяц. А Kiro работал с прод-инфраструктурой AWS.
С тех пор я использую --dangerouslyDisableSandbox только когда точно знаю, что делаю. И у Claude Code есть permissions в settings.json, где можно запретить агенту выполнять определённые команды без подтверждения. У Kiro, судя по описанию, такого гейта не было - или он был отключён.
6.3 миллиона
Январь 2026: Amazon сокращает порядка 16 000 сотрудников. Разворачивает тысячи AI-агентов в подразделении Stores. CNBC цитирует внутренние отчёты: «4.5x developer velocity».
5 марта 2026: Amazon.com падает на 6 часов. Checkout, pricing, accounts.
Что подтверждено: Amazon созвал совещание. Пресс-служба называет его «обычной еженедельной встречей по операциям». CNBC видел внутренние документы, где среди причин серии инцидентов фигурировало «Gen-AI assisted changes». Потом эту строчку удалили из документа - до совещания.
Позиция Amazon: только один из инцидентов вовлекал AI, и «причина не связана с AI - наши системы позволили инженерной ошибке иметь более широкое влияние, чем должно было быть».
Мой вывод: я не могу утверждать, что мартовский аутейдж напрямую вызван AI. Но удалённая строчка из документа и сам факт экстренного совещания не вяжутся с версией «обычная рабочая неделя». При этом даже по официальной версии Amazon проблема в том, что инженерная ошибка не была ограничена по blast radius. А если инженер - это AI-агент, вопрос blast radius становится вдвойне актуальным.
Нулевое сомнение
Человек с operator-level доступом к продакшену перед rm -rf делает паузу. Может, на секунду. Внутренний голос: «а точно? а бэкап есть?». Это не про квалификацию - это про risk aversion, встроенный в людей эволюцией.
AI-агент этого не делает. У него objective function: починить баг максимально эффективно. «Delete and recreate» - это не ошибка с точки зрения агента. Это оптимальное решение: быстро, чисто, гарантированно устраняет проблему.
Кто-то на LinkedIn сформулировал это точнее, чем я: «the agent inherited the permissions of a senior engineer… but none of the hesitation».
Права сеньора. Без его сомнений.
Это не философская проблема. Это инженерная. Destructive actions - удаление окружений, drop table, force push, изменение IAM policies - должны требовать отдельного подтверждения. Для людей это стандартная практика: two-person approval, MFA на критические операции. Для AI-агентов этих гейтов чаще всего просто нет.
Две недели спустя, Meta
18 марта 2026. Инженер Meta задаёт технический вопрос на внутреннем форуме. Другой инженер запускает AI-агента - The Verge описывает его как «similar in nature to OpenClaw within a secure development environment» - для анализа вопроса.
Что сделал агент: самостоятельно опубликовал ответ на форуме. Без разрешения запрашивающего инженера. Ответ предназначался только ему, но у агента не было gate на публикацию - разделения между «подготовить ответ» и «опубликовать ответ» в его workflow не существовало.
Важная оговорка: агент не делал прямых технических изменений в системе. Он дал неточную рекомендацию, сотрудник ей последовал, и уже человеческое действие привело к неправильной конфигурации permissions. Почти два часа проприетарный код, бизнес-стратегии и пользовательские данные были доступны инженерам без соответствующих прав.
Meta классифицировала инцидент как SEV1 - вторая по тяжести категория. Tracy Clayton, пресс-секретарь: «no user data was mishandled».
Формально Meta права: агент не трогал инфраструктуру. Но в феврале 2026 у другого сотрудника Meta агент OpenClaw начал удалять письма из инбокса без разрешения - а это уже прямое действие. Паттерн: агент превышает scope, потому что scope не был чётко определён.
По данным Saviynt 2026 CISO AI Risk Report (235 CISO): 47% видели непредвиденное поведение AI-агентов в своих средах. Только 5% уверены, что могут остановить скомпрометированного агента.
А теперь про другое: supply chain
24 марта 2026. Здесь природа инцидента принципиально иная - это не AI-агент, который «решил сам». Это классическая supply chain атака на инфраструктуру, которую используют AI-агенты.
LiteLLM - open-source прокси для LLM-провайдеров. Единый API для OpenAI, Anthropic, Azure, Bedrock. 95 миллионов загрузок в месяц с PyPI. 40 тысяч звёзд на GitHub. Если вы работаете с AI-агентами в проде, велик шанс, что LiteLLM или его зависимость где-то в вашем стеке.
Цепочка атаки по данным Snyk и Endor Labs:
19 марта - группа TeamPCP перезаписывает git-теги в trivy-action (GitHub Action для Trivy - сканера безопасности). Малварь harvester внутри.
23 марта - через ту же инфраструктуру компрометируют Checkmarx KICS. Регистрируют домен checkmarx.zone.
24 марта, 10:39 UTC - LiteLLM CI/CD запускает Trivy без pinned version, Trivy подтягивает заражённый экшен, TeamPCP получает PYPI_PUBLISH токен из GitHub Actions runner. Публикуют litellm==1.82.7.
10:52 UTC - версия 1.82.8 с дополнительным вектором: файл litellm_init.pth, который выполняется автоматически при каждом запуске Python-интерпретатора в окружении с установленным LiteLLM.
Payload: credential harvester (env vars, SSH-ключи, AWS/GCP/Azure/K8s creds, DB passwords), шифрованная эксфильтрация на models.litellm.cloud, persistent backdoor через ~/.config/systemd/user/sysmon.service, Kubernetes-червь через privileged pods в kube-system.
13:38 UTC - PyPI карантинит пакет. Окно: 3 часа, при 3.4 миллиона загрузок в день.
Почему я ставлю это рядом с Kiro и Meta, хотя природа другая: все три инцидента объединяет не «AI принял плохое решение», а общая проблема - инфраструктура AI-разработки построена на уровне доверия, который она не заслужила. Kiro получил неограниченные prod-права. AI-агент Meta получил право публиковать без review. А CI/CD пайплайн LiteLLM тянул Trivy без pinned version и хранил PyPI-токен как env variable, доступную любому GitHub Action.
Ирония в том, что Trivy - инструмент для поиска уязвимостей - стал точкой входа в атаку.
Что из этого следует
Я не буду писать «мы все обречены». Но три конкретных инженерных вывода из марта 2026 у меня есть.
Первый: необратимые действия AI-агентов должны требовать отдельного подтверждения. Удаление окружений, DROP TABLE, force push, изменение IAM policies - всё, что нельзя откатить за минуту, должно проходить через policy gate. Для людей два подтверждения перед rm -rf / - норма. Для агентов этого чаще всего нет. Amazon после инцидента ввёл mandatory peer review для AI-изменений в проде. Это правильно, но это реактивная мера.
Второй: AI-assisted changes в проде требуют blast-radius limits. Даже если агент действует правильно, масштаб ошибки должен быть ограничен архитектурно: feature flags, canary deployment, sandbox-first execution. Amazon в своём же официальном заявлении признаёт: «наши системы позволили ошибке иметь более широкое влияние, чем должно было быть». Вот это и есть отсутствие blast-radius limit.
Третий: CI/CD для AI-стека - это high-value target. LiteLLM показал, что supply chain атака на AI-инфраструктуру имеет мультипликаторный эффект: один отравленный пакет → все AI-агенты, которые через него ходят → все credentials, к которым у этих агентов есть доступ. Pinned versions, trusted publishing через JWT вместо долгоживущих токенов, аудит транзитивных зависимостей - это не параноя, а гигиена. Особенно когда ваш LLM-прокси имеет доступ к ключам от всех провайдеров.
Главная проблема не в том, что «агент ошибся». Агенты будут ошибаться - как и люди. Проблема в том, что мы даём им ошибаться дорого. Без checkpoint, без blast-radius limit, без review gate.
А потом удивляемся результатам.
P.S. Fortune цитирует анонимного инженера Amazon: «People are becoming so reliant on AI that essentially they stop reviewing the code altogether». Birgitta Böckeler из Thoughtworks на QCon London 2026: «The longer it goes without supervision, the more I have to review afterwards». Может, и не стоило давать агенту operator-level доступ к проду. Хотя бы до тех пор, пока у него нет встроенного risk aversion.
UPD: LiteLLM выложили security update - если у вас LiteLLM как транзитивная зависимость через AI-фреймворки или MCP-серверы, вы тоже можете быть затронуты. pip show litellm - проверяйте версию. Всё до 1.82.6 включительно - clean.
