Безопасная разработка с агентами держится на трёх замках: ключи, ревью другой моделью и стоп на необратимом

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

Наш материал для проверки этих границ: записи работы машины агентов на vibecoding.ru. Собственного клиентского кейса у нас нет. Ниже разобраны эпизоды нашего сайта; они показывают механизм ошибки, а не частоту инцидентов у клиентов.

Фраза «не трогай секреты» полезна в правилах для ИИ-агентов, но сама не ограничивает чтение файла. Аналогично пароль на экране ничего не говорит о правах прямого запроса к серверу. В ленте видно, где расходились инструкция, интерфейс и реальное действие.

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

Распределение ответственности и подготовка отката разобраны в статье об ошибках ИИ. Здесь разберём свидетельства, по которым ИТ-директор может разрешить работу: какие права выданы, что нашёл проверяющий и кто подтвердил опасный шаг.

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

Исключение файла из git защищает от коммита, но не от чтения агентом. Файл вне репозитория также остаётся доступен процессу, если у того есть право читать весь диск. Проверяемая изоляция задаёт разрешённые пути, окружение и инструменты; секрет не должен появляться в журнале команды или теста.

Входящее письмо, задача из трекера или содержимое сайта могут включать чужую инструкцию. Агент должен обрабатывать их как данные, а права инструмента ограничивает исполняющая система. OWASP рекомендует минимальные полномочия: для проверки отправки письма не нужен ключ, позволяющий управлять всей почтой.

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

Код и объяснение автора часто выглядят согласованно. Мы отдаём проверку другой модели в отдельном контексте: исходная задача, изменение кода, правила доступа и список запрещённых действий. Просим искать нарушение этих правил, а не подтверждать объяснение автора. Это наш способ проверки, а не требование NIST или гарантия независимости ошибок моделей.

Статический анализ кода, SAST, тоже нужен: он ищет известные признаки уязвимостей без выполнения приложения. По описанию OWASP, автоматическая проверка авторизации сложна; конфигурация за пределами кода может остаться вне анализа. Поэтому отсутствие замечаний сканера не отвечает на вопрос, может ли посторонний аккаунт получить чужую запись.

Этот вопрос проверяют на тестовых данных прямым запросом к серверу: без входа, с неподходящей ролью и с чужим объектом. Ожидаемый результат задают заранее: доступ запрещён, содержимое не возвращается. Замечание модели превращают в воспроизводимую проверку; инженер оценивает результат и исправление.

Удаление ящика требует подтверждённой выгрузки истории до удаления. Обещание «если что, восстановим» ничего не доказывает, пока выгрузку не открыли и не проверили. Для удаления данных или разрушительного изменения схемы нужен такой же конкретный ответ: что сохранено и проверено до исполнения.

Переключение DNS обычно можно вернуть, но оно немедленно меняет путь посетителей к проду. Поэтому стоп нужен и перед обратимыми действиями с большим воздействием. Общий заказ «перенести сервис» не должен одновременно разрешать каждое переключение и удаление по пути.

До разрешения агент готовит изменение, ожидаемый эффект и проверку результата. Право выполнить опасный шаг остаётся у человека или отдельного процесса согласования. Если у агента уже есть неограниченный ключ, фраза «жди команды» оставляет запрет на его усмотрение; ограничение должно проверяться при вызове инструмента.

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

Для своей карты безопасности мы используем NIST CSF 2.0: управление, выявление, защита, обнаружение, реагирование и восстановление. Это шесть функций рамки управления рисками. Таблица ниже переводит их в вопросы про агентов; такой перевод наш, NIST не предписывает проверку кода другой моделью.

Список правил легче показать, чем след их исполнения. Например, запись «ключи защищены» стоит заменить подтверждением, кому ключ выдан и как его отозвать. После обнаружения лишнего доступа руководителю нужен статус исправления, а после удаления важна проверка восстановления, а не только сообщение «задача закрыта».

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

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

Решение о расширении доступа принимает руководитель разработки вместе с ответственным за безопасность. У них должны остаться результаты проверок и список неразрешённых действий. Второй агент с сообщением «всё хорошо» не заменяет эти материалы.

Если сначала нужно оценить, как у вас устроены задачи и проверки, пройдите тест для руководителя. Он помогает оценить организацию разработки; безопасность конкретного продукта проверяют отдельно по его коду, правам и среде.

Для потока разработки есть подписка на разработку: «Один проект» и «Все проекты». Код остаётся в репозитории клиента. В FAQ сервиса на 7 октября 2026 указано: код не идёт в обучение моделей, запросы хранятся 30 дней. Эту формулировку и условия доступа стоит проверить при согласовании работы.

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

2. Проверку отделяют от написания. Дайте другой модели правила доступа и превратите замечания в воспроизводимые тесты.

3. Опасный шаг требует собственного разрешения. Убедитесь, что исполняющая система проверяет его, а сохранённые данные можно открыть.

4. Три замка включают в полный цикл. Назначьте ответственного за обнаружение, остановку, отзыв ключей и восстановление.

5. Допуск расширяют по доказательствам. Сохраните результаты пилота и список действий, на которые агент ещё не получил прав.