Перед публикацией сайта проверьте файлы проекта, историю изменений и код, который получит браузер посетителя. ИИ-агент мог вставить API-ключ в настройки, пример кода или готовую страницу. Если ключ нашёлся, удалите его из проекта и замените у поставщика сервиса: одного удаления из файла недостаточно. Ниже — порядок проверки для владельца бизнеса без опыта разработки и способ поставить такую проверку перед следующими правками Claude Code.
Где искать ключ после работы ИИ-агента?
Представьте обычную задачу: вы попросили агента подключить к сайту внешний сервис и дали ему ключ для настройки. Агент написал код, проверил соединение, а заодно сохранил ключ в файле с настройками. Сайт работает, поэтому на глаз ошибку не заметить. Начните с папки проекта и выясните, какие файлы агент создал или изменил перед публикацией.
Сначала проверьте файлы настроек, примеры конфигурации и код страниц. Ищите названия вроде API_KEY, SECRET и TOKEN, а также название сервиса, к которому подключали сайт. Отдельно посмотрите файлы .env: в них часто кладут настройки для локальной работы. Если вы пользуетесь Git, проверьте и список файлов, которые попадут в следующий коммит — сохранённое изменение проекта.
Есть ещё место, которое легко пропустить: код сайта, который браузер загружает посетителю. Если агент вставил ключ туда, скрыть его папкой проекта или настройкой доступа на сервере уже не получится. Ключ для такого подключения держат на стороне сервера, а сайт обращается к серверу за нужным действием. Если схема подключения непонятна, попросите разработчика показать, где именно хранится ключ и какой код получает браузер.
Даже если .env не попадает в Git, агент может прочитать его во время работы. Содержимое прочитанного файла уйдёт в API модели вместе с запросом; поэтому для Claude Code имеет смысл запретить чтение .env через правила доступа и не держать рабочие ключи сайта в локальном проекте (Хабр, «−$200 за 40 минут: как я прошла принудительный экспресс-курс по security для вайбкодинга»).
Как проверить проект без ручного просмотра каждого файла?
Проведите автоматический поиск секретов по файлам проекта. Для этого подойдёт ggshield от GitGuardian: утилита распознаёт больше 500 типов ключей и токенов и может проверять изменения перед коммитом (Sostav.ru, «Claude Code и безопасность данных: что уже нашли и починили, а что проверять предпринимателю»). Начать можно с одного запуска на копии проекта; затем разработчик настроит проверку перед сохранением новых изменений в Git.
Отчёт сканера стоит разобрать по каждому совпадению. Найденная строка бывает учебным примером, но бывает и действующим ключом. Проверьте, к какому сервису она относится, используется ли сейчас и в каком файле лежит. Не вставляйте найденное значение в переписку с агентом или открытый онлайн-инструмент ради уточнения: покажите специалисту путь к файлу и тип находки, а сам ключ передавайте только через согласованный закрытый канал.
Автоматический поиск не закрывает всю задачу. Он может не распознать строку без привычного формата, а проверка текущих файлов не отвечает на вопрос, был ли ключ в прежнем коммите. Поэтому после отчёта посмотрите историю Git и откройте сайт в браузере: проверьте код страницы и файлы, которые браузер загрузил после открытия. Для общей проверки сайта после правок агента пригодится порядок проверки API сайта после вайбкодинга.
Что делать, если ключ уже попал в код или историю Git?
Сначала определите, успел ли проект выйти за пределы вашего компьютера: отправляли ли его в общий репозиторий, публиковали ли сайт, давали ли доступ подрядчику. При любом сомнении считайте найденный рабочий ключ раскрытым. Зайдите в настройки сервиса, которому принадлежит ключ, отключите его и создайте замену. Если не знаете, где это сделать, найдите в панели сервиса раздел с ключами и передайте задачу человеку, который подключал сервис.
После замены уберите старый ключ из кода и проверьте, не остался ли он в истории Git. Удаление строки из последнего файла не стирает прежние версии. Если ключ уже попал в общий репозиторий, разработчик разберётся с историей и копиями проекта; замену ключа откладывать до окончания этой работы не стоит. Заодно проверьте, не записывал ли сайт значение ключа в отладочные сообщения или файлы с ошибками.
Новый ключ сохраните там, откуда его берёт сервер, без добавления в код страниц и общую папку проекта. Затем проверьте нужное действие сайта: например, отправляется ли заявка через подключённый сервис. Так вы поймёте, что старый ключ отключён, новый работает, а опубликованная страница не раскрывает его посетителю.
Как поставить проверку перед следующей публикацией?
Попросите того, кто работает с проектом, встроить поиск секретов в привычный путь правки: агент меняет файлы, сканер проверяет изменения перед коммитом, человек просматривает результат, затем обновляет сайт. GitGuardian описывает ggshield как утилиту, которую можно подключить к такой проверке перед коммитом без сложной настройки (Sostav.ru, «Claude Code и безопасность данных: что уже нашли и починили, а что проверять предпринимателю»).
Добавьте в инструкции для Claude Code короткое правило: не читать .env, не вставлять ключи в код страниц и не печатать их в ответе. Правило не заменяет сканер, ведь агент способен ошибиться или взять секрет из другого файла. Практичнее закрепить оба шага в рабочем процессе: запрет на чтение файлов с секретами и отдельную проверку изменений перед публикацией. Если проект ведёт подрядчик, результатом такой проверки станет понятный ответ: какие файлы проверили, что нашли и где теперь хранится ключ.
Какие ошибки мешают заметить утечку?
- Проверять только страницу в браузере. Ключ может остаться в файле настроек или прежней версии проекта, хотя на странице его не видно.
- Добавить .env в список исключений Git после того, как файл уже сохранили в истории. Исключение поможет с будущими изменениями, но прежний коммит останется.
- Принять отсутствие находок у сканера за доказательство безопасности. Просмотрите историю проекта и код, который браузер получает при загрузке сайта.
- Удалить найденный ключ из файла и продолжить им пользоваться. Если его уже раскрыли, отключите старое значение у поставщика сервиса.
- Отправить ключ агенту для «проверки». Для разбора достаточно указать файл и место находки без самого значения.
Перед ближайшей публикацией начните с трёх действий: просмотрите изменённые агентом файлы, запустите поиск секретов и уточните, какой код получит браузер. Если обнаружится рабочий ключ, сначала замените его у поставщика сервиса, затем проверьте историю проекта и работу сайта с новым ключом.
