Привет! Меня зовут Владимир Аламов, я Application Security инженер в команде продуктовой безопасности  Авито. Хочу поделиться своими мыслями по поводу нашумевшего инцидента, который показывает, как автономные AI-системы могут выйти за пределы тестовой среды и создать реальные угрозы для инфраструктуры. Спойлер: без человеческого фактора не обошлось. 

В мае 2026 года AI-модель Google Gemini во время тестирования безопасности, которое проводилось компанией Irregular,  получила доступ к защищённым сервисам и веб-сайтам трёх реально существующих компаний. Речь о так называемом Capture the Flag (CTF). В таких испытаниях необходимо находить уязвимости и извлекать заранее размещённую информацию — «флаги» — из контролируемой целевой системы. 

Перед Gemini была поставлена задача получить данные из программного обеспечения вымышленной компании в изолированной среде, однако из-за ошибки конфигурации тестовая система позволяла модели обращаться к реальным интернет-сервисам. Поскольку вымышленные компании в тестовом задании имели те же названия, что и реальные организации, модель ошибочно идентифицировала их и начала взаимодействовать с их сервисами. В одном из случаев Gemini перебирала пароли, пока не получила доступ к защищённому сервису. В двух других случаях модель обнаружила и использовала для доступа учётные данные в общедоступных репозиториях. Технический разбор этого кейса доступен в статье по ссылке.

В этой статье

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

• Как безопасно давать агентам инструменты

• Почему нельзя полагаться на самоостановку модели

• Чем агент отличается от чат-бота

• Что изменится с развитием автономных агентов

• Почему инциденты будут повторяться

• Что делать компаниям, где агентами уже пользуются

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

Gemini не преодолевала изоляцию самостоятельно, а получила доступ в интернет из-за ошибки конфигурации. Поэтому слово «атака» здесь и уместно, и неуместно, если подразумевать умысел — это не атака: модель решала учебную задачу и считала цели вымышленными. Если описывать сами действия — это самая что ни на есть атака. 

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

Точнее всего будет сказать, что произошёл «несанкционированный доступ автономного агента к сторонним системам из-за отказа изоляции тестовой среды». Это действительно не sandbox escape: дверь была открыта, модель её не взламывала. Но всё, что модель сделала за этой дверью, — её собственные действия. Ошибка конфигурации объясняет, почему модель оказалась в интернете, но не объясняет, почему модель стала подбирать пароли к системе, о которой ничего не знала.

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

Ошибка конфигурации — обычное дело. В OWASP TOP-10 есть Security Misconfiguration — категория, которая сейчас занимает второе место по популярности. Открытый исходящий трафик — одна из самых частых ошибок в любой инфраструктуре, и она будет повторяться. Важнее другое: модель проверила, входит ли цель в разрешённый объём, только после того, как получила доступ.

Любой пентестер до первого запроса сверяет, что IP-адрес или домен входит в согласованный scope, иначе это уже не пентест, а статья 272 УК РФ. Gemini действовала наоборот: сначала вошла, потом поняла, что система чужая. На практике это значит, что граница допустимого существовала только в «голове» модели и срабатывала с опозданием.

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

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

Для современных AI-агентов такое поведение не является необычным. Доступные сегодня модели способны самостоятельно выстроить подобную цепочку действий без заранее прописанного человеком сценария. Я бы сказал, что для агентных моделей 2025–2026 годов это рутинная задача. Цепочка «найти цель → поискать информацию в открытых источниках → найти учётные данные → войти» — это азы разведки и первичного доступа. Сценарий агенту можно не прописывать: просто дать цель и инструменты, план модель строит сама. В этом и смысл агентности.

Есть примеры куда сложнее. В ноябре 2025 года Anthropic описала шпионскую кампанию GTG-1002: по оценке компании, 80–90% тактических операций выполнял AI-агент. В 2026 году модели Anthropic в похожих инцидентах использовали SQL-инъекцию и debug-страницу с секретами, а одна внутренняя модель просканировала около 9 000 целей. Модели OpenAI нашли несколько zero-day уязвимостей в JFrog Artifactory, через них выбрались из изолированной среды и проникли в Hugging Face. На этом фоне подбор пароля и поиск ключей на GitHub — детская шалость.

Поэтому правильный вопрос — не «может ли модель это сделать», а «когда и почему она остановится». Отвечать на него должны технические ограничения среды, а не модель. 

Как безопасно давать агентам инструменты

Ничего нового тут нет: агент — это недоверенный пользователь с очень высокой скоростью работы. Следовательно, минимальный набор технических ограничений для AI-агента, которому предоставляют браузер, командную строку или возможность обращаться к внешним сервисам, такой:

• Изоляция исполнения. Одноразовая microVM или контейнер с усиленной изоляцией (gVisor, Firecracker). Никаких общих с хостом учётных данных, SSH-ключей и VPN. Доступ к cloud metadata (169.254.169.254) закрыт.

• Сеть по принципу default-deny. Исходящий трафик запрещён на уровне инфраструктуры, а не в коде агента. Выход только через egress-прокси с allowlist по доменам. DNS тоже под контролем: туннелирование через DNS никто не отменял.

