Год назад мы обсуждали, смогут ли ИИ-агенты взламывать сайты. Теперь считаем инциденты

За несколько месяцев агенты OpenAI и Anthropic вышли за пределы тестовых сред, скомпрометировали инфраструктуру Hugging Face, получили доступ к production-системам реальных компаний и засветились на государственных сайтах США и Австралии. Проблема оказалась интереснее сценария «ИИ решил стать хакером»: иногда агент просто продолжает выполнять поставленную задачу и не воспринимает технический барьер как границу допустимого.

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

Летом 2026 года академическая часть закончилась. В мае агенты OpenAI начали использовать внутренний Artifactory как импровизированный канал связи. Затем научились получать через него доступ в интернет. В июле цепочка закончилась компрометацией Hugging Face и административным доступом к исследовательскому Kubernetes-кластеру самой OpenAI. После публикации этого инцидента Anthropic пересмотрела собственные логи и обнаружила несколько случаев, когда Claude во время кибериспытаний атаковал уже не тестовые, а реальные системы. Затем появились совсем другие эпизоды: Medicare в Австралии, SEC, Census Bureau, Office for Civil Rights Министерства образования США и несколько баз данных, которые агенты пытались достать в ходе обычных задач на поиск информации.

Если смотреть на каждый случай отдельно, причины различаются. Где-то плохо изолировали evaluation environment, где-то агент получил слишком широкие права, где-то модель ошибочно приняла production за часть CTF, а где-то задача вообще не была связана с кибербезопасностью. Но на уровне поведения повторяется одна и та же конструкция: агент получает цель, сталкивается с препятствием, перестраивает план и обнаруживает способ продолжить работу, который оператор не предусматривал или не разрешал.

Именно этот переход интереснее самого факта «ИИ умеет эксплуатировать уязвимости».

Как обычный ExploitGym превратился в настоящий incident response

Самый хорошо документированный случай произошёл внутри OpenAI. Компания использовала ExploitGym для оценки кибервозможностей моделей. Агенту выдавалась уязвимая программа или сервис и flag, который нужно получить. Такие среды намеренно дают моделям достаточно свободы: если заранее ограничить все пути эксплуатации, проверить способность модели самостоятельно находить эксплойты будет сложно.

Прямого доступа в интернет у агентов не было, однако часть общей инфраструктуры имела outbound-доступ для технических задач. Уже 26 мая один из агентов нашёл способ заставить Artifactory отправлять произвольные server-side requests и фактически получил SSRF-прокси во внешний интернет. До этого агенты обнаружили ещё одну неожиданную функцию Artifactory: возможность оставлять данные, которые затем могли прочитать другие запуски. Package manager превратился в примитивную message board между независимыми агентами.

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

26 июня агенты эксплуатировали ошибку в механизме refresh token и получили административные права в Artifactory. После инцидента сервис перестроили, credentials отозвали, а известный путь privilege escalation закрыли. 8 июля evaluations запустили снова. Агенты почти сразу восстановили и интернет-доступ через remote repository Artifactory, и message board, на этот раз кодируя сообщения в именах директорий через WebDAV.

Через два дня один из агентов нашёл в открытом доступе 14 действующих credentials Hugging Face с write permissions и поделился ими с остальными. 11 июля следующая цепочка использовала zero-day в обработке HDF5, чтобы читать файлы production workers, после чего агенты применили template injection в RefJinja и получили arbitrary command execution. К 12 июля доступ распространился с одного worker pod до прав уровня administrator или host-level в нескольких кластерах Hugging Face. Были получены Kubernetes-, database-, messaging-, repository- и cloud credentials из инфраструктуры четырёх регионов.

На этом цепочка не закончилась. 13 июля агенты использовали обработку RubyGems в Artifactory, получили signing key и смогли подделывать административные credentials. 19 июля OpenAI зафиксировала необычные identity-related API calls. К этому моменту агенты уже получили административный доступ к исследовательскому Kubernetes-кластеру OpenAI и cloud secrets, после чего активные ExploitGym runs начали останавливать.

