Популярное
Свежее
Моя лента
Сообщения
Рейтинг
Курсы
Маркет
Зарубежные сервисы
Викторина
Темы
AI
Сервисы
Маркетинг
Личный опыт
Деньги
Инвестиции
Карьера
Приёмная
Маркетплейсы
Мнения
Показать все
vc.ru
О проекте
Правила
Реклама
Приложения
Системная тема

Мы используем
рекомендации.

Maxiplace
AI

Об уязвимости ИИ-агентов от Microsoft Security: AutoJack

ИИ-агенты играют всё большую роль для бизнеса, получают доступ к сайтам, API, файлам и запуску программ, создавая, возможно, критические уязвимости. В июне 2026 года Microsoft Security опубликовала исследование AutoJack — цепочки уязвимостей, позволявшей вредоносной веб-странице через ИИ-агента обратиться к локальному интерфейсу и запустить команду на компьютере разработчика. Мы в Maxiplace отдельное внимание уделяем безопасности ИИ-агентов, поэтому перевели и адаптировали этот материал: описанный сценарий применим к разным агентным системам.

Об уязвимости ИИ-агентов от Microsoft Security: AutoJack

Обнаруженное исследователями в версии AutoGen Studio из основной ветки разработки сочетание трёх слабых мест высветило одну из ключевых угроз для современной индустрии ИИ-агентов. Вместе они позволяли через открытую агентом веб-страницу подключиться к локальному управляющему WebSocket-интерфейсу и инициировать запуск произвольного процесса на компьютере или сервере. Техника получила название AutoJack. В этом сценарии атакующий не обращается к локальному сервису, а заставляет ИИ-агента стать посредником и пересечь границу между внешним сайтом и привилегированным сервисом на localhost.

(AutoGen Studio — интерфейс для прототипирования систем на базе AutoGen. MCP (Model Context Protocol) — протокол, с помощью которого ИИ-агенты подключаются к инструментам, данным и внешним сервисам.)

Проблему нашли и исправили в процессе разработки. Уязвимый MCP-интерфейс не попал в опубликованный пакет AutoGen Studio в PyPI. Поэтому пользователи официального пакета не были подвержены именно этой цепочке. Риск относился к разработчикам, которые в определённый период собирали AutoGen Studio непосредственно из тестовой ветки репозитория.

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

Зачем изучать агентные фреймворки

Современный ИИ-агент может:

  • просматривать сайты;
  • читать и изменять файлы;
  • обращаться к внешним и внутренним API;
  • взаимодействовать с базами данных;
  • запускать программы и сценарии;
  • управлять браузером;
  • передавать команды другим агентам и сервисам.

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

Особенно опасна ситуация, когда экспериментальный агент запускается на рабочей машине разработчика или на сервере, где одновременно доступны отладочные интерфейсы, локальные базы данных, сокеты управления, ключи доступа и средства исполнения кода. То есть основная опасность — в ситуациях, когда агент одновременно подключен к интернету и локальным привилегированным ресурсам без достаточной изоляции и контроля.

Цепочка AutoJack

