Пользователи, которые создают приложения через нейросети, часто рассчитывают, что за безопасность результата отвечают разработчики соответствующих ИИ-сервисов. На самом деле, основная часть ответственности всегда остается на создателе приложения.Бизнес-партнер по безопасности 1С-БитриксОб эксперте: Леонид Плетнев — бизнес-партнер по информационной безопасности 1С-Битрикс. Курирует направление информационной безопасности в части организации взаимодействия бизнеса и технических подразделений. Эксперт в области проектирования систем защиты критичных данных, продуктовой безопасности, ИТ-аудита и контроля, CISM, CISA.
Три зоны ответственности
В августе 2026 года сервис Reeve проверил почти 31 тысячу приложений, созданных с помощью вайбкодинга, и выяснил: практически у каждого нашлась хотя бы одна проблема безопасности. Больше половины приложений на платформе Supabase позволяли читать таблицы базы данных без какой-либо авторизации, при этом 394 приложения раскрывали таблицы с персональными данными пользователей.
При этом вайбкодинг становится массовой практикой в компаниях. Однако безопасность сгенерированного кода часто остается без должного внимания: вручную код проверяют только 14% сотрудников.
Когда приложение создается при помощи вайбкодинга, в нем условно возникают три зоны ответственности. Первая зона закреплена за инфраструктурой, то есть за серверами, хранением данных, выдачей ключей и изоляцией приложений друг от друга. Провайдеры вайбкод-инфраструктуры как правило заранее задают настройки безопасности по принципу «закрыто все, что не открыли специально», поэтому пользователю не нужно делать это самому. Сервер с приложением не отвечает на запросы из интернета, поэтому подключиться к нему напрямую снаружи невозможно, а вход открывается через защищенный канал только тем, кого владелец пустил и кто прошел проверку на платформе.
Вторая зона приходится на ИИ-инструменты, которые генерируют код по описанию задачи и безопасность результата не гарантируют. За 2025 год в популярных мобильных приложениях российских разработчиков нашли 48,8 тысячи уязвимостей, что на 63% больше, чем годом ранее, и рост связывают в том числе с распространением ИИ-сгенерированного кода, который тиражирует небезопасные способы хранения чувствительных данных. Модель воспроизводит решения из примеров, на которых ее обучали, поэтому проверка сгенерированного кода строго обязательна, ведь без нее приложение может уйти в работу с неизвестным набором уязвимостей.
Третья зона остается за самим пользователем, который решает, какие данные доверить приложению, какие права выдать агенту и ключам, кому открыть доступ и что проверить перед запуском. Все эти решения хранятся под учетной записью владельца, и человек, получивший доступ к ней, получает вместе с ней приложение, его данные и ключи к сторонним сервисам. По словам эксперта, учетные записи теряют в основном из-за слабых паролей и украденных доступов, поэтому двухфакторный вход и надежный уникальный пароль закрывают большую часть этой угрозы.
Как настроить безопасность такого приложения
Главное правило вайбкодинга требует выдавать ИИ-агенту минимум прав, потому что агент работает с теми же полномочиями, что есть у учетной записи владельца, и все его действия засчитываются как действия самого человека. Например, приложению, которому достаточно читать сделки, разумно не давать право их удалять, и для сценариев с показом данных подходит режим «только чтение».
Тот же минимум прав вместе с экранированием ввода защищает от промпт-инъекции, когда злоумышленник прячет постороннюю команду внутри письма или страницы, которую читает агент.
Перед запуском эксперт советует проводить аудит даже тем, кто не умеет читать код. Больше половины пользователей вайбкодинга уже поручают проверку сгенерированного кода на уязвимости самому же ИИ, а больше четверти не проверяют результат вовсе. Аудит стоит запускать в отдельной чистой сессии и повторять на другой модели, поскольку проверка собственного кода дает завышенную оценку, и в запросе нужно явно просить проверить сам код, сторонние библиотеки, логику работы запущенного приложения и его системное окружение. Однако решения с юридическими и финансовыми последствиями в любом случае остаются за человеком.
Публичный доступ меняет риски
Отдельного внимания требует режим доступа к готовому продукту. Публичный режим открывает вход из интернета без пароля и приглашения, злоумышленники находят такие приложения при помощи постоянно сканирующих сеть ботов примерно за час, поэтому включать его имеет смысл только для форм или лендингов без чувствительных данных.
Как только приложением начинают пользоваться посторонние люди, владелец отвечает за него уже перед ними. Владельцу нужно составить собственные пользовательское соглашение и политику конфиденциальности, а по всему, что пользователи оставят в приложении, от имени и телефона до платежных реквизитов, он выступает как минимум обработчиком персональных данных и отвечает за сохранность этих сведений.
Отдельная история начинается, когда владелец подключает к приложению свой ключ от стороннего ИИ-сервиса: дальше с переданными данными обращаются по правилам этого сервиса, и эти правила также необходимо изучить заранее.