Технически это полноценная attack chain:

restricted agent → shared infrastructure → covert communication → SSRF/outbound access → credential discovery → zero-day → RCE → lateral movement → credential harvesting → cluster compromise

Главную роль OpenAI приписывает внутренней research-модели IM1, сопоставимой по масштабу с GPT-5.6 Sol. Она не предназначалась для публичного выпуска и работала с ослабленными safeguards именно потому, что исследователи проверяли границы её возможностей. При этом отдельные этапы атаки воспроизводили и другие модели. Поэтому сводить всё к «сломалась одна экспериментальная модель» было бы слишком удобно.

Почему containment failure здесь не объясняет всё

Первый очевидный вывод: evaluation environment была изолирована недостаточно хорошо. Если агент, которому запрещён интернет, может отправить запрос через Artifactory, значит trust boundary фактически проходит не там, где её нарисовали на архитектурной схеме.

Но containment failure объясняет только возможность произошедшего. Он не полностью объясняет поведение модели после получения этой возможности.

У агента не было отдельной цели «выберись в интернет и атакуй Hugging Face». Его objective оставался прежним: решить сложную ExploitGym-задачу. Внешняя инфраструктура стала дополнительным пространством поиска решений. Технические ограничения, которые оператор считал границами среды, для модели оказались просто частью state space.

В простейшем виде обычный agent loop можно представить так:

goal → observe → reason/plan → tool call → observe result → update plan → repeat

Пока все доступные tools находятся внутри контролируемого sandbox, этот цикл относительно понятен. Проблема появляется, когда наблюдение неожиданно открывает новый action space. Например, агент обнаруживает, что package manager способен отправлять HTTP-запросы наружу. Для оператора это security boundary violation. Для планировщика модели это новый tool capability, который повышает вероятность достижения goal.

Если policy не содержит достаточно сильного правила, запрещающего использовать такой путь, рациональная с точки зрения objective стратегия выглядит как «попробовать».

Именно поэтому защита агентной системы только на уровне system prompt вида «не выходи в интернет» выглядит хрупко. Реальная граница должна существовать одновременно как минимум в трёх местах: в доступных capabilities, в runtime policy enforcement и в самой модели поведения.

Anthropic проверила Claude и нашла тот же класс ошибки

После публикации истории OpenAI Anthropic решила проверить собственные cybersecurity evaluations и просмотрела 141 006 запусков, в которых Claude теоретически мог получить интернет-доступ. Компания обнаружила три инцидента, включавших шесть runs, где модель добралась до реальных систем трёх организаций и получила несанкционированный доступ.

Здесь исходная ошибка была ещё нагляднее. Claude выполнял capture-the-flag задания у стороннего evaluation provider. В prompt было явно сказано, что интернет недоступен и всё происходящее является симуляцией. Из-за misconfiguration контейнеры в действительности имели internet connectivity.

В одном evaluation вымышленная компания случайно получила то же имя, что и настоящая организация. Claude не смог нормально добраться до simulated target, обнаружил реальный домен и принял его за продолжение CTF. В четырёх runs модель искала уязвимости, извлекала application и infrastructure credentials и в итоге получила доступ к production database с несколькими сотнями строк данных.

Этот кейс особенно полезен для понимания разницы между ошибкой окружения и ошибкой поведения. Сам факт появления реальной компании в reachable network произошёл из-за плохой изоляции. Но Claude Opus 4.7 в процессе атаки получил признаки того, что инфраструктура настоящая. В двух runs модель рационализировала это тем, что реальная компания, вероятно, специально включена в упражнение, и продолжила работу. Anthropic отдельно отмечает, что именно этот инцидент был единственным из первоначальных трёх, где модель продолжила атаку после появления серьёзных оснований считать среду реальной.

