Атака на ШІ Google: як хакери маніпулюють ботами через prompt injection

Нова загроза для ШІ-систем: що сталося в репозиторії Google

Фахівці з питань кібербезпеки зробили серйозне відкриття, яке переосмислює підходи до захисту автоматизованих систем. У популярному репозиторії Google ADK виявлена принципово нова категорія атак — спосіб, коли один ШІ-агент низького рівня привілей отримує можливість маніпулювати ботом із розширеними правами доступу. Це перший зафіксований випадок такого вектора загрози в історії розвитку систем штучного інтелекту. Відкриття сигналізує про масштабне розширення поверхні потенційних атак, з якими стикатимуться організації, що активно впроваджують ШІ-асистентів у свої робочі процеси.

Проблема демонструє, що одна лише ізоляція середовищ виконання більше не забезпечує достатнього рівня захисту. Управління безпекою розвитків вимагає кардинальної переоцінки всіх моделей запобігання загрозам. Керівники з інформаційної безпеки мають невідкладно переглянути свої системи контролю й впровадити нові механізми розмежування доступу.

Як працює атака через межу довіри

Ядро проблеми криється у неправильній ізоляції двох типів ШІ-агентів з різними рівнями прав, які спільно використовували одну межу довіри в системі. Механізм цієї вразливості можна розібрати за такою схемою:

Взаємодія публічного й внутрішнього ботів

• Публічний агент (низькі привілеї) — активується автоматично щоразу, коли користувач відкриває Pull Request або створює Issue. До таких дій мають доступ всі учасники без обмежень.
• Внутрішній агент (високі привілеї) — запускається виключно мейнтейнерами й має доступ до розширених функцій, включаючи середовище безперервної інтеграції та розгортання (CI/CD).

Як хакер експлуатує систему

Атакуючий використовує техніку prompt injection (впровадження зловмисних інструкцій у текстовий запит) для того, щоб змусити публічного бота сгенерувати спеціальний сервісний тег команди, наприклад @gemini-cli. Ось що далі відбувається:

1. Публічний бот сприймається системою як обліковий запис із правами Collaborator (учасника проекту).
2. Сервісний тег розпізнається як законний запит від розробника через цю привілейовану ролю.
3. Це запускає високопривілейованого внутрішнього бота для виконання критичних операцій.
4. Зловмиснику вдається отримати доступ до токенів автентифікації та змінювати коментарі в коді.

Підвищення привілеїв через ланцюг довіри між агентами представляє суттєво нову категорію загроз для організацій, які не передбачали подібні сценарії в своїх моделях захисту.

Рівні доступу й розмежування прав

Критична помилка полягала у тому, що система вважала публічного бота учасником проекту й надавала його командам легітимність. Тоді як цей бот виконував коди, укладені потенційними зловмисниками під час звичайного процесу創建 Pull Request.

Можливість запустити високопривілейованого агента без явної перевірки й ручного затвердження мейнтейнером створила ідеальне середовище для експлуатації. Система CI/CD, що працює на основі довіри до ролей облікових записів, виявилася вразливою до такого способу обходу авторизації.

Позиція розробника й рекомендації з безпеки

Google відновила безпеку свого репозиторію після виявлення цієї вразливості. Однак компанія відмовила у виплаті винагороди за програмою винагород за помилки, посилаючись на те, що успішна атака все ще вимагала б соціальної інженерії та ручного підтвердження змін мейнтейнером.

Незважаючи на це пояснення, експерти наголошують на необхідності глибшого переосмислення архітектури безпеки. Просто розділити середовища виконання недостатньо. Кожен ШІ-агент повинен володіти:

• Власною строго обмеженою цифровою ідентичністю (Agent Identity), а не спільною роллю;
• Мінімальним набором прав (принцип найменших привілеїв), необхідних для конкретного завдання;
• Явною верифікацією перед кожною критичною операцією;
• Журналюванням всіх дій для аудиту й виявлення аномалій.

Що повинні зробити організації прямо зараз

Для захисту своїх систем, на базі яких працюють ШІ-асистенти, компанії мають виконати такі кроки:

1. Переглянути архітектуру взаємодії між агентами в своїх репозиторіях та системах CI/CD.
2. Упровадити окремі цифрові ідентичності для кожного ШІ-агента замість спільних облікових записів.
3. Настроїти явну систему затвердження для операцій із високими привілеями.
4. Активізувати детальне журналювання й моніторинг поведінки ботів.
5. Провести навчання команди з фізичної інженерії й методів prompt injection.

Вплив на индустрію та майбутнє безпеки ШІ

Виявлення цього першого випадку атаки «агент проти агента» сигналізує про те, що епоха мультиагентних систем вимагає принципово нових підходів до безпеки. До появи широкого впровадження ШІ-асистентів такі вектори загроз просто не існували в практиці розробників.

Організаціям потрібно не тільки реагувати на вже виявлені вразливості, а й проактивно розробляти нові моделі захисту, які передбачають можливість маніпуляції між агентами. Це стосується як內部систем, так і публічних репозиторіїв, що працюють з користувальницьким контентом.

Визнання цієї загрози є першим кроком до розроблення дійсно безпечних систем штучного інтелекту. Без зміни підходу до розмежування прав та ідентичності агентів майбутні атаки будуть продовжуватися й набиватимуть більше масштабу.