Безопасность вайбкодинга

Опасность вайбкодинга — не в том, что модель напишет вредоносный код. Она в том, что агент читает файлы целиком, выполняет команды и ходит в сеть, а вы это разрешили один раз и забыли. Дальше — конкретные настройки и правила вместо общих слов про осторожность.

Что ломается на практике

Пять сценариев, которые встречаются чаще остальных:

• Ключ уехал в репозиторий. Агент прочитал .env, процитировал строку в объяснении, вы закоммитили вывод или скриншот.
• Команда с побочным эффектом. Одобрили «почини миграции» — получили выполненную миграцию на боевой базе.
• Тихо неправильные права. Код работает, эндпоинт отвечает, проверки владельца объекта нет. Запуск этого не ловит.
• Лишняя зависимость. Модель предложила пакет, вы поставили, он тянет за собой ещё сорок.
• Инструкция из данных. В прочитанном issue или на странице документации оказался текст, адресованный агенту.

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

Секреты: главный источник аварий

Правило первое и не обсуждаемое: ключи, пароли и токены не лежат в файлах проекта. Ни в коде, ни в конфиге, ни в комментарии «временно».

Минимальный порядок:

1. Секреты — в переменных окружения или в отдельном файле вне репозитория.
2. .gitignore заводится до первого коммита и содержит .env, *.key, *.pem, локальные конфиги.
3. Если ключ всё-таки попал в коммит — он скомпрометирован. Не «удалить файл», а отозвать и выпустить новый: история git остаётся у всех, кто уже сделал clone.
4. Проверять перед выкладкой не глазами, а поиском: git diff плюс grep по характерным префиксам ключей.

Отдельный слой защиты есть в самих инструментах. У Claude Code настройки песочницы позволяют закрыть чтение конкретных путей и переменных окружения, причём запрет держится внутри более широкого разрешения: если открыть на чтение весь домашний каталог, а ~/.env закрыть, файл останется закрытым. Работает это, впрочем, только там, где песочница вообще поддерживается.

Права: что агент может без вопроса

У современных CLI-агентов права настраиваются, и по умолчанию они разумны — проблемы начинаются, когда их расширяют «чтобы не мешало».

Claude Code. В ручном режиме сессия начинается с прав только на чтение: запись файлов, выполнение команд и вызовы MCP-инструментов спрашиваются. Встроенный набор безопасных команд вроде ls, cat и git status выполняется без вопроса. Отдельно оговорено, что команды, тянущие данные из сети (curl, wget), автоматически не одобряются. Есть граница рабочего каталога: в ручном режиме писать можно только в папку запуска и её подпапки. В автоматическом режиме вместо человека действия просматривает отдельная модель-классификатор, а ваши явные правила запрета продолжают действовать всегда.

Codex CLI. Права задаются режимом песочницы — read-only, workspace-write или danger-full-access — и отдельно политикой одобрений (on-request, never и другие значения в конфиге). Значения по умолчанию в справочнике не зафиксированы, поэтому свои фактические нужно смотреть командой codex doctor: она печатает строку с реальным режимом файловой системы, сети и одобрений.

Практическое правило по разрешениям: разрешать точечно и заранее (конкретные команды вроде npm run lint), а не широко и в момент, когда агент уже ждёт. Разрешение, выданное на десятом подряд запросе, вы не читали.

Песочница и её границы

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

Здесь есть ограничение, которое обязательно нужно знать заранее: у Claude Code песочница работает на macOS, Linux и WSL2, а нативная Windows не поддерживается. Формулировка в документации прямая: «Native Windows is not supported. On Windows, run Claude Code inside a WSL2 distribution». У Codex на Windows команды выполняются под sandbox на restricted token.

Что это значит на практике: если вы на Windows и вам нужна изоляция уровня ОС — либо переносите работу в WSL2, либо выбираете инструмент, у которого этот механизм на Windows есть. Подробнее — в установке Claude Code на Windows и в установке Codex CLI на Windows.

Чего песочница не заменяет: она не проверяет корректность кода и не мешает агенту записать в ваш же проект что-то неправильное. Это защита от «команда сделала не то с системой», а не от «код делает не то».

Подмена инструкций

Агент читает не только ваши сообщения, но и файлы, страницы, вывод команд, тексты задач. Любой из этих источников может содержать текст, написанный так, чтобы агент принял его за указание. Это называется инъекцией промпта, и полностью её не решает никто.

Встроенные механизмы защиты есть: разрешения на чувствительные операции, отдельный контекст для загруженных из сети страниц, подтверждение доверия при первом запуске в новом репозитории и при подключении нового MCP-сервера, отдельная проверка подозрительных команд даже из ранее разрешённого списка. В документации Claude Code при этом стоит честная оговорка: эти меры существенно снижают риск, но полностью иммунной система не бывает.

Что зависит от вас:

• Не отправляйте недоверенный текст прямо в агента — особенно вывод, скачанный из сети.
• Читайте предлагаемые команды до одобрения, а не после.
• MCP-серверы ставьте только те, чей источник вам понятен. Каталоги коннекторов проверяются на соответствие критериям листинга, но это не аудит безопасности.
• Работу с внешними сервисами по возможности выносите в отдельную машину или контейнер.

Чужой код и зависимости

Модель охотно предложит библиотеку. Три вопроса перед установкой:

1. Существует ли она вообще? Название может быть правдоподобным и выдуманным — а на выдуманные названия популярных пакетов иногда заводят настоящие вредоносные.
2. Нужна ли она? Половина предлагаемых зависимостей закрывает пятнадцать строк собственного кода.
3. Что она тянет за собой? Смотреть надо на дерево зависимостей, а не на одну строку в манифесте.

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

Точка отката

Всё вышеперечисленное — про снижение вероятности. Точка отката — про то, что делать, когда что-то всё-таки произошло.

• Git с первого дня. Не «когда проект станет серьёзным». Возможность вернуться на шаг назад одной командой отделяет эксперимент от потери работы.
• Коммит перед тем, как отпустить агента надолго. Чистое дерево до запуска — это возможность посмотреть ровно на то, что он сделал.
• Резервная копия данных, а не только кода. Git не защищает базу, а именно её ломают миграции.
• Стенд для всего необратимого. Платежи, рассылки, миграции, удаление — сначала на копии.

Отдельно про встроенные механизмы отката: у Claude Code есть контрольные точки и /rewind, восстанавливающие состояние разговора и файлов. В документации к ним есть важная оговорка — они отслеживают только изменения через инструменты правки файлов, а изменения, сделанные командами оболочки или внешними процессами, не захватываются. Заменой git это не является.

Чек-лист на полчаса

1. Завести .gitignore и убедиться, что секретов нет ни в одном отслеживаемом файле.
2. Отозвать и перевыпустить всё, что когда-либо попадало в репозиторий.
3. Посмотреть фактические права агента: codex doctor или /permissions и /sandbox.
4. Решить, где вы работаете: нативно без изоляции или в WSL2 с песочницей.
5. Прописать в файле правил проекта запреты: не трогать миграции, не ставить зависимости без согласования, не выполнять команды против боевой среды.
6. Проверить, что бэкап базы существует и что вы умеете его разворачивать.
7. Список MCP-серверов и внешних интеграций — сократить до тех, которые действительно нужны.

Проверка результата — отдельная тема со своим порядком действий: как проверять код от ИИ. Почему у агента вообще появляются такие права и что меняется по сравнению с чатом — в разборе ИИ-агентов.