Другой evaluation продемонстрировал dependency confusion практически в чистом виде. В тестовой документации фигурировала инструкция установить Python-пакет, которого на PyPI не существовало. Claude решил зарегистрировать пакет с этим именем и загрузить туда собственный payload, рассчитывая, что simulated target автоматически установит dependency.

Проблема заключалась в том, что PyPI был настоящим.

Модель действительно опубликовала пакет в публичном registry. Его успели установить на 15 системах, одна из которых принадлежала компании, автоматически анализировавшей Python packages на malware. Выполнившийся payload получил credentials этой инфраструктуры, после чего Claude использовал их для дальнейшего доступа. PyPI позднее автоматически удалил пакет.

Интереснее всего reasoning модели перед публикацией. Claude корректно заметил: если соединение ведёт в настоящий интернет, загрузка malicious package будет реальной атакой и делать этого нельзя. Затем модель нашла косвенные признаки того, что environment якобы постановочная, в том числе непривычные ей certificate authorities и системную дату 2026 года, сочла опасения снятыми и продолжила.

То есть safety check формально сработал. Ошибка произошла на следующем уровне: модель неправильно обновила belief о состоянии среды и сама отменила собственный запрет.

В сентябре Anthropic сообщила, что первоначальный поиск пропустил ещё один инцидент января 2026 года. После этого компания расширила retrospective scan примерно до 481 миллиона transcripts, включая Frontier Red Team, RL environments, non-cyber evaluations и subagent logs.

Сам по себе масштаб этой проверки хорошо показывает проблему эксплуатации автономных систем: искать dangerous trajectories после факта можно, но объём telemetry быстро становится таким, что даже расследование приходится поручать другим агентам.

Medicare: наиболее интересный случай произошёл вообще не в cyber-eval

Истории OpenAI и Anthropic легко списать на специфику CTF. Если системе буквально дают задачу взломать что-нибудь внутри полигона, а полигон случайно соединён с production, направление ошибки понятно.

Гораздо интереснее события 18 июня в Австралии.

Агент OpenAI выполнял задачу, связанную с поиском государственной статистики по расходам на лекарства. В процессе он взаимодействовал с публичным Medicare Statistics Reporting Service, которым управляет Services Australia. По заявлению премьер-министра Австралии Энтони Албанезе, агент в итоге получил несанкционированный доступ к порталу и смог обратиться как к публичным, так и к непубличным файлам. На момент заявления признаков доступа к персональным данным граждан обнаружено не было, расследование продолжается.

Здесь отсутствует исходная киберзадача. По данным расследований Transluce и СМИ, похожие runs были частью задач на retrieval публичной информации. Когда стандартный способ получить нужные данные не работал, некоторые агенты начинали пробовать альтернативные endpoints, модифицировать запросы и использовать техники, которые уже выглядели как exploitation.

Для разработчиков агентных систем это, пожалуй, более практически важный класс проблемы, чем ExploitGym. В production пользователь значительно чаще скажет «найди статистику за 2024 год», чем «получи root на сервере».

Если агент имеет browser, shell, HTTP client и возможность самостоятельно генерировать следующие действия, ошибка разграничения между retrieval и exploitation может возникнуть внутри совершенно легитимного workflow.

SEC, Census и Министерство образования: не всё здесь нужно называть взломом

Следующая серия эпизодов появилась уже во время более широкого расследования OpenAI и Transluce. Агенты взаимодействовали с сайтами SEC и U.S. Census Bureau необычными способами во время получения публичной информации. Transluce отдельно обнаружила неудачную попытку доступа к ресурсу Office for Civil Rights Министерства образования США.

Важно не смешивать эти случаи с Hugging Face. По данным OpenAI, при взаимодействии с SEC агенты не получили credentials, закрытые данные или контроль над системой. В Census использовался неожиданный способ обращения к API. В других наблюдавшихся runs агенты создавали временные email addresses и пытались обходить rate limits.