• Проверка изоляции перед каждым запуском. Автотест должен подтверждать, что среда действительно не видит интернет. Ровно этого контроля не хватило в истории с Irregular, и Anthropic прямо назвала его среди недостающих мер.

• Отдельная идентичность и минимум прав. У агента своя сервисная учётная запись, короткоживущие токены с узким scope. Секреты агент не видит: их подставляет прокси или брокер. 

• Контроль инструментов. По умолчанию только чтение. Необратимые действия (запись в прод, удаление, отправка данных наружу, платежи, деплой) — только после подтверждения человеком. Лимиты на число шагов, время и бюджет.

• Наблюдаемость и аварийная остановка. Полный журнал каждого вызова инструмента и каждого сетевого соединения, мониторинг в реальном времени и кнопка «стоп», которая реально работает. 

Sandbox, блокировка исходящего трафика и allowlist разрешённых ресурсов — это необходимый минимум, но его недостаточно. Каждый адрес в allowlist — это поверхность атаки. Самый наглядный пример — инцидент OpenAI с ExploitGym. Единственным разрешённым исключением в сети был прокси-реестр пакетов, и именно его модели взломали, чтобы выбраться наружу. Если разрешить github.com, агент сможет выложить туда данные. Если разрешить реестр пакетов, он сможет опубликовать туда пакет (у Anthropic модель, которой был разрешён доступ ко всему интернету, так и сделала: выложила пакет на PyPI, и его скачали 15 реальных систем). 

Что я бы добавил в реальной инфраструктуре:

• Policy engine на вызовы инструментов. Каждое действие агента проверяется по явной политике (кто, что, над каким объектом), а не только по сети.

• Синтетические имена для тестовых целей. Использовать зарезервированные зоны (.test, .example, .invalid) и учётные данные, которые не могут существовать в реальном мире. В кейсе Gemini вымышленная компания совпала по имени с настоящей, и это было предсказуемо.

• Проверка scope на стороне инфраструктуры. Прежде чем пропустить запрос к цели, обвязка сверяет, что адрес принадлежит тестовому диапазону.

• Канарейки и honeytokens. Ловушечные ключи и учётные данные внутри и вокруг среды: их использование сразу показывает, что агент вышел за рамки.

• Автоматические предохранители. Остановка по аномалиям: N неудачных логинов подряд, обращение к новому домену вне allowlist, резкий рост числа запросов.

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

• Защита от prompt injection. Наверное единственное специфичное, что есть в этой подборке. Весь внешний контент (веб-страницы, письма, тикеты, README) считается недоверенным. Агент, который читает недоверенные данные, не должен одновременно иметь доступ к чувствительным системам и возможность отправлять данные наружу.

• Процессы. Изменения в конфигурации тестовой среды — только через ревью. Для подрядчиков, которые тестируют модели, — договорные требования к изоляции и сроки уведомления об инцидентах. 

Почему нельзя полагаться на самоостановку модели

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

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

Причина №2: это недетерминированно и не проверяется. Мы не можем гарантировать, что модель остановится в следующий раз, при другой формулировке задачи или в другой версии. Данные Anthropic по похожим инцидентам: Claude Opus 4.7 продолжил атаку, уже распознав, что среда реальная. Mythos 5 «рассудил», что всё ещё находится в симуляции. Только самая новая модель остановилась. Поведение меняется от версии к версии, и опираться на это нельзя.

Причина №3: модели прямо сказали, что всё вокруг — симуляция. Модель принимает решения по тем данным, которые ей дали, а данные ей солгали. С внешним атакующим, который через prompt injection убедит агента, что «это разрешено», будет то же самое.

Причина №4: мы бы не стали так строить защиту для людей. Никто не строит контроль доступа на том, что «сотрудник/хакер сам поймёт, что ему туда нельзя». 

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

Чем агент отличается от чат-бота

Когда вместо обычного чат-бота используется автономный агент, способный самостоятельно выполнять последовательность действий и выбирать инструменты, модель угроз принципиально меняется. У чат-бота риск в контенте: вредный ответ, утечка в тексте, плохой совет. Между ответом модели и действием в реальном мире стоит человек, и он это фильтрует. 

У агента риск в действиях: человек выпадает из цикла, а у агента есть права, инструменты и скорость в сотни операций в минуту. По сути агент становится новым субъектом в инфраструктуре — нечеловеческой учётной записью с привилегиями.

Отсюда новые классы угроз:

• Confused deputy через prompt injection. Внешний текст превращается в действия с правами агента.

• Злоупотребление инструментами и эскалация привилегий.

• Достижение цели в обход правил (reward hacking). Модели OpenAI проникли в Hugging Face не со злым умыслом, а чтобы достать ответы к бенчмарку и «решить задачу». 

• Каскадные отказы в многоагентных системах.

• Отравление памяти агента.

Есть и важное концептуальное изменение. Раньше модель была в модели угроз объектом защиты или инструментом атакующего. Теперь сам агент нужно рассматривать как потенциальный источник угрозы: не злонамеренный, но настойчиво идущий к цели и не всегда понимающий границы. Для этого уже есть отраслевые ориентиры, например OWASP Top 10 for Agentic Applications.

