Когда я начала разбираться в теме “вайбкодинг-безопасность”, мне быстро стало понятно: проблема давно не в том, что AI иногда пишет «грязный» код. Настоящий риск появляется в момент, когда люди без дополнительных проверок запускают продукты, сделанные Cursor или Claude, и не до конца понимают, что именно у них работает под капотом. Один оставил API-ключ в публичном репозитории и за ночь потерял деньги. Другие запускали приложения через Lovable и даже не знали, что их базы данных открыты для всех. Третий доверил AI-агенту доступ к инфраструктуре — и тот удалил production-базу. Ниже — три реальные истории о том, как желание запуститься быстрее обернулось проблемами с безопасностью.
Что такое вайбкодинг и почему это важно знать
Вайбкодинг — это по сути когда человек просит ИИ-ассистента для кода написать ему приложение, скрипт или интеграцию. Дальше большинство просто копирует результат, не особо вникая, как это устроено внутри. ChatGPT, Claude, Cursor или другие инструменты генерируют рабочий код, который действительно запускается, — это и есть вайб-кодинг для новичков. На этом этапе у человека часто возникает ощущение, что он “разобрался в разработке”, хотя на деле он просто собирает готовые куски.
По сути это кодинг без опыта: человек может никогда не писать продакшен-код вручную, но при этом уже запускает сервисы, подключает базы данных, API и платежные системы. Проблема начинается там, где пропадает понимание контекста — что такое секреты, где должны храниться ключи, как работает авторизация или почему нельзя просто вставить API-ключ в frontend. В вайбкодинге эти вещи часто остаются “за кадром”, потому что ИИ не объясняет последствия, он просто предлагает решение, которое “сейчас заработает”.
И именно это незнание делает вайбкодинг уязвимым с точки зрения безопасности. Когда код собирается через ИИ и сразу идет в продакшен, граница между “работает” и “безопасно работает” фактически исчезает.
История 1. API-ключ в публичном репозитории
Утечка данных при вайбкодинге случилась с моим знакомым, он основатель небольшого AI-стартапа, и этот кейс про то, как потерять почти весь бюджет на запуск из-за одной строчки кода.
Он не был техническим фаундером — раньше занимался маркетингом и продажами, а MVP решил собрать сам через vibe coding. Идея казалась простой: сервис для генерации карточек товаров для маркетплейсов, где продавцы загружают фото товара и получают готовые к размещению изображения. Нанимать команду он не хотел: задача была быстро проверить спрос, поэтому за несколько вечеров он собрал приложение с помощью AI-ассистента, который написал frontend, подключил API генерации изображений и помог с деплоем.
Главная цель была максимально приземленной: как можно быстрее показать работающий продукт первым клиентам.
Перед запуском он пополнил баланс API-сервиса примерно на $700. Вечером приложение наконец заработало: первые регистрации, первые тесты, первые довольные сообщения от знакомых. Чтобы показать проект потенциальному инвестору, он сделал репозиторий публичным и отправил ссылку.
Проблема была в том, что AI-ассистент выбрал самый быстрый путь, чтобы «всё заработало прямо сейчас». Вместо нормальной работы через backend и секреты в .env, он вставил API-ключ прямо в код frontend-приложения. Когда на одном из этапов переменные окружения не подтянулись, AI предложил временный костыль: захардкодить ключ в конфиг, а «потом вынести в .env». Как это обычно бывает, до «потом» руки не дошли.
Полезный блок со скидкой
Если захотелось разобраться, как устроена безопасность в реальных проектах, — держите промокод Практикума на любой платный курс: KOD (можно просто нажать). Он даст скидку при покупке и позволит сэкономить на обучении.
Бесплатные курсы в Практикуме тоже есть — по всем специальностям и направлениям, начать можно в любой момент, карту привязывать не нужно, если что.
Дальше сработал классический сценарий: публичный GitHub-репозиторий → git push с ключами → боты, которые сканируют открытые репозитории в поисках токенов. На следующий день утром он увидел десятки уведомлений о расходах. Кто-то нашел ключ, начал массово отправлять запросы к API и буквально за ночь сжег почти весь баланс.
Когда он полез разбираться, выяснилось, что ключ лежал сразу в двух местах: в публичном репозитории и в собранном frontend-bundle, откуда его тоже можно было достать за пару минут.
В итоге за одну ночь он потерял около $600, срочно перевыпускал ключи, чистил историю Git, закрывал репозиторий и переписывал архитектуру так, чтобы API работал через backend-прокси. Запуск пришлось остановить почти на неделю: пришлось перевыпускать ключи, чистить историю Git и переписывать архитектуру так, чтобы запросы к API шли через backend-прокси, а не напрямую из frontend.
Самое неприятное в этой истории — продукт работал именно так, как он хотел. AI действительно помог быстро собрать MVP. Просто вместе с MVP он случайно опубликовал ключи от своей инфраструктуры.
Похожий кейс обсуждали ещё на Reddit. Ошибки, которые он допустил:
- оставил API-ключ в коде, а не вынес секреты в .env
- сделал публичный репозиторий до проверки, что в нем нет секретов
- доверился AI-костылю «временно захардкодить ключ»
- не настроил ограничения на расходы и алерты у API-провайдера
История 2. Уязвимость с утечкой в 170+ приложений
Второй кейс уже не про индивидуального разработчика, который мог ошибиться по невнимательности, а про большую команду, которая однажды слишком доверилась ИИ-агентам и поставила под удар сохранность данных пользователей.
Сервис Lovable активно продвигался как способ собрать полноценное приложение «по переписке с AI»: описываешь идею, получаешь frontend, backend, авторизацию и базу данных практически без участия инженеров. Этим пользовались в основном фаундеры, продуктовые менеджеры и нетехнические предприниматели, которым нужно было быстро запустить MVP без команды разработки.
Типичный сценарий выглядел так: человек приходил в Lovable, писал что-то вроде «хочу маркетплейс для бронирования услуг» или «хочу SaaS для учета клиентов», платформа автоматически генерировала приложение на связке React + Supabase. Пользователь видел, что регистрация работает, данные сохраняются, приложение можно деплоить — и на этом считал продукт готовым.
Проблема была в том, что AI генерировал базы данных без Row Level Security (RLS) — ключевого механизма защиты в Supabase. При этом публичный anon key и URL базы автоматически попадали в клиентский код. Это само по себе нормально: Supabase так и работает. Но без RLS этот ключ фактически открывал доступ ко всей базе.
Иными словами, тысячи людей публиковали приложения, даже не подозревая, что любой человек может открыть DevTools, вытащить ключ из frontend-кода и напрямую отправлять запросы в базу данных.
Именно так это и обнаружили исследователи безопасности. Они начали проверять приложения, собранные через Lovable, и заметили повторяющийся паттерн: достаточно было найти Supabase URL и сделать простой запрос к API — и база отвечала без какой-либо авторизации. После массовой проверки выяснилось, что проблема затронула 170+ приложений и 303 публичных endpoint, а в открытом доступе оказались пользовательские данные, платежная информация, приватные сообщения и внутренние записи компаний.
Для многих владельцев этих приложений это стало шоком: внешне продукт выглядел полностью рабочим. Пользователи могли регистрироваться, заходить в аккаунты и пользоваться сервисом — просто параллельно вся база данных была открыта для всех.
После публикации исследования уязвимости присвоили идентификатор CVE-2025-48757, а Lovable пришлось обновлять шаблоны генерации и добавлять базовые настройки безопасности по умолчанию. Часть проектов срочно закрывали доступ к базам, включали RLS и перепроверяли, не успели ли злоумышленники скачать данные.
Самое показательное в этой истории: люди делали ровно то, что им обещал продукт — быстро запускали приложение без разработчиков. Проблема была в том, что AI отлично справлялся с задачей «чтобы работало», но полностью пропускал этап «чтобы было безопасно».
История 3. Когда у агента слишком много прав
Третий кейс — уже не про утечку данных, а про то, что бывает, когда AI-агенту дают слишком много прав.
Летом 2025 года основатель SaaS-компании и инвестор Джейсон Лемкин решил проверить, можно ли реально собрать коммерческий продукт через vibe coding. Он несколько дней строил приложение в Replit с AI-агентом: тот писал код, менял интерфейс, помогал с логикой и в целом сильно ускорял разработку. Лемкин позже говорил, что буквально «подсел» на такой формат, потому что продукт рос очень быстро.
На одной из стадий он объявил code freeze — то есть запретил AI вносить любые изменения в продакшен-код и попросил ничего не трогать без подтверждения. Нужно было просто стабилизировать систему перед следующим этапом.
Но AI-агент решил, что нашел проблему в базе данных: увидел пустые запросы, «запаниковал» и без разрешения начал выполнять команды. В результате он удалил production-базу с данными о 1 200+ компаниях и 1 200+ руководителях. После этого стало еще хуже: вместо того чтобы сразу признать ошибку, агент начал генерировать фейковые данные и утверждать, что все работает нормально. Позже сам Replit AI признал:
«I made a catastrophic error in judgment.»
Лемкин заметил проблему, когда увидел странные данные в системе и понял, что реальные записи исчезли. Сначала AI утверждал, что восстановить ничего нельзя, но позже выяснилось, что часть данных все-таки можно откатить через резервные копии. Replit публично извинился и пообещал добавить дополнительные ограничения для AI-агентов.
Эта история хорошо показывает, что главная проблема вайбкодинга — не только плохой код, но и опасная автономность, когда AI получает доступ к инфраструктуре уровня production.
| Что пошло не так | Последствие |
|---|---|
| AI дали доступ к production-базе | удаление реальных данных |
| Не было разделения dev/staging/prod | агент работал не в той среде |
| AI мог выполнять команды на удаление данных без подтверждения | удаление произошло за секунды |
| Слишком высокий уровень доверия к агенту | бизнес восстанавливал данные вручную |
Во всех трех историях повторяется один и тот же паттерн: AI отлично ускоряет запуск продукта — пока не получает доступ к тому, что может сломать бизнес за одну команду.
Почему ИИ не защищает вас от таких ошибок
Ключевая проблема вайбкодинга в том, что ИИ-ассистент для кода не оценивает безопасность как отдельную задачу. Он оптимизирует результат под “чтобы работало”, а не под “чтобы было безопасно”. Поэтому, если явно не попросить сделать security review, модель просто не добавляет его в процесс — не потому что “плохо обучена”, а потому что это не часть базового запроса пользователя.
Это подтверждают и исследования. Например, анализ GitGuardian показывает, что в 2025 году было обнаружено около 29 миллионов утёкших секретов в публичных репозиториях GitHub, и при этом AI-assisted commits утекали примерно в 2 раза чаще, чем обычный код. Другими словами, чем активнее используется ИИ для генерации кода, тем чаще в нём оказываются ключи, токены и другие секреты.
В другом исследовании безопасности AI-кода фиксируется ещё более жёсткая картина: при проверке pull request’ов, сгенерированных или доработанных агентами, до 87% из них содержали хотя бы одну уязвимость. Это означает, что “рабочий” код от ИИ почти всегда требует дополнительной проверки перед продакшеном.
Если упростить, механика ограничений вайбкодинга выглядит так:
- ИИ не запускает отдельную проверку безопасности по умолчанию
- он не различает учебный, тестовый и продакшен-контекст
- он предлагает решения, которые быстрее всего решают задачу
- уязвимости появляются как побочный эффект “ускорения разработки”
И именно поэтому риски в кодинге без знаний не исчезают — они просто переносятся дальше по цепочке, уже в работающие продукты.
Минимальный чеклист вайбкодера
Если вы понимаете основные vibe coding риски, уже проще выстроить безопасный вайбкодинг и не повторить ошибки из кейсов выше. Ниже — практический чеклист для кодинга с ИИ, который закрывает не очевидные, а более технические точки отказа.
- Проверяйте, не попали ли API-ключи, токены и credentials в frontend bundle после сборки (dist, .next, build) — секреты часто исчезают из исходников, но остаются в скомпилированном коде.
- Настраивайте pre-commit hooks и secret scanning (например, GitGuardian, Gitleaks или GitHub Secret Scanning) — это часть базового набора инструментов разработчика, который помогает ловить утечки до git push.
- Никогда не используйте service_role, root credentials или admin-токены в клиентском коде — особенно в проектах на Supabase, Firebase и других BaaS-платформах, которые часто генерирует ИИ.
- Ограничивайте права AI-агентов через IAM/RBAC: запрещайте удаление production-данных, изменение инфраструктуры и доступ к критичным ресурсам без ручного подтверждения.
- Перед деплоем прогоняйте SAST/DAST-сканеры (например, Semgrep, Snyk, SonarQube, OWASP ZAP) по коду, который написал ИИ — это часть подхода DevSecOps, где безопасность проверяют не в конце, а прямо в процессе разработки.
- Проверяйте зависимости, которые предлагает AI: он часто подтягивает устаревшие npm/pip-пакеты с известными CVE, deprecated-библиотеки или непроверенные GitHub-репозитории.
- Разделяйте staging/dev/prod окружения и не позволяйте AI работать напрямую с production-инфраструктурой — кейс Replit хорошо показал, чем заканчивается отсутствие такой изоляции.
- После генерации кода отдельно просите модель провести security review: искать SQL-инъекции, broken access control, insecure storage, exposed secrets и другие типичные уязвимости. Без этого кодинг с ИИ почти всегда заканчивается проверкой уже в продакшене.
Заключение
Если смотреть на все эти истории вместе, становится очевидно: вайбкодинг безопасность — это не про “плохие инструменты” и не про ошибки отдельных разработчиков. Проблема в том, что вайбкодинг делает разработку слишком простой, а правила безопасности при этом никто не объясняет и не встраивает в сам процесс. ИИ-ассистент для кода помогает быстро получить рабочий результат, но не подсказывает, где заканчивается “работает” и начинается “может быть опасно”.
В итоге люди, которые занимаются кодингом без опыта, запускают продукты, копируют готовые решения и доверяют генерации кода так же, как готовому сервису. Но в этом процессе легко пропустить базовые вещи — API-ключи в репозитории, открытые базы данных или доступ AI-агента к production-среде. И именно там появляются реальные инциденты.
Если после этой статьи хочется сделать один практический шаг — прямо сейчас проверь свой репозиторий на утечки секретов и ключей перед следующим git push. Это займет пять минут, но может сэкономить вам деньги, данные и много нервов.
Советуем дополнительно почитать по теме:
- 12 AI GitHub-репозиториев 2026 года: локальные модели, автоматизация и агенты — запускаем модели локально, автоматизируем без подписок, собираем агентов.
- Как создать AI-агента: пошаговое руководство — если вы попросите чат-бота отменить вашу подписку, он напишет вежливую инструкцию из пяти шагов. А AI-агент — сам пойдёт в биллинг-систему, проверит тариф и нажмёт кнопку «Отменить». Под капотом — суровая инженерия: выстроить архитектуру, выдать инструменты, настроить память.
- 15 скиллов для AI-агентов: установка и как работает в 2026 — базовое знакомство с экосистемой скиллов для AI-агентов: что это такое, как устроены внутри, почему работают именно так и какие 15 скиллов стоит затестить для рабочих задач.
- Закончились токены в Claude Code: 6 репозиториев, как сократить расход — подборка из 6 репозиториев для Claude Code и практический блок про то, как не сжечь бюджет на токенах ещё до того, как напишете первую фичу.
- Галлюцинации ИИ: почему LLM врут и как с этим бороться — что такое галлюцинации ИИ, почему модель может отвечать уверенно, но неточно, и как отличать правдоподобный ответ от фактически неверного.
Бонус для читателей
Если вам интересно погрузиться в мир ИТ и при этом немного сэкономить, держите наш промокод на курсы Практикума. Он даст вам скидку при оплате, поможет с льготной ипотекой и даст безлимит на маркетплейсах. Ладно, окей, это просто скидка, без остального, но хорошая.
