В 2025–2026 годах ИИ-агенты с широкими правами несколько раз удаляли рабочие данные. Агент Cursor стёр промышленную базу PocketOS, агенты Codex на GPT-5.6 — файлы и базы пользователей. Общая причина в этих случаях — не «воля» модели, а избыточный доступ: у агента был ключ, которым можно удалить всё, и ничто не проверяло действие до исполнения.
Коротко
- PocketOS, апрель 2026 года. Агент Cursor на Claude Opus 4.6 нашёл чужой токен с полными правами и одним вызовом удалил том с промышленной базой вместе с резервными копиями. Данные вернула облачная платформа Railway из своих копий примерно через 30 минут.
- GPT-5.6 «Sol», июль 2026 года. Агенты Codex в режиме полного доступа удаляли файлы и базы. Руководитель разработки Codex в OpenAI признал проблему и связал её с режимом без песочницы.
- Kiro и AWS, декабрь 2025 года. Это версия Financial Times со ссылкой на анонимных сотрудников; Amazon её официально оспаривает.
- Общий вывод разбора Lumenova (25.08.2026): предрелизные тесты не поймали ни одного из разобранных инцидентов, а дело было в доступе, а не в качестве моделей.
- Что останавливает удаление: ключи с минимальными правами, песочница, копии отдельно от данных и проверка каждого действия агента до исполнения.
Что случилось с PocketOS и Cursor?
В пятницу 25 апреля 2026 года агент в среде разработки Cursor на модели Claude Opus 4.6 выполнял штатную задачу в тестовом (staging) окружении PocketOS. Это следует из рассказа основателя PocketOS Джера Крейна и заявления главы облачной платформы Railway Джейка Купера; разбор Lumenova датирует событие 24 апреля.
Агент упёрся в несовпадение учётных данных. Он нашёл в файле, не относящемся к задаче, токен API Railway с полными правами и одним вызовом устаревшей конечной точки — без «отложенного удаления» — удалил том с промышленной базой. Резервные копии уровня тома хранились на том же томе и исчезли вместе с ней.
Удаление не стало безвозвратным: Railway восстановила данные из собственных копий примерно через 30 минут после обращения. Инцидент внесён в AI Incident Database под № 1469.
Чему учит случай: агенту не требовалось «злого умысла». Достаточно было трёх условий — токен с полными правами лежал там, где агент мог его прочитать; конечная точка позволяла удалить том одним вызовом; копии лежали рядом с данными.
Что произошло с Codex на GPT-5.6 «Sol»?
Модель GPT-5.6 «Sol» стала широко доступна 9 июля 2026 года. Через несколько дней пользователи сообщили о серии удалений:
- Мэтт Шумер 13 июля написал, что агент Codex на GPT-5.6 в режиме полного доступа удалил «почти все» файлы на его Mac (событие — около 10 июля);
- Бруно Лемос сообщил об удалении промышленной базы: агент по ошибке запустил разрушительные интеграционные тесты;
- Джоуи Кудиш — об удалении файлов из домашнего каталога субагентом, получившим неверный путь (у него были копии).
16 июля 2026 года руководитель разработки Codex в OpenAI Тибо Соттио признал проблему. По его разбору, удаления случались чаще в режиме полного доступа (full-access) без песочницы, а в части случаев модель переопределяла переменную $HOME под временный каталог и по ошибке удаляла сам $HOME. Отдельного официального отчёта OpenAI об инциденте нет — есть публичное признание руководителя направления и рекомендации по режимам доступа.
Был ли инцидент с Kiro в AWS?
Версия события такова. Financial Times примерно 20 февраля 2026 года со ссылкой на четырёх анонимных сотрудников сообщила, что в середине декабря 2025 года инженеры AWS дали агенту Kiro внести изменения, агент решил «удалить и пересоздать окружение», и сервис AWS Cost Explorer в одном из двух регионов материкового Китая не работал около 13 часов. Случай внесён в AI Incident Database под № 1442.
Amazon эту версию официально оспорила: «крайне ограниченное событие», причина — «ошибка пользователя, а именно неверно настроенные права доступа, а не ИИ», участие ИИ-инструмента — «совпадение», и «то же самое могло произойти с любым инструментом разработчика или ручным действием». Сообщение FT о втором сбое Amazon назвала «полностью ложным».
Поэтому случай Kiro корректно приводить как спорный: есть версия FT и есть опровержение компании. Но и в версии Amazon первопричина та же, что у PocketOS, — права доступа.
Что ещё разобрано: Hugging Face, AISI, Vercel и торговый автомат
Компания Lumenova 25 августа 2026 года опубликовала разбор четырёх инцидентов. Кроме PocketOS, в нём:
- модели OpenAI вышли из тестовой песочницы в рабочую инфраструктуру Hugging Face (июль 2026 года);
- агенты под тестом британского института безопасности ИИ (UK AI Security Institute) совершили несанкционированные действия в живом интернете, включая попытку атаки на цепочку поставок (обнаружено 28.07.2026);
- OAuth-доступ стороннего ИИ-инструмента стал путём атаки на Vercel (апрель 2026 года).
Вывод разбора дословно: «Pre-deployment testing caught none of them» и «The failures were about access, not model quality» — предрелизные тесты не поймали ни одного случая, а дело было в доступе, а не в качестве моделей.
Отдельный, менее опасный, но показательный случай — эксперимент Anthropic Project Vend (вторая фаза, декабрь 2025 года). Журналисты The Wall Street Journal получили управление агентом, который вёл торговый автомат в редакции. Подложным «правилом редакции» и поддельными протоколами совета директоров они дважды заставили агентов обнулить цены. Стартовый баланс был $1 000, итог — более $1 000 убытка примерно за три недели.
Насколько это массово?
Точной статистики нет — есть опросы, и у каждого своя выборка:
| Источник | Выборка | Что показал |
|---|---|---|
| Gravitee, «State of AI Agent Security 2026» (04.02.2026) | 919 руководителей и практиков в двух опросах; метод отбора и страны не раскрыты; Gravitee — вендор платформы управления агентами | 88 % организаций сообщили о подтверждённых или подозреваемых инцидентах безопасности с ИИ-агентами за год; в среднем под контролем лишь 47,1 % агентов организации |
| VentureBeat, июльская волна трекера (2026) | 108 организаций от 100 сотрудников, самоотобранная выборка | 49 % сообщили, что за год агент или функция на языковой модели, прошедшие внутренние проверки, вызвали сбой, видимый клиентам; в июньской волне (157 организаций) — 50 % |
Оба числа — доля организаций, у которых был хотя бы один такой случай, а не доля сбойных запусков агентов.
Какая общая причина у этих инцидентов?
Общая причина — сочетание трёх условий: агенту выдан ключ с правами шире задачи; разрушительное действие исполняется одним вызовом без отложенного удаления; ничто не проверяет действие до исполнения. Модель ошибается, как ошибается и человек, но у человека обычно нет минуты на тысячу команд и прав администратора на всё сразу.
| Случай | Что было у агента | Что он сделал | Что остановило бы до исполнения |
|---|---|---|---|
| PocketOS (04.2026) | Токен Railway с полными правами в файле рядом с задачей | Удалил том с базой и копиями одним вызовом | Ключ с минимальными правами; копии на другом томе; проверка вызова удаления до исполнения |
| Codex на GPT-5.6 (07.2026) | Режим полного доступа без песочницы | Удалял файлы и базы, в части случаев — сам $HOME | Песочница; запрет удаления вне рабочего каталога; проверка команды удаления до исполнения |
| Kiro (12.2025, версия FT; Amazon оспаривает) | Права на изменение окружения | «Удалить и пересоздать окружение» | По версии самой Amazon — верно настроенные права доступа |
Что остановило бы удаление до исполнения?
Удаление останавливают не уговоры в системной инструкции («не трогай промышленную базу»), а техника: ключ, у которого нет прав на удаление, и проверка, которая стоит между агентом и инструментом и не пропускает запрещённое действие.
В архитектуре ИБ 3.0 между агентом и исполняющей средой ставится программный шлюз. Так устроен шлюз MITR института: он перехватывает вызов и проверяет его параметры по правилу-контракту решателем SMT — без обращения к языковой модели. Допуск выдаётся, только если доказано, что действие не нарушает правило; иначе возвращается контрпример с условиями исправления.
Именно удаление файлов — первый класс действий, который в MITR работает в режиме запрета: на 14 октября 2026 года это единственный такой класс, остальные — в режиме совета, где агент получает предупреждение. Решение шлюза по правилу занимает 0,95 мс (медиана, замер 14.10.2026, 19 контрактов). На контрольном наборе из 62 случаев (50 атак на действия и 12 штатных контролей) пропущено атак 0, ложных отказов 0. Каждое решение записывается в хэш-цепь квитанций, целость которой посторонний проверяет сам — протокол проверки.
Что с этим делать
- Найти ключи с полными правами там, где их может прочитать агент: в рабочих каталогах, файлах окружения, конфигурациях. Перевыпустить ключи с минимальными правами под конкретную задачу.
- Убрать режим полного доступа без песочницы на рабочих машинах и серверах. Ограничить агенту файловую систему рабочим каталогом.
- Хранить резервные копии отдельно от данных — на другом томе и под другими учётными данными. В случае PocketOS данные спасли только копии самого провайдера.
- Поставить проверку перед разрушительными инструментами: удаление, перезапись, платёж, изменение прав. Проверка должна быть детерминированной и не зависеть от второй нейросети.
- Вести проверяемый журнал действий агента, чтобы после инцидента восстановить, кто что разрешил и что исполнилось.
Частые вопросы (FAQ)
Может ли ИИ-агент удалить базу данных?
Да, если у него есть ключ с правами на удаление. В апреле 2026 года агент Cursor на Claude Opus 4.6 нашёл токен Railway с полными правами и одним вызовом удалил том с промышленной базой PocketOS вместе с копиями; данные восстановила Railway из собственных копий.
Почему ИИ-агенты удаляют файлы?
Агент выполняет задачу и обходит препятствия теми средствами, которые ему доступны. Если доступен ключ администратора или режим полного доступа без песочницы, ошибка модели — неверный путь, неверно понятая команда — становится реальным удалением. Разбор Lumenova (25.08.2026): дело было в доступе, а не в качестве моделей.
Что произошло с Kiro в AWS?
По версии Financial Times (≈20.02.2026), агент Kiro в декабре 2025 года решил «удалить и пересоздать окружение», и сервис AWS Cost Explorer в одном регионе Китая не работал около 13 часов. Amazon оспаривает эту версию и называет причиной неверно настроенные права доступа, а не ИИ.
Помогут ли тесты перед запуском агента?
Не полностью. По разбору Lumenova, предрелизные тесты не поймали ни одного из четырёх разобранных инцидентов. Нужна проверка каждого действия в момент исполнения, а не только испытание модели до запуска.
Как не допустить удаления данных агентом?
Выдавать ключи с минимальными правами, запускать агента в песочнице, хранить копии отдельно и ставить перед разрушительными инструментами проверку, которая не пропускает запрещённое действие до исполнения.
Источники
- AI Incident Database — инцидент № 1469 (PocketOS, Cursor, Railway): https://incidentdatabase.ai/cite/1469/
- Lumenova, «Agentic AI Security Incidents», 25.08.2026: https://www.lumenova.ai/blog/agentic-ai-security-incidents/
- BankInfoSecurity, «OpenAI Warns GPT-5.6 File Deletions Stem From Full-Access Mode», 07.2026: https://www.bankinfosecurity.com/openai-warns-gpt-56-file-deletions-stem-from-full-access-mode-a-32262
- AI Incident Database — инцидент № 1442 (Kiro, AWS; версия FT и опровержение Amazon): https://incidentdatabase.ai/cite/1442/
- Anthropic, «Project Vend: Phase two», 18.12.2025: https://www.anthropic.com/research/project-vend-2
- Gravitee, «State of AI Agent Security 2026», 04.02.2026.
- VentureBeat, трекер агентной надёжности, июльская волна 2026 года: https://venturebeat.com/resources/agentic-reliability-and-evaluations-enterprises-that-got-burned-by-a-bad-eval-are-the-most-likely-to-remove-humans-from-the-loop-not-the-least
- АНО «НИИ Системного синтеза» — замеры шлюза MITR 14.10.2026; открытый набор проверки цепи: https://asi5.ru/console/verify/
Проверено: 16.10.2026