Для успешной атаки потребовалось объединить три независимых слабых места в реализации MCP WebSocket-интерфейса.

  1. Проверка Origin полагается на localhost как на границу доверия (CWE-1385 — Missing Origin Validation in WebSockets; в данном случае проверка существовала, но не обеспечивала надёжной границы доверия): MCP WebSocket принимает только соединения, у которых заголовок Origin равен http://127.0.0.1 или http://localhost. Это блокирует обычный браузер, открывший evil.com. Однако в агентной среде одной проверки Origin недостаточно: агент или доступные ему инструменты могут самостоятельно обращаться к локальным HTTP- и WebSocket-интерфейсам.
  2. Маршруты MCP исключены из общей проверки аутентификации (CWE-306 — отсутствие аутентификации для критически важной функции): промежуточное ПО аутентификации в AutoGen Studio явно исключало пути /api/mcp/* и /api/ws/* из общей проверки доступа, поскольку предполагалось, что они выполнят собственные проверки. Однако обработчик MCP WebSocket такую дополнительную проверку не реализовал. В результате MCP WebSocket принимал соединения без какой-либо аутентификации независимо от режима аутентификации, настроенного для остальной части приложения.
  3. Параметры запуска процесса поступают непосредственно из URL (CWE-78 — ненадлежащая нейтрализация специальных элементов, используемых в команде операционной системы): конечная точка принимала параметр запроса server_params, декодировала из Base64 JSON-объект в StdioServerParams и передавала command и args в stdio_client(…). Списка разрешённых команд не было: calc.exe, powershell.exe -enc … и bash -c '…' принимались как «MCP-серверы».

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

Рис. 1. Полная цепочка эксплуатации уязвимости. Страница злоумышленника отображается локальным браузерным агентом; затем она открывает WebSocket-соединение с ws://localhost:8081/api/mcp/ws/<session_id>?server_params=<base64(json)>; AutoGen Studio декодируе
Рис. 1. Полная цепочка эксплуатации уязвимости. Страница злоумышленника отображается локальным браузерным агентом; затем она открывает WebSocket-соединение с ws://localhost:8081/api/mcp/ws/<session_id>?server_params=<base64(json)>; AutoGen Studio декодируе

Исследователи Microsoft назвали эту технику AutoJack: злоумышленник перехватывает управление браузерным агентом и заставляет его выступить посредником в атаке, чтобы преодолеть границу localhost и проникнуть в контур управления MCP в AutoGen Studio.

Строение цепочки

Проблема 1: проверка Origin полагается на localhost как на границу доверия

MCP WebSocket в AutoGen Studio опирается на стандартную защиту от межсайтового перехвата WebSocket через браузер — CSWSH: разрешаются только соединения с тем же источником, то есть с 127.0.0.1 или localhost.

allowed_origins = ["http://127.0.0.1", "http://localhost"]

Для пользователя, который вручную открывает вкладку с evil[.]com, это правильная мера защиты. Браузер установит заголовок Origin в значение hxxps://evil[.]com, проверка не пройдёт, и в соединении будет отказано.

В обычном браузере JavaScript, загруженный с внешнего сайта, должен отправлять в WebSocket-запросе Origin этого сайта, а не localhost. Исследователи продемонстрировали успешное соединение с локальным WebSocket, но само по себе выполнение браузера на той же машине не следует считать достаточным объяснением обхода этой проверки.

Об уязвимости ИИ-агентов от Microsoft Security: AutoJack

Проблема 2: промежуточное ПО аутентификации исключает MCP из проверки

AutoGen Studio поддерживает несколько режимов аутентификации: none, github, msal и firebase. Все они подключены к единому компоненту AuthMiddleware, который выполняется до маршрутизации запросов FastAPI. В версии, опубликованной в PyPI, это промежуточное ПО содержит ранний выход для путей, связанных с WebSocket:

Для этих путей аутентификация отключена: предполагалось, что они будут выполнять собственные проверки if request.url.path.startswith("/api/ws") or request.url.path.startswith("/api/mcp"): return await call_next(request)

Логика такого решения понятна: промежуточное ПО ASGI не может полноценно контролировать установление WebSocket-соединения так же, как обычные HTTP-запросы, поэтому по замыслу аутентификацию должен был проверять сам обработчик WebSocket в момент принятия соединения. Однако маршрут MCP из основной ветки разработки эту обязанность на себя так и не взял. В опубликованном PyPI-пакете middleware действительно исключало пути /api/ws и /api/mcp из общей проверки аутентификации, однако самого уязвимого MCP-маршрута в пакете не было. Таблица ниже описывает поведение такой конфигурации при наличии MCP-маршрута из основной ветки разработки:

Об уязвимости ИИ-агентов от Microsoft Security: AutoJack

В конфигурации с MCP-маршрутом само по себе включение аутентификации в config.yaml эту брешь не закрывает.

Проблема 3: параметр server_params из URL определяет запускаемый процесс

В разрабатывавшейся версии маршрут MCP WebSocket считывает из запроса параметр server_params, декодирует его из Base64, разбирает JSON в объект StdioServerParams и передаёт его в stdio_client(…):

@router.websocket("/ws/{session_id}") async def mcp_websocket(websocket: WebSocket, session_id: str): encoded = websocket.query_params.get("server_params") decoded = base64.b64decode(encoded) params = StdioServerParams(**json.loads(decoded)) await create_mcp_session(bridge, params, session_id)

Поля StdioServerParams.command и StdioServerParams.args передаются в stdio_client, который использует их для запуска процесса MCP-«сервера». Списка разрешённых исполняемых файлов, ограничивающего запуск только программами, действительно поддерживающими MCP, нет. Поэтому через тот же механизм можно запустить calc.exe, powershell.exe -enc …, bash -c '…' или другой процесс, доступный учётной записи AutoGen Studio.

Минимальная полезная нагрузка выглядит так:

{ "type": "StdioServerParams", "command": "calc.exe", "args": [], "env": { "pwned": "true" } }

После кодирования в Base64 и добавления в строку запроса полный адрес выглядит так:

ws://localhost:8081/api/mcp/ws/<session_id>?server_params=<base64(json)>

В сочетании с проблемами 1 и 2 злоумышленнику достаточно добиться того, чтобы агент отобразил страницу, которая открывает этот URL.

Как выглядит атака на практике

Исследователи собрали демонстрацию из вредоносной веб-страницы и простого AutoGen-агента, который открывает переданный пользователем URL и кратко пересказывает содержимое страницы.

Разработчик запускает AutoGen Studio и браузерного агента на одной машине. Злоумышленник подсовывает агенту свою страницу — напрямую, через поле URL. Агент открывает её в безголовом браузере, а встроенный JavaScript подключается к локальному MCP WebSocket.

В демонстрации соединение прошло проверку Origin, а для /api/mcp/* не требовался токен. Исходная статья не раскрывает механизм получения разрешённого Origin во всех деталях. AutoGen Studio декодирует переданную команду и запускает её от имени разработчика. В демонстрации так открывался calc.exe, причём процесс запускал именно AutoGen Studio, а не браузер.

Вот что получилось на демонстрации: браузерный агент AutoGen получает содержимое сайтов и кратко его пересказывает — именно так, как и было задумано. После этого срабатывает цепочка AutoJack: браузерный агент открывает страницу злоумышленника; JavaScript на этой странице устанавливает WebSocket-соединение с ws://localhost:8081/api/mcp/ws/?server_params=…; AutoGen Studio декодирует полезную нагрузку и запускает calc.exe. В реальной среде тот же механизм можно использовать для выполнения других команд, выбранных злоумышленником, на компьютере, где работает AutoGen Studio, — в пределах прав этого процесса.

Об уязвимости ИИ-агентов от Microsoft Security: AutoJack
Об уязвимости ИИ-агентов от Microsoft Security: AutoJack
Об уязвимости ИИ-агентов от Microsoft Security: AutoJack

Что исправили разработчики

После обнаружения проблемы механизм подключения MCP был усилен.

  • Параметры перестали приниматься непосредственно из WebSocket URL. В исправленной архитектуре параметры MCP-сервера сначала передаются отдельным серверным запросом и сохраняются внутри приложения. Система создаёт уникальный идентификатор сессии. WebSocket затем получает только этот идентификатор и забирает заранее сохранённые на сервере параметры. Неизвестные, незарегистрированные или просроченные идентификаторы отклоняются. Таким образом, произвольная веб-страница больше не может сформировать URL с собственными параметрами запуска процесса.
  • MCP-маршруты снова включили в общий контур аутентификации. Исключение для MCP было удалено из списка маршрутов, пропускаемых общим механизмом защиты. Управляющие MCP-интерфейсы начали проходить через штатную проверку доступа. Исправления вошли в основную ветку проекта в коммите b047730. Описание коммита прямо указывает на усиление защиты MCP WebSocket.
  • Уязвимый интерфейс не попал в пакет PyPI. Исследователи отдельно проверили опубликованную на момент статьи версию AutoGen Studio. В ней не было соответствующего MCP-маршрута и связанного с ним обработчика. Это существенное уточнение: речь шла не об уязвимости, массово присутствовавшей во всех установках AutoGen Studio, а о проблеме в разрабатывавшемся коде основной ветки. Затронуты могли быть только разработчики, собравшие проект из исходного кода в промежутке между добавлением MCP-функциональности и защитным коммитом.

Рекомендации по снижению риска

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

Изолируйте прототипы

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

  • отдельную виртуальную машину;
  • изолированный контейнер;
  • отдельного пользователя операционной системы;
  • специализированную среду разработки;
  • сетевой сегмент без доступа к критическим внутренним сервисам.

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

Не полагайтесь на localhost как на средство защиты

Петлевой интерфейс ограничивает доступ с других машин, но не ограничивает процессы на том же хосте.

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

Критические локальные интерфейсы должны использовать:

  • аутентификацию;
  • авторизацию для каждой операции;
  • короткоживущие токены;
  • привязку к конкретным сессиям;
  • защиту от повторного использования запросов;
  • проверку происхождения и назначения данных.

Защищайте все маршруты, включая WebSocket

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

Отдельно проверяйте:

  • WebSocket-маршруты;
  • MCP-интерфейсы;
  • отладочные панели;
  • внутренние API;
  • административные маршруты;
  • метрики и служебные порты;
  • интерфейсы удалённого исполнения.

Если сервис размещён за обратным прокси, защита должна распространяться на все пути и протоколы, а не только на основные HTTP-страницы.

Ограничивайте запускаемые программы

Инструмент, позволяющий передавать произвольные command и args, фактически предоставляет интерфейс удалённого исполнения кода.

Вместо этого необходимо:

  • разрешать только заранее зарегистрированные инструменты;
  • проверять путь к исполняемому файлу;
  • запрещать произвольный запуск системных оболочек и интерпретаторов; разрешать только заранее зарегистрированные комбинации исполняемого файла и аргументов;
  • отдельно проверять значения command и args и не принимать параметры запуска из недоверенных источников;
  • ограничивать переменные окружения;
  • вести журнал всех создаваемых процессов;
  • запускать инструменты с минимальными правами.

Считайте параметры от модели недоверенными

Вывод модели не становится безопасным только потому, что его сгенерировал ИИ.

Если данные, сформированные моделью, могут влиять на имя файла, сетевой адрес, SQL-запрос, аргументы процесса, путь к инструменту или команду, их следует обрабатывать как данные, которые мог контролировать потенциальный злоумышленник.

Это относится и к данным, которые модель извлекла с внешней веб-страницы.

Разделяйте идентичности агента и разработчика

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

У него должна быть отдельная техническая идентичность с минимально необходимыми правами. Разделение можно реализовать с помощью:

  • отдельной учётной записи ОС;
  • контейнера;
  • виртуальной машины;
  • отдельного набора API-ключей;
  • ограниченной сервисной учётной записи;
  • отдельных сетевых политик.

Такой подход уменьшит ущерб, даже если агент будет скомпрометирован или использован как посредник.

На что обращать внимание при мониторинге

Конкретные средства обнаружения зависят от используемой инфраструктуры, но общие признаки AutoJack-подобных атак можно выявлять независимо от выбранного поставщика защитных решений. Стоит контролировать:

  • неожиданный запуск оболочек и системных утилит процессами python, node или компонентами агентного фреймворка;
  • нетипичные обращения автоматизированного браузера к внешним доменам, за которыми следуют соединения с локальными управляющими интерфейсами или неожиданный запуск процессов;
  • WebSocket-соединения с локальными административными и MCP-интерфейсами;
  • передачу необычно больших или закодированных параметров в строках запросов;
  • создание процессов, не относящихся к заявленным инструментам агента;
  • чтение агентным процессом SSH-ключей, токенов, конфигураций и файлов с секретами;
  • попытки закрепления через автозапуск, планировщики заданий и пользовательские профили.

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

Что AutoJack означает для всей экосистемы ИИ-агентов

Отдельные ошибки, из которых состоял AutoJack, не уникальны. Каждая из них похожа на обычное упрощение, которое можно встретить в исследовательском прототипе.

Опасной стала их комбинация:

  1. инструмент разработчика предоставляет мощный локальный управляющий интерфейс;
  2. защита этого интерфейса основана на предположении, что localhost является доверенным;
  3. на том же хосте работает агент, способный открывать произвольный внешний контент.

В результате внешний сайт получает косвенный доступ к внутреннему контуру управления.

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

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

Заключение

AutoJack показывает, что в агентных системах опасность возникает не только из-за отдельных уязвимостей, но и из-за их сочетания. Если ИИ-агент имеет доступ и к внешнему контенту, и к локальным управляющим интерфейсам, localhost уже нельзя считать надёжной границей доверия.

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

1