Endpoint Detection and Response (EDR) два десятилетия неплохо отвечает на один вопрос: делает ли этот процесс то, что сделал бы опасный код? Он проверяет подписи, следит за аномальным поведением и отмечает несанкционированное повышение привилегий. ИИ-агент с доступом к инструментам ломает саму предпосылку этого вопроса — не потому, что сам является опасным кодом, а потому, что является доверенной программой, которую можно убедить злоупотребить своим собственным, полностью законным доступом.
У этой проблемы уже есть имя — и оно появилось задолго до ИИ
Использование легитимной, подписанной программы для чего-то злонамеренного — не новость. MITRE ATT&CK каталогизирует это как System Binary Proxy Execution (T1218): «бинарные файлы, подписанные доверенными цифровыми сертификатами, как правило, могут выполняться в системах Windows, защищённых проверкой цифровой подписи», — именно поэтому белые списки и проверка подписей пасуют, как только действующим лицом оказывается сам доверенный бинарный файл. ИИ-агент распространяет ту же слабость на программу, в которую вообще не нужно заранее закладывать опасный код: её можно перенаправить прямо во время работы — текстом, который она прочитает.
Перехваченный агент — это «сбитый с толку представитель»
Здесь применим термин «проблема сбитого с толку представителя» (confused deputy problem): «компьютерная программа, которую другая программа (с меньшими привилегиями или правами) обманом заставляет злоупотребить своими полномочиями». Дайте агенту реальные инструменты, позвольте ему читать контент, который вы не проверяли, — и этот контент сможет им командовать. Именно этот паттерн описывает статья OWASP о внедрении инструкций, и он уже не просто теория, а продемонстрированный факт: в отчёте Invariant Labs от 26 мая 2025 года агент для написания кода, читая обычный на вид GitHub issue в публичном репозитории, следовал скрытым в нём инструкциям, чтобы раскрыть данные из приватного репозитория, используя инструменты, которые ему были предоставлены на законных основаниях. Собственный вывод исследователей: «это не изъян в самом коде GitHub MCP-сервера, а фундаментальная архитектурная проблема, которую нужно решать на уровне агентной системы».
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling
# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.В этом и есть настоящее слепое пятно: не пробел в каком-то одном продукте, а то, что запись в логе для «агент выполнил свою обычную работу» и для «агента перехватили, чтобы он злоупотребил своей обычной работой» может быть идентичной на уровне процесса. В бинарном файле ничего не изменилось. В паттерне системных вызовов нет ничего нового. Изменилось только намерение за запросом, а намерение — не поле в логе процесса.
Что реально снижает этот риск, а что нет
Стоит точно передать, что на самом деле рекомендует человек, давший имя этому паттерну. Саймон Уиллисон, описавший «смертельную триаду» — одновременное наличие у одного агента доступа к приватным данным, контакта с недоверенным контентом и возможности внешней связи, — прямо говорит, что реальное решение состоит в том, чтобы избегать этого сочетания, а не в дополнительной защитной надстройке: «единственный способ оставаться в безопасности здесь — полностью избегать этой смертельной триады». Он открыто скептичен в отношении продуктов, заявляющих, что надёжно ловят внедрённые инструкции постфактум, отмечая, что «мы всё ещё не знаем, как со стопроцентной надёжностью это предотвратить», и что показатель улавливания в 95 процентов — «это откровенно неудовлетворительная оценка» для средства защиты.
- Сначала — архитектура: давайте агенту только самые узкие инструменты и доступ к данным, необходимые для его задачи, чтобы успешному внедрению инструкций было меньше чем злоупотреблять (именно на это архитектурное решение указывают и Уиллисон, и Invariant Labs).
- Относитесь к любому контенту, который агент читает и который вы сами не написали и не проверили — issue, загруженные страницы, скачанные файлы, — как к недоверенному вводу, принципиально и каждый раз.
- Там, где архитектуры и проверки недостаточно, единственный шаг, который попытка утечки данных не может обойти, — это исходящее сетевое соединение. Наблюдение за ним или его ограничение, для каждого процесса отдельно, не мешает обмануть агента, но это реальный, независимый уровень защиты, который не зависит от того, удалось ли вообще распознать внедрённую инструкцию.
Какое место здесь занимают FireAI и HisnLabs
No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.
FireAI — это собственный продукт HisnLabs: ИИ-файрвол, работающий прямо на вашем Mac. Он показывает простым языком каждое соединение, которое устанавливают ваши приложения, и позволяет вам решать, что покидает ваш Mac, — его ИИ работает локально, поэтому ваш трафик никогда не отправляется ни нам, ни кому-либо ещё. Команда исследователей безопасности HisnLabs — это те, кто поддерживает точность этих решений: они каталогизируют, какие домены являются обычной телеметрией, а какие — реальным сервисом, отслеживают страну и сеть, стоящие за соединением, и обучают локальную модель (функцию Autopilot) на реальных шаблонах трафика — и ничего из этого не покидает ваш Mac.
Вы можете прочитать о технических решениях, лежащих в его основе, или попробовать FireAI в течение 17 дней на странице FireAI от HisnLabs.