Исследование Wake Forest: ИИ-агенты и приложения для 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% утечек были связаны с передачей вывода модели через стандартный поток. 4

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

Виноваты и злоумышленники, и небрежная разработка

Исследование выделяет две основные причины утечек:

• Злонамеренная разработка. Создатель намеренно добавляет инструкции или полезную нагрузку для сбора учетных данных и частных данных, а иногда и их отправки на удаленный сервер.
• Небрежная разработка. Разработчик не соблюдает безопасные практики и случайно оставляет учетные данные или пути доступа открытыми для атакующих. 1

Разница важна для устранения последствий. Злонамеренные материалы необходимо выявлять и удалять, а случайные утечки требуют более надежного управления секретами, безопасного логирования, контроля аутентификации и тестирования до публикации.

После того как исследователи сообщили о проблеме SkillsMP, Wake Forest заявила, что все выявленные злонамеренные навыки были удалены, а большинство уязвимых — исправлено. Однако очистка исходного репозитория не гарантирует полного устранения проблемы: копии и форки могут сохранить раскрытые учетные данные даже после исправления оригинала. 14

Приложения для iOS открывают другой путь к захвату аккаунта LLM

В рамках связанного исследования проверили 444 приложения для iOS с функциями LLM. В 282 из них — примерно в 64% — сетевой трафик содержал пригодные для эксплуатации учетные данные LLM или механизмы доступа к серверной части. 25

Исследователи зафиксировали следующие основные варианты:

• Повторно используемые токены на основе JWT — 48% случаев;
• Неаутентифицированные прокси серверной части — 33%;
• Передача API-ключей в открытом виде — 19%. 3

Такие слабые места могут проявляться при обычном использовании приложения. Если атакующий перехватит ключ, повторно применит токен или найдет открытый прокси, он сможет отправлять запросы к LLM через аккаунт разработчика. Это позволяет расходовать оплаченные ресурсы модели, злоупотреблять связанными облачными сервисами и создавать несанкционированные счета. 25

Предоставленные данные подтверждают риск серьезных, а в зависимости от лимитов аккаунта и продолжительности атаки — потенциально неограниченных расходов. При этом они не доказывают конкретную сумму ущерба, например «сотни тысяч долларов».

С исправлением проблем также не спешили. Через три месяца после ответственного раскрытия информации уязвимость устранили лишь в 28% затронутых приложений; в последующем исследовании 72% оставались эксплуатируемыми. 311

Чем это важно для разработки с помощью ИИ

В совокупности две работы показывают: добавление ИИ-функции в приложение или установка готового навыка для агента расширяет поверхность атаки. Возникают новые риски, включая:

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

Проблема становится особенно заметной на фоне так называемого vibe coding — разработки, при которой код быстро создается и интегрируется с помощью ИИ. Скорость не заменяет моделирование угроз: аутентификацию, работу с секретами, разграничение прав, логирование и проверку зависимостей по-прежнему нужно продумывать на уровне инженерии. В исследовании агентских навыков признаки разработки с помощью ИИ обнаружили в 72% случаев с жестко заданными учетными данными, что указывает на возможность массового распространения небезопасных шаблонов в сгенерированном или быстро собранном коде. 4

Какие меры рекомендуют исследователи

Выводы работ формируют базовый набор защитных мер для команд, создающих ИИ-продукты или распространяющих агентские навыки:

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

Главный вывод прост: безопасность ИИ нельзя добавлять в последний момент, уже после выхода продукта. Учетные данные, полномочия агентов, контекст модели и контроль расходов должны рассматриваться как базовые элементы безопасности продукта с самого начала.