Ключі від ШІ витікають із навичок агентів та iOS-застосунків

Дослідження Університету Вейк-Форест вказують на спільну проблему двох швидкозростаючих екосистем ШІ: облікові дані часто зберігаються там, де їх можуть отримати агент, застосунок або зловмисник. В одному дослідженні проаналізували 17 022 сторонні навички для агентів і виявили 520 небезпечних навичок із 1 708 проблемами безпеки. У пов’язаному дослідженні 444 iOS-застосунків із функціями великих мовних моделей (LLM) 282 застосунки під час тестування розкривали ключі або механізми доступу до бекенду. 124

Практичний ризик полягає не лише в самому витоку рядка з ключем. API-ключ або токен може відкрити доступ до приватних даних, можливостей ШІ-агента чи платних запитів до моделі з облікового запису розробника.

Що показало дослідження навичок агентів

Дослідники відібрали 17 022 навички з 170 226 артефактів на SkillsMP — відкритому маркетплейсі навичок для ШІ-агентів. Вони поєднали статичний пошук секретів, динамічне тестування в ізольованому середовищі з тестовими обліковими даними та перевірку відповідності заявленої мети навички її поведінці під час виконання. 34

Аналіз виявив:

• 520 небезпечних навичок, у яких загалом було 1 708 проблем безпеки, розподілених за 10 схемами витоку облікових даних. 416
• 466 із 520 навичок розкривали дані, якими можна було скористатися без підвищених привілеїв. Це відповідає заявленому показнику 89,6% безпосередньої експлуатованості. 14
• 76,3% випадків витоку вимагали одночасного аналізу текстових інструкцій і програмного коду.
• 3,1% випадків були пов’язані з ін’єкцією вказівок природною мовою без виконуваного коду. 4

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

Як журнали налагодження передають секрети моделі

Особливо небезпечним виявився вивід налагоджувальної інформації. У фреймворках агентів стандартний вивід може потрапляти до контексту моделі. Тому ключ, надрукований через print або console.log, іноді стає доступним у відповідь на звичайний запит природною мовою. У зведенні дослідження зазначено, що 73,5% витоків були пов’язані з передаванням даних через стандартний вивід до LLM. 4

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

До витоків призводять і навмисні атаки, і недбалість

Дослідники описують дві основні причини:

• Навмисно шкідлива розробка. Автор додає інструкції або корисне навантаження, призначені для викрадення ключів чи приватних даних і, потенційно, їхнього надсилання на віддалений сервер.
• Недбала розробка. Розробник не дотримується безпечних практик і ненавмисно залишає облікові дані або шляхи доступу відкритими для зловмисників. 1

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

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

iOS-застосунки відкривають інший шлях до захоплення ШІ-акаунтів

У пов’язаному дослідженні перевірили 444 iOS-застосунки з функціями LLM. У 282 із них — приблизно 64% — мережевий трафік містив придатні для експлуатації ключі або механізми доступу до бекенду. 25

Серед основних способів витоку були:

• JWT-токени, які можна повторно використати: 48%;
• бекенд-проксі без автентифікації: 33%;
• передавання API-ключів у відкритому вигляді: 19%. 3

Такі слабкі місця можуть бути помітними під час звичайного користування застосунком. Зловмисник, який перехопить ключ, повторно використає токен або знайде відкритий проксі, потенційно зможе надсилати запити через обліковий запис розробника LLM. Це дає змогу витрачати кошти на платні обчислення, зловживати підключеними хмарними ресурсами та створювати несанкціоновані рахунки. 25

Наведені дані підтверджують ризик значних або потенційно необмежених витрат — залежно від лімітів облікового запису та тривалості атаки. Однак вони не доводять конкретну суму збитків, наприклад «сотні тисяч доларів».

Виправлення проблем також відбувалося повільно. Через три місяці після відповідального розкриття інформації лише 28% уражених iOS-застосунків усунули заявлену вразливість, а 72% залишалися експлуатованими під час повторної перевірки. 311

Чому це важливо в епоху AI-assisted development

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

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

Ризик посилюється на тлі так званого vibe coding — швидкої розробки та інтеграції програм за допомогою ШІ без глибокого опрацювання всіх деталей. Швидкість не замінює моделювання загроз: автентифікацію, роботу із секретами, авторизацію, журналювання та перевірку залежностей потрібно проєктувати свідомо. У дослідженні навичок агентів також зазначено, що у 72% випадків із жорстко закодованими обліковими даними були ознаки розробки за допомогою ШІ. Це може свідчити про масштабне поширення небезпечних шаблонів у згенерованому або поспіхом зібраному коді. 4

Які заходи безпеки потрібні

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

1. Не зберігати довготривалі ключі провайдерів на пристроях користувачів і в контексті моделі. Чутливі запити слід спрямовувати через автентифікований сервер.
2. Використовувати короткоживучі облікові дані з вузькими дозволами. Дотримуватися принципу найменших привілеїв і перевіряти токени, а не вважати сам факт їхнього володіння достатньою авторизацією.
3. Вилучати секрети з журналів і стандартного виводу. Усе, що потрапляє в контекст агента, потенційно може бути відновлене моделлю або користувачем.
4. Перевіряти на секрети код, конфігурації, промпти та залежності. Результати дослідження навичок показують, чому текстові інструкції та виконуваний код потрібно аналізувати разом.
5. Тестувати мережевий трафік і авторизацію бекенду. Переконатися, що перехоплений запит не можна повторити або перенаправити через проксі без автентифікації.
6. Розгортати ключі заново після витоку та перевіряти форки й копії. Видалення секрету з оригінального репозиторію не означає, що його прибрали з усіх поширених версій.
7. Запровадити перевірку на рівні платформи до публікації. Модерація маркетплейсу, рекомендації для розробників, відповідальне розкриття та автоматизовані перевірки мають доповнювати індивідуальну увагу до безпеки. 34

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