ИИ-агент может менять файлы, запускать команды и обращаться к внешним сервисам без подтверждения каждого шага. Такая автономность помогает в разработке, но доступ к production превращает ошибочное решение модели из неудачного кода в действие над данными и инфраструктурой.
Доступ ИИ должен ограничивать возможные последствия ошибки
Мы используем агентов для работы с кодом, тестами и конфигурацией инфраструктуры. При этом стараемся разделять две вещи: агент может самостоятельно готовить изменения, но его технические права не должны позволять выполнять действия, которые не нужны для задачи.
Текстовая инструкция вроде «не удаляй данные production» полезна для постановки задачи. Но она не заменяет права доступа, разделение сред и другие ограничения.
Если агент не должен удалять production-базу, надёжнее не выдавать ему учётные данные, которые позволяют это сделать.
Инструкция агенту не заменяет контроль доступа
В 2025 году основатель SaaStr Джейсон Лемкин рассказал об инциденте во время разработки приложения с Replit. Агент удалил production-базу, хотя до этого получал инструкции не менять систему во время заморозки кода.
Одна из причин заключалась в устройстве окружения: агент работал с данными, которые использовало production-приложение. Текстовый запрет существовал, но система технически разрешала выполнить операцию.
В 2026 году похожий принцип проявился в инциденте PocketOS. Агент Cursor столкнулся с проблемой учётных данных в тестовой среде, нашёл API-ключ Railway и удалил том. На томе находилась production-база.
Вместе с базой пострадали резервные копии, размещённые в той же области хранения. После операции агент сам указал, что нарушил заданные ограничения.
Оба случая показывают одну проблему: инструкция описывает желаемое поведение, но не запрещает действие технически.
Для системы безопасности это разные уровни контроля.
Фраза:
«Не удаляй данные production»
задаёт правило для модели.
Учётная запись без права удаления данных исключает такую операцию независимо от решения модели.
Тот же принцип давно применяют к людям и приложениям. Пользователю базы не выдают административные права, если они не нужны для его работы. Сервису не передают ключ от всей инфраструктуры, если он обращается к одному API.
ИИ-агентам имеет смысл выдавать права по той же модели.
Агенту нужны только права для текущей задачи
Цена ошибки зависит от доступных инструментов.
Если агент работает с локальной копией репозитория, неудачное изменение можно увидеть через Git и откатить. Если у него есть SSH, административный ключ облачного провайдера и доступ к production-базе, то же ошибочное решение может изменить данные, сетевые настройки или работающие сервисы.
Поэтому агенту стоит выдавать минимальный набор полномочий.
Для разработки ему могут понадобиться:
- исходный код;
- локальное окружение;
- тесты и статический анализ;
- журналы локальных сервисов;
- документация;
- тестовые внешние сервисы.
Для подготовки Dockerfile или конфигурации CI/CD доступ к production-серверу не нужен.
Такой подход не ограничивает задачи, которые агент способен решить. Он ограничивает последствия действий, которые к этим задачам не относятся.
Вместо прямого доступа к серверу — инфраструктура в коде
Отказ от SSH для агента не означает возврат к ручному администрированию.
Изменения инфраструктуры можно поручить ИИ в виде кода:
- Dockerfile;
- Docker Compose;
- конфигурации оркестратора;
- Ansible;
- Terraform;
- CI/CD;
- сценарии повторяемых административных операций.
В этом случае агент не меняет сервер напрямую. Он меняет файл, который описывает требуемое состояние или порядок действий.
Разработчик видит diff до применения изменений.
Вместо:
«Агент настроил сервер»
получается проверяемая последовательность:
«Агент предлагает изменить эти файлы конфигурации».
После проверки конфигурацию применяет автоматизированный процесс.
Это переносит неопределённость из этапа исполнения в этап подготовки изменений. Агент может предложить неверную конфигурацию, но команда увидит её до воздействия на production.
CI/CD отделяет подготовку изменения от его применения
Наш процесс можно представить так:
ИИ готовит изменение → инженер проверяет → CI/CD применяет
Агент работает с локальной копией проекта. Он может изменять код и инфраструктурные файлы, запускать тесты, собирать контейнеры и исправлять найденные ошибки.
После этого разработчик проверяет результат и отправляет изменение в репозиторий.
Дальше CI/CD выполняет заранее заданный процесс: собирает приложение, запускает проверки и развёртывает новую версию.
Человеку не нужно вручную выполнять команды на сервере. Его задача — контролировать переход между локальным изменением и production.
При этом сам процесс развёртывания остаётся автоматическим.
Прямой SSH-доступ агента часто мало добавляет к такой схеме. Если конвейер уже настроен, основная инженерная работа заключается не в выполнении команд, а в подготовке конфигурации, зависимостей, порядка операций и проверок.
Для прямого доступа пришлось бы дополнительно решать вопросы сетевых прав, хранения учётных данных, журналирования и ограничения доступных команд.
Если задачу можно выполнить через конфигурацию и CI/CD, отдельный канал доступа к серверу не требуется.
Секреты не нужно передавать модели без необходимости
Тот же принцип относится к паролям и ключам.
Чтобы настроить приложение, агенту достаточно знать имена переменных:
DB_PASSWORDS3_ACCESS_KEYPAYMENT_API_TOKEN
Их значения можно хранить в secret storage CI/CD или другом предназначенном для этого хранилище.
Во время развёртывания система подставит значения сама.
Так агент может подготовить конфигурацию, не получая пароль базы или ключ внешнего сервиса.
Каждая система, которой передали секрет, становится ещё одним местом его хранения и обработки. Если для выполнения задачи значение не требуется, его лучше не добавлять в контекст агента.
Резервная копия должна пережить тот же инцидент, что и основные данные
Инцидент PocketOS показывает ещё один принцип: резервную копию нужно изолировать от аварии, от которой она защищает.
Если данные и резервные копии находятся в одном томе или управляются одной учётной записью, одна операция может затронуть оба источника.
Поэтому критичные копии мы храним отдельно от серверов приложения — в удалённом хранилище.
Если ошибка агента, приложения или администратора повредит данные на сервере, удалит контейнерный том или потребует пересоздать машину, удалённая копия останется доступной.
Права на резервное хранилище тоже следует отделять от обычных полномочий агента.
Если агенту не нужно удалять резервные копии для выполнения задачи, его учётные данные не должны предоставлять такую возможность.
Этот принцип не связан только с ИИ. Агент лишь добавляет ещё одного участника, ошибка которого должна укладываться в уже существующую модель восстановления.
Контроль человека нужен на границах риска
Проверять вручную каждое действие агента не требуется.
В локальном окружении можно разрешить ему самостоятельно читать код, менять файлы, запускать тесты, искать информацию и пересобирать контейнеры. Эти операции обратимы и не затрагивают production.
Другой уровень — действия с production-данными, секретами, сетевыми правилами и облачными ресурсами.
Здесь одной инструкции недостаточно.
Поэтому человеческий контроль удобнее размещать на переходах между уровнями риска.
Агент самостоятельно готовит изменение. Автоматические проверки подтверждают формальные требования. Инженер разрешает переход в production. CI/CD выполняет заданную процедуру.
Так не приходится выбирать между полной автономией и ручным подтверждением каждой команды.
Ограничения остаются полезны после смены ИИ
Инфраструктура в коде, разделение сред, минимальные права и изолированные резервные копии нужны не только из-за агентов.
Конфигурация остаётся в Git. Её можно сравнить с предыдущей версией, проверить, воспроизвести на другом сервере или откатить.
Новый разработчик видит не набор команд, которые кто-то выполнил в терминале, а описание инфраструктуры проекта.
Поэтому ИИ хорошо сочетается с этими практиками. Агент сокращает трудозатраты на подготовку конфигурации, а существующие инженерные механизмы ограничивают последствия ошибки.
Безопасность должна зависеть от инфраструктуры, а не от поведения модели
Нельзя строить процесс на предположении, что агент всегда правильно интерпретирует инструкции.
То же правило действует и для человека.
Если доступ к production-базе не нужен для задачи, его не стоит выдавать. Если развёртывание выполняет CI/CD, агенту не нужен SSH. Если секрет можно подставить во время выполнения, его значение не нужно передавать модели.
Агент получает свободу там, где действие обратимо: в локальной разработке, исследованиях, генерации кода, конфигурации и тестах.
Production защищают технические механизмы: права доступа, разделение сред, Git, CI/CD, управление секретами и независимые резервные копии.
Текстовый запрет задаёт агенту правило. Инфраструктура определяет, может ли он его нарушить.
