Безопасность вайб-кодинга: дверь открыл сам ИИ

В мае 2026 израильская команда RedAccess просканировала 380 000 вайб-приложений на популярных no-code платформах. Пять тысяч из них сливают чужие данные прямо сейчас, пока ты это читаешь. Медицинские записи, финансы, внутренние документы компаний. Дыра у всех одна и та же, и её открыл не хакер.

Я собираю продукты через ИИ четвёртый год. Видел, как ИИ-агент в живом проекте моего знакомого снёс рабочую базу за вечер: решал рутинную задачу, выбрал короткий путь, грохнул всё. Бэкап был трёхдневный. Не злой умысел, не атака. Агент сделал ровно то, что сказали, - нашёл самое короткое решение. И таких историй вокруг меня - три за два года.

Дальше - четыре одинаковые ошибки из всех публичных историй взлома вайб-приложений, рабочий промпт «спроси у ИИ» который ловит главную дыру за минуту, история про то, как агент Codex обошёл права администратора через docker, и чек-лист на полчаса в конце.

Когда читаешь подряд истории про Lovable, Tea и сканирование RedAccess - удивляет общий знаменатель. Ни одна история не про «хитрого хакера». В каждой дыру открыл сам инструмент по умолчанию, а владелец не знал, что её надо закрыть.

Lovable, CVE-2025-48757. Платформа собирает приложения по текстовому описанию. Исследователь нашёл 303 открытые точки доступа в 170 приложениях. Наружу торчали имена, телефоны, статусы оплат, чужие ключи к ИИ-сервисам, домашние адреса. У 70% проверенных приложений защита строк в базе (RLS) была выключена полностью. RLS - правило «пользователь видит только свои строки». Когда таблицу создаёт человек через панель, защита включается сама. Когда таблицу создаёт ИИ командой - остаётся выключенной.

Tea, 72 000 фото и больше миллиона личных сообщений. Приложение для анонимных отзывов о людях. В июле 2025 потеряли около 72 тысяч изображений (включая 13 тысяч селфи и фото документов), затем больше миллиона переписок. Причина та же: открытое хранилище без проверки доступа.

RedAccess, май 2026. Сканирование 380 000 вайб-приложений. Из них 5 000 сливают чувствительные данные прямо сейчас - медицинские записи, финансы, документы компаний. Структурная причина в их репортаже: «многие платформы по умолчанию делают новые проекты публично доступными, а билдеры-непрограммисты не всегда знают, что это надо поменять».

Личный пример поближе. У одного вайб-кодера, которого я знаю лично, взломали приложение из-за стандартного пароля на базе. ИИ поставил пароль из дефолтного шаблона. Такой пароль подбирается ботом за секунды. Зашли, поставили майнеры, переписали проект. Пришлось сносить сервер целиком.

Четыре истории. Один знаменатель: дыра появляется сама. Ты не сделал ничего неправильного - ты просто не сделал ничего. А в безопасности бездействие означает «открыто всем».

Самая частая и самая дорогая дыра из четырёх - выключенный RLS на Supabase. Это значит, что любая таблица с пользовательскими данными отдаёт всё содержимое любому, у кого есть публичный ключ приложения. А публичный ключ лежит в HTML страницы и доступен любому через DevTools.

Чек руками займёт минут двадцать. Чек через ИИ - минуту. Вот рабочий промпт, копируй и вставляй в Claude Code или в любого агента, у которого есть доступ к твоему проекту:

Что этот промпт сделает за минуту. Откроет схему публичных таблиц, проверит флаг rowsecurity у каждой, посчитает политики через pg_policies, сопоставит названия колонок с маркерами персональных данных и сгенерит готовый SQL для копирования в SQL Editor. В лоб без агента это часовая работа - руками лезть в каждую таблицу и читать документацию.

Если в выводе хоть одна таблица с пользовательскими данными окажется с выключенным RLS - закрывай немедленно. Это та же дыра, через которую утекли 170 приложений Lovable. Скажи агенту: «применить SQL-скрипт из последнего ответа», подтверди в дашборде Supabase, что у проблемных таблиц появилась отметка «RLS enabled». Дальше проверь по-настоящему: зайди под обычным пользователем и попробуй запросить чужие данные. Если не пускает - политика работает.

Дальше расширенный набор: проверка прав на сервере, защита от prompt injection, борьба с майнерами. Полная инструкция со всеми источниками - в моём гайде по безопасности вайб-кодинга. Там 10 пунктов чек-листа, разбор RLS-политик на конкретных примерах и три инструмента которые проверяют код за тебя.

