Права AI-агента: как дать доступ к инфраструктуре и не потерять продакшен

Опубликовано 24 сентября 2026 · 8 минут

Агент в Cursor, Claude Code или Replit работает с теми правами, которые сумеет найти. В этом гайде разбираем, что обычно входит в эти права, каких ключей у агента быть не должно и как настроить проект, чтобы агент мог деплоить и отлаживать, но не мог удалить данные на продакшене.

На типичный проект на Vercel, Railway, Supabase или Fly настройка займёт полдня. Отказываться от агентов в инфраструктурных задачах не придётся. Задача скромнее: если агент ошибётся, пострадает только dev-окружение, которое вы можете пересоздать.

Два инцидента с одной причиной

PocketOS, апрель 2026. Агент в Cursor на Claude Opus нашёл токен Railway CLI в файле, который не имел отношения к задаче. Токен создавали для управления доменами, но он разрешал любые операции. Агент одним API-вызовом удалил продакшн-базу и бэкапы на уровне тома, на всё ушло 9 секунд. Данные восстановили примерно через час с помощью Railway (The Register).

Replit и SaaStr, июль 2025. На девятый день эксперимента Джейсона Лемкина, во время объявленной заморозки кода, агент Replit удалил продакшн-базу с записями о 1206 руководителях и 1196 компаниях. Кроме того, он сгенерировал базу из 4000 вымышленных людей. Сначала агент сообщил, что откат невозможен, но откат сработал. После инцидента Replit добавил автоматическое разделение баз для разработки и продакшена (The Register, Fortune).

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

К чему у агента есть доступ на вашей машине

Локальный агент работает от имени вашего пользователя в системе. Если его не ограничить, он может читать и использовать:

Все файлы репозитория, включая .env, .env.production, старые конфиги, скрипты с зашитыми токенами и заметки, которые когда-то попали в коммит. Файл из .gitignore по-прежнему лежит на диске и читается.
Логины CLI в домашней папке. После railway login, vercel login, supabase login, fly auth login или aws configure токен хранится в файле в домашней папке, например в ~/.aws/credentials. Им может воспользоваться любой процесс, запущенный от вашего имени, и часто с полными правами на аккаунт.
Переменные окружения из профиля шелла, в том числе DATABASE_URL, который смотрит на продакшен.
Подключённые MCP-серверы. MCP-сервер базы данных или хостинга работает с теми ключами, которые вы ему дали, и агент может вызвать любой его инструмент.
Шелл. Если агенту разрешено выполнять команды, он может запустить psql, curl к API провайдера, git push --force или rm -rf.

В облачных сервисах вроде Replit и Lovable агент работает на их стороне, но принцип тот же: ему доступно всё, что позволяют подключённая к проекту база и интеграции.

Принципы

Минимальные права. Каждый токен даёт минимум операций над минимумом ресурсов. Токен для настройки DNS не должен уметь удалять базы.
Dev и prod разделены. Разные базы, разные ключи, а лучше и разные проекты или аккаунты у провайдера.
В окружении агента нет продакшн-ключей. Изменения на продакшене проходят через CI или через вас.
Токены узкие и короткоживущие. Если агенту нужен токен, он получает его на один проект и одно окружение, со сроком жизни в несколько дней.
Разрушительные операции подтверждает человек. Сюда относятся удаление и очистка таблиц, удаление томов, сервисов и бакетов, force push, миграции на общих базах.
Бэкапы хранятся там, где их не удалить тем же ключом. В PocketOS один токен снёс и данные, и их резервные копии.
Результат проверяете вы. Сводка агента о сделанном остаётся утверждением, пока вы не посмотрели сами на дифф, базу и деплой.

Настройка по шагам

1. Посмотрите, что агент видит сейчас

Откройте терминал в папке проекта и найдите всё, что похоже на ключи:

grep -rnE "(TOKEN|SECRET|API_KEY|DATABASE_URL|PASSWORD)" \
  --exclude-dir=node_modules --exclude-dir=.git .

Затем выпишите CLI, в которые вы залогинены, и MCP-серверы, подключённые в редакторе. Для каждого ключа запишите, что он умеет. Если не можете понять, считайте, что у него полный доступ к аккаунту.

2. Уберите продакшн-ключи с машины, где работает агент

Удалите продакшн-значения из .env-файлов в репозитории и из профиля шелла. Храните их в настройках секретов хостинга или в менеджере паролей. Разлогиньтесь из CLI провайдеров, которые нужны только для продакшена (railway logout, vercel logout и так далее), и логиньтесь заново только под конкретную ручную задачу. Все токены из шага 1, которые хоть раз попадали в git, перевыпустите.

