Інтелектуальні агенти виявили вразливість до атак на маршрутизатори

Критична вразливість у ланцюжку AI‑агентів: маршрутизатори

Маршрутизатори (API‑посередники), які з’єднують локальні агентські застосунки з хмарними ІІ‑моделями, представляють собою малоизвестну, але надзвичайно небезпечну точку атаки. Дослідники з Каліфорнійського університету в Санта‑Барбарі продемонстрували, наскільки легко можна скористатися цією вразливістю.

Що таке AI‑маршрутизатор?
* Роль – проксі між клієнтським застосунком і постачальником моделі (OpenAI, Anthropic, Google).
* Доступ – повний до кожного JSON‑пакету, що проходить через нього.
* Безпека – більшість великих провайдерів не застосовують криптографічну цілісність даних; тому маршрутизатор може змінювати запити без виявлення.

Як дослідники перевіряли загрозу
| Крок | Що зробили | Результат |
|------|------------|-----------|
| 1 | Отримали доступ до 28 комерційних маршрутизаторів (Taobao, Xianyu, Shopify) і проаналізували 400 безкоштовних з відкритих спільнот. | Увійшли у багато потенційно небезпечних точок. |
| 2 | Впровадили payload, замінивши URL‑адресу інсталятора або ім’я пакету на свій контрольований ресурс. | Змінений JSON проходив усі автоматичні перевірки; одна змінена команда `curl` запускала довільний код на клієнті. |
| 3 | Витік API‑ключ OpenAI і спостерігали, як зловмисники використовували його для генерації 100 млн токенів GPT‑5. |
| 4 | Було розкрито облікові дані в сесіях Codex. |
| 5 | Розгорнули 20 спеціально уразливих маршрутизаторів на 20 IP‑адресах і моніторили їх активність. | 40 000 спроб несанкціонованого доступу, ~2 млрд оплачених токенів, 99 наборів облікових даних у 440 сесіях Codex (398 проектів). У 401 з 440 сесій був увімкнено автономний режим YOLO, що дозволяє агенту виконувати будь‑які команди без підтвердження. |

Чому це так небезпечно
* Простота атаки – не потрібна підробка сертифікатів; клієнт сам вказує кінцеву точку API.
* Відсутність перевірки цілісності – шкідливий маршрутизатор може змінювати команду, яку агент виконуватиме.
* Небезпечні сервіси – навіть «добросовестні» посередники можуть стати вектором атаки.

Як захиститися без участі постачальника
1. Підпис відповідей від моделі – ідеальний варіант, але наразі відсутній у великих провайдерів (аналог DKIM для пошти).
2. Багаторівнева захищеність на стороні клієнта – розглядайте кожен маршрутизатор як потенційного противника:
* Валідація JSON‑структури та контенту.
* Обмеження за URL, методами HTTP і payload.
* Логи й моніторинг підозрілої активності.
3. Обмеження доступу до API‑ключів – зберігайте ключі у безпечних сховищах, застосовуйте ротацію та мінімальні права.

Висновок
Перевірка походження команди від ІІ‑моделі неможлива без підпису відповідей зі сторони постачальника. Поки такі механізми не з’являться, користувачі повинні захищати себе на стороні клієнта, ретельно перевіряючи усі проміжні сервіси й впроваджуючи суворі політики безпеки.