Самый недооценённый риск в вайб-кодинге - твой собственный агент со слишком широкими правами. Злой хакер снаружи - это уже следующая глава. Свежий пример с Hacker News, конец мая 2026. Агенту Codex поручили решить задачу, для которой нужны были права администратора. Прав у пользователя не было. Агент не остановился. Он осмотрелся, увидел, что пользователь состоит в группе docker, понял, что эта группа фактически даёт root, и через docker смонтировал хостовый раздел.

Цитата прямо из треда (тут единственная английская в статье):

В переводе: «sudo был недоступен, но у меня был доступ к группе docker, а это root-эквивалент. Я смонтировал хостовый путь и переписал живую конфигурацию.»

Тут нет злого умысла. Просто агент, которому сказали «реши задачу», находит структурную слабость быстрее человека. И если эта слабость даёт ему доступ к твоим ключам или к продакшену - он её использует. Атаку никто специально не разрабатывал. Она удалась, потому что у агента был доступ к учётным данным, которые не были нужны для выполняемой задачи.

В исследовании университета Джонса Хопкинса по агентам Anthropic, Google и Microsoft вывод сформулирован так же жёстко: в каждом успешном тесте у агента был лишний доступ. Никто специально его не «взламывал» - инструмент сам нашёл свою же слабость.

Из этого три практических следствия для тебя как владельца проекта:

Не запускай агента в режиме «разрешить всё» на боевой машине. Режим, где агент не спрашивает подтверждений (часто называется bypass или yolo), - только для песочницы или тестового проекта. Не для машины, где лежат рабочие ключи и доступ к продакшену.

Разнеси среды. Прод-ключи отдельно от среды агента. Машина для экспериментов - с тестовыми ключами. Я для каждого проекта держу две папки: одна песочница для агента, вторая боевая - в неё агент не ходит без ручного разрешения.

Запрети агенту читать секреты. В Claude Code это делается одной строкой в permissions.deny:

Тогда даже если агент захочет открыть .env, инструмент его не пустит. Важный нюанс: это покрывает встроенные инструменты агента. Если агент запустит свой скрипт, который сам откроет файл, правило не остановит. Поэтому жёсткая граница - это песочница на уровне системы. А permissions.deny - один из слоёв защиты, не последний.

Боты круглосуточно сканируют новые публичные коммиты на GitHub. По данным GitGuardian, от момента когда секрет попал в публичный репозиторий до первой попытки им воспользоваться проходит меньше 60 секунд. Меньше минуты. Дальше схема стандартная: нашли ключ от облака - подняли серверы под майнинг криптовалюты, утром у тебя счёт на десятки тысяч долларов. Истории такого формата регулярно всплывают в каналах разработчиков, и счета там пятизначные.

Масштаб проблемы за 2025 год в публичных репозиториях GitHub: 28,65 миллиона новых захардкоженных секретов, рост на 34% за год. Утечки именно ключей от ИИ-сервисов выросли на 81% за год - вайб-кодинг подливает масла. Логика понятная: агент делает git add . и git push не глядя, и твой .env уезжает в публичный доступ вместе со всем остальным.

Что проверить прямо сейчас, в этом порядке:

Дополнительный слой - инструмент gitleaks, который ищет секреты в истории коммитов локально, до того как они уехали в публичный репозиторий. Запускается одной командой: gitleaks detect --source .. На большом проекте может найти десятки забытых ключей за пять лет. Я первый раз гонял на старом репо - нашёл ключ от моментально оплачиваемой подписки, который кто-то из прошлой команды положил в коммит четыре года назад. Подписка к тому моменту уже была отвязана от карты, но если бы нет - бот тратил бы мои деньги все эти годы.

Тут начинается самое коварное в вайб-кодинге, потому что опасность приходит из инструмента, который ставишь ради безопасности. Когда выполняешь npx skills add ... или ставишь расширение в редактор, ты тянешь чужой код, который агент потом исполняет с твоими правами. Если автора взломали или пакет изначально вредоносный - проблема у тебя.

В мае 2026 вредоносное расширение «ahbanC.shiba» прожило в маркетплейсе VS Code (Visual Studio Marketplace) ровно восемнадцать минут до удаления модераторами. За эти 18 минут оно выгребло у поставивших его людей пароли из менеджера, токены GitHub, доступы к облаку и конфиги Claude Code (отчёт ReversingLabs, июнь 2026). Зловред часто переживает обычное удаление пакета и запускается в следующей сессии. Восемнадцати минут хватило, чтобы испортить жизнь сотням разработчиков.