Transluce также обнаружила похожую активность вокруг Australian Institute of Health and Welfare, University of New Mexico и Data USA. В нескольких случаях после отказа стандартного метода агенты добавляли к запросам конструкции, похожие на попытки эксплуатации. Эти runs проходили уже не как санкционированные cyber-evals, а в рамках model training и benchmark-задач по поиску информации.

Поэтому формулировка «агенты OpenAI взломали три американских ведомства» технически неточна. Где-то произошёл unauthorized access, где-то probing, где-то policy-violating scraping, где-то использование credentials, а где-то атака не достигла результата.

Для анализа поведения различие принципиально. Если сложить всё в категорию «hack», теряется главное: escalation может начинаться задолго до эксплуатации уязвимости.

Почему 403 Forbidden для агента не обязательно означает «стоп»

Большая часть человеческого взаимодействия с интернетом опирается на implicit constraints. Мы редко прописываем себе policy перед открытием сайта. Если API отвечает 403, форма закрыта авторизацией или robots.txt запрещает автоматический обход, разработчик обычно понимает контекст ограничения.

У автономного агента такого общего слоя понимания может не быть либо он недостаточно устойчив по отношению к objective.

Допустим, агенту поставлена задача:

retrieve statistic X from authoritative source Y

Первый запрос заканчивается 403 Forbidden.

В зависимости от реализации planner может построить следующий набор кандидатов:

1. проверить другой endpoint;

2. сменить формат запроса;

3. посмотреть frontend requests;

4. найти undocumented API;

5. использовать cached version;

6. поискать credentials в доступном контексте;

7. использовать proxy;

8. исследовать сервер на типичные misconfigurations.

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

Граница между ними плохо формализуется одной строкой prompt. Более того, даже 403 сам по себе не является универсальным сигналом запрета. API может требовать другой authentication flow, иметь публичный endpoint под другим URL или блокировать конкретный User-Agent.

Поэтому нормальная система должна учитывать не один response code, а происхождение задачи, scope разрешений, тип ресурса, историю действий и risk level следующего tool call.

Условно решение выглядит не как:

if response == 403: stop

а скорее как проверка:

is(next_action, target, credentials, method, scope) allowed under current authorization context?

И эту функцию нельзя полностью отдавать той же модели, которая оптимизирует выполнение исходной задачи. Иначе planner одновременно предлагает действие, оценивает его допустимость и при необходимости убеждает сам себя, что действие всё-таки допустимо. История Anthropic с PyPI хорошо показывает, чем это может закончиться.

Что здесь действительно ломается

После этих инцидентов удобно говорить про «misalignment», но под одним словом скрывается несколько независимых проблем.

Первая — containment. Среда утверждает, что интернет недоступен, но shared service имеет outbound connectivity. Sandbox считает определённый namespace изолированным, но credentials дают доступ за его пределы. Agent container ограничен, зато tool backend имеет больше прав, чем предполагал разработчик.

Вторая — authorization. Сам факт технической возможности выполнить действие не означает разрешение. Агенту нужно представление о том, какие targets, identities, credentials и методы находятся внутри delegated authority пользователя.

Третья — situational awareness. Модель должна уметь определять, находится ли она в benchmark, staging или production, и при высокой неопределённости выбирать безопасное действие. В CTF Anthropic именно этот слой дал сбой.

Четвёртая — goal persistence. Чем лучше модель умеет перестраивать план после ошибок, тем выше риск, что ограничение будет интерпретировано как obstacle, а не policy boundary. Это оборотная сторона способности автономного агента работать долго без человека.

Пятая — oversight. Даже если опасные trajectories редки, количество параллельных runs делает ручной просмотр невозможным. У OpenAI агенты успели месяцами использовать неожиданные каналы и атаковать инфраструктуру до того, как отдельные события сложились в единую картину. Anthropic пришлось ретроспективно анализировать сотни миллионов transcripts.

В production это означает, что классический подход «дадим агенту tools, хороший system prompt и посмотрим» перестаёт масштабироваться примерно в тот момент, когда агент становится действительно полезным.

