Из 444 iPhone-приложений с ИИ, которые проверили исследователи, 282 допускали утечку API-ключей или иным способом открывали доступ к платным LLM через обычный сетевой трафик. Для разработчика это не просто неловкость в стиле «ой, ключ уехал в клиент»: чужие запросы к модели могут идти за его счет. Для русскоязычных команд, которые собирают AI-функции поверх OpenAI, Gemini и других провайдеров, это прямое напоминание: мобильный клиент не должен знать ничего лишнего о платежном контуре.
О находке сообщает The Hacker News со ссылкой на исследование команды Wake Forest University. Авторы изучили 444 AI-чатбота для iOS из американского App Store конца 2025 года и пришли к неприятной, но предсказуемой цифре: почти две трети приложений оставляли путь к платному AI-бэкенду открытым. Причем речь не про джейлбрейк, реверс-инжиниринг или экзотику для мобильных пентестеров. Исследователи использовали собственный инструмент LLMKeyLens, который просто наблюдает за сетевым трафиком приложения и вытаскивает оттуда учетные данные или признаки неверно настроенного прокси.
Все 282 проблемных приложения разделили на три группы. В 54 случаях ключ передавался в открытом виде: достаточно одного перехваченного запроса, чтобы увидеть его целиком. Еще 92 приложения отправляли запросы через сервер, который отвечал любому клиенту вообще без проверки, кто именно к нему обращается. По сути это открытый ретранслятор к чьему-то платному аккаунту у AI-провайдера. Самая массовая категория — 136 приложений с так называемыми временными токенами. Формально это безопаснее, чем вшивать постоянный API-ключ, но на практике токены тоже утекали в трафике и часто оставались рабочими после перехвата. В одном приложении токен был выставлен до 2125 года, то есть «временность» там выглядела скорее как художественный прием. В другом токен с заявленным сроком жизни в один час продолжал работать еще 128 дней после истечения.
Исследование задело не только счета разработчиков, но и внутреннюю логику самих продуктов. У 28 из 54 приложений, где ключ уходил открытым текстом, в том же запросе обнаруживался еще и скрытый системный промпт. Это уже двойная неприятность: злоумышленник получает не только доступ к платной модели, но и инструкции, которые определяют поведение ассистента, ограничения, тональность и внутреннюю продуктовую механику. Для стартапов и команд, которые строят differentiation на промптах и обвязке поверх стандартных моделей, такая утечка превращает «секретный соус» в общедоступный ингредиент.
По данным исследования, уязвимые приложения использовали как минимум десять AI-провайдеров, причем OpenAI встречался чаще других. Проблема затронула 13 категорий приложений. Больше всего утечек нашли у продуктов для продуктивности, а самый высокий процент уязвимых приложений оказался в категории health and fitness. При этом финансовые и медицинские приложения в выборке не показали утечек вообще. Такой контраст выглядит показательно: там, где разработчики давно живут под давлением комплаенса и аудитов, дисциплина с секретами лучше. Там, где AI-функция часто добавляется как быстрый способ нарастить ценность продукта и конверсию в подписку, безопасность нередко остается на уровне «потом закроем».
И это не академическая страшилка ради красивого PDF. Украденные ключи уже давно используют в схеме, которую индустрия называет LLMjacking: чужие аккаунты эксплуатируют как бесплатный шлюз к дорогим моделям. The Hacker News приводит оценку Sysdig: в худшем сценарии скомпрометированные учетные данные могут набегать более чем на 46 тысяч долларов в день в виде AI-расходов. Это не означает, что каждая утечка приводит к такому счету, но хорошо показывает масштаб риска. Если у вас мобильное приложение с заметной аудиторией, даже одна ошибка в авторизации на прокси или один забытый ключ в клиенте могут быстро превратить юнит-экономику в анекдот для финансового директора.
Еще одна неприятная цифра касается реакции рынка. Исследователи уведомили все 282 команды разработчиков и подождали три месяца. За это время явные исправления появились только у 28% приложений. Еще 23% оставались открытыми, то есть утекший доступ продолжал работать. Остальные либо исчезли, либо не отвечали, либо возвращали ошибки, из-за чего нельзя было уверенно сказать, закрыта проблема или просто сервис лежит. Для индустрии это плохой сигнал: совет «не храните ключи в приложении» не нов и не требует прорыва в криптографии, но даже после прямого уведомления многие команды не довели базовую гигиену до конца.
Контекст у истории тоже неприятно устойчивый. В 2025 году исследование LM-Scout показало похожую небезопасную интеграцию AI-функций в Android-приложениях и автоматически получило доступ к 120 из них. Другая работа, Leaky Apps, находила секреты в тысячах Android- и iOS-приложений и отдельно подчеркивала старую болезнь мобильной разработки: даже если ключ убрали из кода, его часто забывают отозвать на стороне провайдера. Иными словами, AI-гонка не принесла новый класс ошибок, она просто сделала старые ошибки дороже. Раньше небрежность с секретами грозила инцидентом безопасности, теперь к нему добавляется счет за токены, который оплачивает не атакующий, а владелец продукта.
Практический вывод для разработчиков довольно скучный, а потому особенно полезный. Ключи нельзя встраивать в клиент. Запросы к модели нужно отправлять через свой сервер, а сервер должен не просто проксировать их, а проверять, кто именно пришел, с какого приложения, с какой сессией и с какими лимитами. Если ключ уже засветился, его надо отзывать, а не утешать себя тем, что «мы потом обновим приложение». Авторы исследования также предлагают AI-провайдерам прямо помечать client-side keys как небезопасный паттерн в документации, отслеживать аномальное использование одного ключа с тысяч устройств и усилить проверки на стороне App Store. Вопрос теперь не в том, найдутся ли еще такие утечки API-ключей, а в том, кто первым начнет относиться к мобильным AI-интеграциям как к платежной инфраструктуре, а не как к фронтенду с красивой иконкой.