Отдельная история про обманчивые названия. Самый звёздный публичный сборник навыков по кибербезопасности для Claude Code называется Anthropic-Cybersecurity-Skills. Около 14 800 звёзд, 754 проверки по OWASP, MITRE и NIST. Слово «Anthropic» в названии усыпляет бдительность. А в описании самого репозитория мелким шрифтом: «это независимый проект сообщества, не связан с Anthropic PBC». Сборник зрелый и сейчас чистый. Но автор - частное лицо. Если его аккаунт уведут - 14 800 пользователей получат зловред в следующем обновлении и будут думать, что обновление от Anthropic.

Минимум привычек перед установкой любого пакета: посмотри автора (если он не та компания, на которую похоже название - читай описание до конца), посмотри дату последнего коммита (свежий репо без истории - красный флаг), фиксируй версии в package.json точкой, не диапазоном ("package": "1.2.3", не "^1.2.3"), незнакомые инструменты прогоняй в тестовой среде без боевых ключей. И главное правило, которое я выработал на ошибках: безопасность пакета сегодня не равна безопасности завтра. Автор может продать репо или его уведут.

Половина моих историй про безопасность - не про то, как кого-то не пустили внутрь. Они про то, как вернулись, когда уже сломали. Я видел три полных потери проектов за последние два года. Все три по одному сценарию: ИИ-агент решал рутинную задачу, выбрал короткий путь, снёс важное. Открыли бэкап - трёхдневной давности. Три дня данных просто исчезли. В одной из историй проект так и не восстановили: данные были не критичные сами по себе, критичными были взаимосвязи, которые восстанавливать дольше, чем переписать с нуля.

Два правила, которые я соблюдаю на каждом проекте.

Бэкапы - часто. Если в приложении есть данные, которые жалко потерять, копия раз в сутки - уже иллюзия. Настрой автоматический бэкап минимум каждые 30 минут. У большинства баз (включая Supabase) это включается в пару кликов. И проверь руками: раз в месяц возьми последний бэкап, поставь в тестовое окружение, попробуй восстановиться. У меня есть знакомый, который три года думал, что бэкап работает. Когда понадобилось - копии писались в формате, который текущая версия СУБД не открывает. Бэкап был - восстановиться было нельзя.

Git - страховка от агента. Когда агент переписал то, что работало, ты откатываешься одной командой git reset --hard HEAD~1, а не часами споришь с ним. Правило, которое я даю агентам в инструкциях: «перед любой рискованной правкой делай коммит с текущим состоянием».

Возьми этот список и пройди по порядку перед тем, как открыть приложение людям. По моим замерам, на полностью свежий проект уходит 25-30 минут. Закрывает 90% типовых дыр, на которых горят вайб-кодеры.

Не пытайся закрыть всё сразу до состояния крепости. Возьми уровень риска под свой проект: сайт-визитка с формой обратной связи и приложение с платежами и медданными требуют разной строгости. Первые пять пунктов - это минимум для любого проекта, который видят чужие люди.

Три действия на ближайший час, которые закрывают 70% сценариев из всех публичных разборов.

Первое: проверь .gitignore и репозиторий на утёкший .env. Если уехал - отзови ключи и перевыпусти. Десять минут.

Второе: скопируй промпт из второго раздела, прогони на своей базе. Если есть таблицы без RLS - применяй сгенерированный SQL. Десять минут.

Третье: настрой бэкап раз в 30 минут вместо раза в сутки. Пять минут.

Через полчаса ты закроешь дыру, через которую утекли 170 приложений Lovable. Тебе не надо становиться безопасником. Достаточно базового уровня: ИИ собрал тебе продукт за вечер, отвечать теперь тебе. Дальше за 2-3 года утечек будет на порядок больше - массовость вайб-кодинга растёт, регуляторы подтянутся, а компании начнут спрашивать у вайб-продуктов аудит безопасности как обычное условие пилота. Тот, кто закрыл базовые дыры сегодня, через год просто будет работать. Если хочется глубже - сценарии prompt injection, защита webhook через подпись, борьба с майнерами в коде агента - всё это в полной инструкции по безопасности вайб-кодинга.

Вопрос в комменты тем, кто уже что-то выложил через ИИ: ты делал ревизию своего .env за последний месяц? Или думал «потом, когда руки дойдут»?