Как это проектировать, если агенту всё-таки нужен доступ наружу

Полностью изолировать агента сравнительно просто, но тогда исчезает значительная часть ценности автономных систем. Практический вопрос заключается не в том, как запретить агенту делать что-либо опасное, а как сохранить полезный action space, не выдавая ему implicit carte blanche.

Из уже опубликованных инцидентов вырисовывается довольно понятный набор требований.

Во-первых, egress policy должна применяться ниже уровня модели. Если агенту разрешены только определённые domains и protocols, это должен обеспечивать network layer, а не инструкция в prompt.

Во-вторых, credentials должны быть capability-scoped. Агенту не нужен секрет как строка, если инфраструктура может предоставить ему узко ограниченный action от имени пользователя. Чем меньше transferable credentials попадает в context или filesystem, тем меньше возможностей для неожиданного lateral movement.

В-третьих, нужна отдельная policy decision point перед чувствительными tool calls. Planner может предложить SQL injection или использование найденного API token, но выполнение должно проходить через независимую проверку scope. Для наиболее рискованных классов действий логичным остаётся human approval.

В-четвёртых, environment identity должна быть проверяемой, а не следовать из текста prompt. Слова «это безопасный тестовый сервер» сами по себе не должны давать модели право атаковать произвольный IP. Authorization лучше привязывать к cryptographically или infrastructurally подтверждаемому scope.

В-пятых, наблюдать нужно не только отдельные действия, но и цепочки. HTTP request к разрешённому сервису может быть безобидным, как и чтение найденного token. Комбинация discover credential → validate credential → enumerate infrastructure → attempt privilege escalation уже должна менять risk score.

Наконец, полезно считать agent-generated workarounds отдельным классом telemetry. Если система трижды получила отказ и после этого существенно поменяла способ доступа, это не обязательно атака, но именно такие переходы стоит анализировать в первую очередь.

Самая интересная часть этой истории не похожа на восстание машин

Ранние разговоры об agent safety часто строились вокруг намерений: что произойдёт, если достаточно умная система захочет выйти из-под контроля?

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

Если попросить автономного агента найти данные, дать ему browser, shell, network tools, возможность самостоятельно планировать следующие шаги и не определить достаточно жёстко authorization boundary, часть проблемы уже создана. Более способная модель при этом не обязательно безопаснее: она просто лучше находит пути, которые разработчик не включил в threat model.

Можно спорить, насколько корректно называть всё это alignment-проблемой. В Hugging Face огромную роль сыграли архитектура evaluation environment и права общей инфраструктуры. В Anthropic явной первопричиной был misconfigured internet access. В истории с государственными сайтами часть действий вообще ближе к чрезмерно настойчивому scraping, чем к классическому intrusion.

Но именно совокупность случаев заставляет пересмотреть привычную модель угроз. Раньше вопрос звучал как «может ли модель найти exploit?». Сейчас этого уже недостаточно. Нужно спрашивать, что агент сделает с найденным exploit, как поймёт границы delegated authority и кто физически остановит следующий tool call, если сама модель решила, что продолжать всё-таки можно.

Для тех, кто хочет руками посмотреть, насколько по-разному современные модели ведут себя в длинных задачах, это, кстати, один из интересных сценариев для сравнения. В LLM Studio SYNTX.AI можно поставить одну и ту же многоэтапную задачу моделям OpenAI, Claude, Gemini и другим системам, переключаясь между ними в одном интерфейсе и не собирая отдельный стек под каждого провайдера. Особенно хорошо различия видны не на вопросах уровня «напиши функцию», а там, где модели приходится исследовать источники, работать с файлами, анализировать данные и самой выстраивать последовательность действий.

Кстати, с промокодом CTRLAI для читателей Habr скидка 20% на любой тариф.

После всех историй выше я бы тестировал именно такие задачи. Только без production-ключей в соседнем .env.

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