Відділ виявлення та реагування кінцевих точок витратив два десятиліття на те, щоб відповісти на одне запитання: чи робить цей процес те, що робив би шкідливий код? Він перевіряє підписи, спостерігає за аномальною поведінкою та позначає несанкціоноване підвищення привілеїв. Агент штучного інтелекту, який має доступ до інструментів, порушує передумови цього питання, не будучи шкідливим кодом, а будучи довіреною програмою, яку можна вмовити зловживати її власним, цілком законним доступом.
Версія цієї проблеми до ШІ вже має назву
Використання легітимної підписаної програми для здійснення шкідливих дій не є новим. MITRE ATT&CK каталогізує це як Виконання системного двійкового проксі (T1218): «двійкові файли, підписані довіреними цифровими сертифікатами, зазвичай можуть виконуватися в системах Windows, захищених перевіркою цифрового підпису», саме тому білий список і перевірка підпису є проблемою, коли сам довірений двійковий файл виконує роль. Агент штучного інтелекту поширює ту саму слабкість на програму, яка взагалі не потребує попереднього завантаження шкідливого коду: її можна перенаправляти під час виконання за текстом, який вона читає.
Викрадений агент - розгублений депутат
Застосовним терміном тут є заплутаний депутат проблема: «комп’ютерна програма, яку інша програма (з меншими привілеями чи правами) обманом змусила зловживати своїми повноваженнями». Дайте агенту реальні інструменти, а потім дозвольте йому читати вміст, який ви не перевіряли, і він зможе навчатися за цим вмістом. Це саме той шаблон, який описує Запис швидкої ін’єкції OWASP, і він уже був продемонстрований, а не лише теоретизований: Invariant Labs Звіт від 26 травня 2025 р показала агента кодування, який читає звичайну на вигляд проблему GitHub у загальнодоступному сховищі, дотримуючись прихованих інструкцій у ньому, щоб відкрити дані приватного сховища, використовуючи інструменти, які йому були законно надані. Власний висновок дослідників: «Це не недолік самого коду сервера 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.Це фактична сліпа пляма: не прогалина в якомусь одному продукті, а той факт, що запис у журналі «агент виконував свою звичайну роботу» та «агент був викрадений для неправильного використання його звичайної роботи» може бути ідентичним на рівні процесу. Нічого про двійковий файл не змінилося. У шаблоні системного виклику немає нічого нового. Змінився лише намір запиту, а намір не є полем у журналі процесу.
Що насправді зменшує це, а що ні
Варто бути точним щодо того, що насправді рекомендує людина, яка назвала цей шаблон. Саймон Віллісон, який описав «смертельна трифекта» доступ до приватних даних, викриття ненадійного вмісту та зовнішній зв’язок разом в одному агенті, чітко каже, що уникнення цієї комбінації є справжнім виправленням, а не додатковим огородженням: «єдиний спосіб залишатися в безпеці — повністю уникнути цієї смертоносної комбінації trifecta». Він відверто скептично ставиться до продуктів, які стверджують, що надійно вловлюють введені інструкції постфактум, зазначаючи, що «ми все ще не знаємо, як на 100 відсотків надійно запобігти цьому», і що 95-відсотковий показник уловлювання є «дуже поганою оцінкою» для контролю безпеки.
- Спершу розробка: надайте агенту найвужчі інструменти та доступ до даних, необхідні для його завдання, щоб успішне впровадження було менше для зловживань (архітектурне виправлення, на яке вказують Willison і Invariant Labs).
- В принципі, кожного разу розглядайте будь-який вміст, який читає агент і який ви не писали чи перевіряли, проблеми, отримані сторінки, завантажені файли, як ненадійні дані.
- Там, де дизайну та перевірки недостатньо, єдиний крок, який не можна пропустити при спробі викрадання даних, — це підключення до мережі. Спостереження або обмеження цього процесу не запобігає обману агента, але це справжній незалежний рівень, який не залежить від розпізнавання введеної інструкції.
Яке місце тут посідають 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.