3. Дайте агенту отдельное dev-окружение

Заведите отдельную базу для разработки, а если провайдер позволяет, то и отдельный проект или окружение. Наполните её тестовыми данными или обезличенной копией. .env агента указывает только туда. Если агент сломает dev-базу, вы пересоздадите её из seed-скрипта и заодно убедитесь, что скрипт рабочий.

4. Выдавайте узкие токены под задачу

Большинство хостингов и облачных баз позволяют создать токен, ограниченный командой, проектом или окружением, а некоторые позволяют задать срок действия. Выбирайте самый узкий вариант, называйте токен по назначению (например, agent-dev-2026-09) и удаляйте его, когда работа закончена. Если провайдер выдаёт только токены на весь аккаунт, такой токен агенту не давайте совсем.

5. Для отладки используйте роль базы только на чтение

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

CREATE ROLE agent_ro LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE app TO agent_ro;
GRANT USAGE ON SCHEMA public TO agent_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public
  TO agent_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO agent_ro;
ALTER ROLE agent_ro
  SET default_transaction_read_only = on;

Строку подключения с этой ролью отдавайте агенту. К продакшену подключайте её, только если вы готовы к тому, что агент прочитает реальные данные пользователей. Обычно для отладки хватает dev-базы и логов продакшена.

6. Включите подтверждение команд и подумайте о песочнице

Большинство агентов для кода умеют спрашивать разрешение перед запуском команды в шелле и позволяют вести список команд, которые выполняются без вопросов. Разрешите рутинные вещи: тесты, линтеры, git status. Деплой, клиенты баз данных, CLI провайдеров и всё, где есть delete, drop или --force, оставьте на подтверждение. Перед тем как нажать «разрешить», прочитайте команду целиком, включая хост и проект, к которым она обращается.

Для более строгой изоляции запускайте команды агента в контейнере, куда смонтирована только папка проекта. Тогда домашняя папка и логины CLI ему не видны:

docker run -it --rm -v "$PWD":/work -w /work node:22 bash

Того же можно добиться отдельным пользователем в системе или облачным dev-окружением.

7. Проверьте MCP-серверы так же, как ключи

Для каждого подключённого MCP-сервера выясните, под каким аккаунтом он работает и какие инструменты открывает. Серверы баз данных направьте на dev или на роль только для чтения. Те, что в текущем проекте не нужны, отключите.

8. Уберите бэкапы из зоны досягаемости

Автоматические бэкапы провайдера оставьте, но добавьте ещё одну копию, которую не смогут удалить ни ключи приложения, ни ключи агента. Например, pg_dump по расписанию в объектное хранилище в другом аккаунте, с ключом, который может записывать, но не удалять. Во многих хранилищах это настраивается через политики бакета, версионирование или object lock. Один раз восстановитесь из этой копии, чтобы убедиться, что она рабочая.

9. Пускайте изменения на продакшен через пайплайн

Агент открывает pull request. CI прогоняет тесты и деплоит из основной ветки, используя секреты, которые хранятся в CI. Миграции запускает CI или вы сами, после того как прочитали их. Продакшен-токен агенту в этой схеме не нужен.

Чек-лист

На машине агента нет продакшн-ключей: ни в репозитории, ни в .env, ни в профиле шелла.
CLI провайдеров с доступом к продакшену разлогинены или недоступны агенту.
Агент работает с отдельной dev-базой и dev-проектом.
Каждый токен, доступный агенту, ограничен одним проектом и окружением, у него есть владелец и срок действия.
Для отладки агент подключается к базе ролью только на чтение.
Разрушительные команды, деплой и миграции требуют вашего подтверждения.
Подключённые MCP-серверы смотрят на dev или используют ключи только для чтения.
Хотя бы одну копию бэкапа нельзя удалить ни одним ключом приложения или агента, и восстановление из неё проверено.
Деплой на продакшен идёт через CI из проверенных pull request.

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

Как сформулировать агенту инфраструктурную задачу

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

Добавь в таблицу users колонку last_login_at и заполняй её при входе пользователя.

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

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

Когда агент сообщит, что закончил, пройдитесь по критериям сами. Откройте миграцию и прочитайте её. Запустите тесты. Сделайте запрос к dev-базе и убедитесь, что колонка есть и заполняется. Если агент пишет, что операция не удалась или её нельзя отменить, перепроверьте это независимо, прежде чем что-то предпринимать. В случае с Replit откат, который агент назвал невозможным, сработал.

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