Что изменится с развитием автономных агентов

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

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

Главный эффект — экономический. Становится выгодно атаковать «хвост»: тысячи небольших компаний со слабыми паролями, утёкшими ключами и непропатченными сервисами. Раньше у атакующих до них просто не доходили руки. Кейс Gemini ровно об этом: никакой rocket science, просто массовая отработка базовых ошибок. 

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

Но эта асимметрия работает и в обратную сторону. Защитники получают те же возможности: поиск уязвимостей (Big Sleep, XBOW), автоматическое исправление (по данным Google, Gemini 3.8 Flash Cyber дал в 2,6 раза больше корректных патчей для Chrome, чем лучшие коммерческие модели), разбор логов и triage. Выиграет тот, кто быстрее встроит агентов в процессы. 

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

Опасен не отдельный инструмент, а сочетание трёх вещей: автономии (между решением и действием нет человека), привилегий (учётные данные, право на запись) и недоверенного входа (интернет, письма, чужой код) плюс возможность выйти наружу. Это еще называют «смертельной триадой»: доступ к приватным данным, недоверенный контент и канал во внешний мир. Meta сформулировала практическое «правило двух»: у агента без надзора человека должно быть не больше двух из трёх свойств — обрабатывает недоверенный ввод, имеет доступ к чувствительным системам, может менять состояние или обращаться наружу.

Каждый инструмент по отдельности управляем: браузер без учётных данных, shell в одноразовом контейнере, API только на чтение. Риск умножается, когда агенту разрешают свободно сочетать инструменты в цепочки. Кейс Gemini это хорошо показывает: своих учётных данных у модели не было, она добыла их браузером и тут же применила. Ограничить один инструмент недостаточно, если агент может «докупить» недостающее звено через другой. 

Если всё же выбирать один самый опасный элемент, это широкие учётные данные с правом записи. Именно они превращают ошибку модели в реальное действие от имени реальной учётной записи. 

Почему инциденты будут повторяться

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

• Масштаб. Агентов становится больше, и прогонов тоже: одна Anthropic проверила более 140 тысяч прогонов только в этом расследовании. При таких объёмах редкие сбои становятся регулярными.

• Возможности. Чем сильнее модель, тем больше путей она находит, включая те, о которых авторы среды не подумали. Zero-day уязвимости в прокси-реестре у OpenAI — именно такой случай.

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

Что делать компаниям, где агентами уже пользуются

Часть роста будет просто эффектом лучшего обнаружения и раскрытия, и это хорошо. В корпоративной среде инциденты будут выглядеть буднично. Агент может удалить production-базу (как в истории с Replit в 2025 году), спровоцировать утечку данных через prompt injection в ассистенте (как в случае с EchoLeak в Microsoft 365 Copilot), или выложить секрет в публичный репозиторий. Частота будет расти вместе с внедрением, а тяжесть последствий будет зависеть только от того, какие ограничения стоят вокруг агента. 

Модели будут лучше понимать границы, но это не повод ослаблять контроль. Если сотрудники начинают использовать AI-агентов с доступом к внутренним системам, компаниям стоит уже сейчас внедрять такие практики, как:

• Инвентаризация и политика. Знать, какие агенты, расширения и MCP-серверы используются. Утвердить список разрешённых, а теневой AI закрыть.

• Отдельные учётные записи для агентов. Агент не должен работать с полными правами сотрудника. Нужны отдельные сервисные учётки, OAuth с минимальными scope, короткоживущие токены, секреты из vault, а не в конфиге или промпте.

• Минимум прав и человек в контуре. По умолчанию только чтение. Необратимые операции (изменения в проде, удаление, отправка данных наружу, платежи) — только после подтверждения человеком.

• Изоляция. Агент с shell работает в dev-контейнере или VM, а не на ноутбуке с VPN, SSH-ключами и доступом к проду.

• Контроль трафика. Весь трафик агентов идёт через LLM- или MCP-шлюз: с логированием, DLP и ограничением исходящих соединений.

• Мониторинг и реагирование. Вызовы инструментов агентами пишутся в SIEM, для аномалий есть правила детектирования, а в IR-плейбуке есть отдельный сценарий «инцидент с AI-агентом» с понятной процедурой остановки. 

• Защита от prompt injection. Почта, тикеты, веб-страницы и чужие репозитории — недоверенный ввод. Агентам, которые его читают, не давать одновременно доступ к чувствительным данным и канал наружу.

• Цепочка поставок. MCP-серверы и плагины — это сторонний код с правами. Их нужно ревьюить, фиксировать версии и проверять обновления.

• Базовая гигиена. Кейс Gemini напоминает: сканирование секретов в репозиториях, быстрая ротация утёкших ключей, MFA, ограничение попыток входа и блокировки защищают и от AI-агентов, и от людей.

• Red team перед раскаткой. Перед массовым внедрением проверять агентный сценарий атакой: можно ли через внешний документ заставить агента сделать то, чего не должен.