Как не пускать бота в прод: безопасный контур до автоматизации
Хороший черновик кружит голову: «раз уж умеет — пусть сразу в прод». Так появляются лишние деплои, чужие письма и ночные откаты. Прод — не уровень сложности для бота. Это отдельный режим с минимальными правами, ручным approval, тестовыми данными и планом отката.
Мощное устройство удобно, но ключи от серверной не выдают «потому что купили» — та же логика, что у айфона в мире ИИ. База: что такое Grok Bot, первый час, безопасный первый контур, официально x.ai/bot и Grok Bot 101.
Ниже — что считать продом, пять слоёв контура, процесс «бот → человек → прод», запреты и чеклист допуска. Без обещания «безопасности по умолчанию».
Что считается продом
Составьте свой список — он часто шире, чем «только Kubernetes». В прод обычно входит всё, что сразу видит внешний пользователь или двигает деньги и права:
- боевые сайты, CMS, магазины;
- платежи, биллинг, счета;
- клиентские и персональные данные;
- права доступа, SSO, админки;
- DNS, прод-базы, очереди;
- публикации «в эфир»;
- любые необратимые удаления в боевых системах.
Если сомневаетесь — считайте продом, пока не доказали обратное тестовым контуром.
Пять слоёв безопасного контура
Тестовые данные
Синтетика, staging, копия без секретов. Не «чуть-чуть прод, но аккуратно».
Минимальные права
Только то, что нужно для одной задачи. Временные доступы. Один контур. Не admin «на всякий».
Черновик или diff вместо применения
Бот готовит план, патч, список команд, отчёт. Применение — отдельный шаг человека официальным способом (CI, PR merge, панель, которую вы контролируете).
Approval
Финальное действие ждёт человека. Особенно платежи, публикации, удаления, права, прод. См. смысл паузы в рабочих процессах выше и в мандате при создании бота.
Откат и журнал
Как вернуть назад за N минут. Кто подтвердил. Что изменилось. Без журнала «допуск в прод» — лотерея.
| Слой | Вопрос | Если нет |
|---|---|---|
| Тест-данные | Где безопасная копия? | Не трогаем бой |
| Права | Зачем этот доступ? | Режем до минимума |
| Черновик | Что смотрим глазами? | Нет допуска |
| Approval | Кто жмёт финал? | Стоп |
| Откат | Как откатить? | Стоп |
Рабочий процесс «бот → человек → прод»
- Бот получает узкую задачу и разрешённые источники.
- Формирует артефакт: diff, план миграции, чеклист изменений, тестовый отчёт.
- Объясняет, что изменится и какие риски.
- Ответственный проверяет файлы, зависимости, адрес назначения, последствия.
- Только после подтверждения человек применяет изменения своим контролируемым способом.
- Неопределённость или ошибка = остановка, а не «ещё один прогон наугад».
Повторяемые заготовки ролей — в кейсах. Первую победу без прода закройте через первый час.
Что запретить сразу
- самостоятельные платежи и «проверь биллинг заодно»;
- удаление и очистку «чтобы освободить место»;
- выдачу новых прав и шаринг доступов;
- секреты, пароли, 2FA-коды в чате и промпте;
- публикацию без ревью;
- вход по общему паролю / чужому аккаунту;
- обход защит входа — не обсуждается.
Ключи не живут в мандате. Коды 2FA вводит человек. Покупка чужих аккаунтов — нет.
Если нужен объём рук на подготовку артефактов — Heavy считайте как ФОТ многорукого / зарплату, не как «купил — значит можно в прод».
Чеклист допуска
Если любого пункта нет — задача остаётся вне прода.
- Назначен владелец допуска
- Scope описан одной страницей (что трогаем / что нет)
- Права минимальные и временные
- Есть тестовый прогон на небоевых данных
- Артефакт — черновик/diff, не «уже применено»
- Approval на финал включён и понятен
- План отката записан и проверен хотя бы устно
- Журнал действий доступен команде
- Результат принят человеком, не «бот сказал ок»
- Нет секретов в промптах и тредах
Командный хаос прав лечится порядком ролей, не отключением контроля: см. playbook команды из 5 ботов и честные фейлы первой недели.
Пример границы: репозиторий и CMS
Репозиторий: бот может готовить ветку и описание PR в тестовом форке или с правами без merge в main. Merge, теги релиза и force-push — человек. CMS: бот собирает черновик страницы в staging; публикация в бой — только после ревью и approval. CRM: бот готовит список правок полей; массовое изменение боевых карточек без теста — стоп.
Так вы не «запрещаете пользу», а разделяете подготовку и применение. Именно это снижает стоимость ошибки, пока мандат ещё учится. Когда процесс стабилен, права расширяют точечно и временно — с журналом и откатом, а не «выдали admin навсегда».
Если срочность давит («надо вчера»), всё равно оставляйте черновик: быстрее откатить плохой план, чем плохой прод. Срочность — аргумент для человека на дежурстве, не для снятия слоёв контура.
Ещё один якорь: секреты и токены живут в официальных механизмах доступа продукта, не в тексте мандата и не в shared-треде. Бот, который «попросил ключ в чат», должен получить отказ и переписанный scope.
FAQ
Можно ли использовать Grok Bot в проде? Только после отдельной проверки доступа, approval, теста и отката. Универсального «можно всем» нет.
Что бот должен делать вместо изменения прода? Готовить план, diff, черновик, тестовый отчёт или список команд для проверки человеком.
Какие права дать сначала? Минимально необходимые, временные, ограниченные одним контуром.
Нужен ли approval для Routine? Для внешних и необратимых действий — да. Финальный шаг человеку.
Что делать, если бот просит секрет? Остановить задачу. Секреты в чат не отправлять. Перестроить доступ официально.
Когда считать Heavy? Если нужна большая работа и несколько параллельных рук — как ФОТ, не как чатовая подписка.
Что сделать сейчас
- Возьмите текущую «почти продовую» задачу и попросите только план или diff.
- Пройдите чеклист допуска; любой пробел = стоп.
- Сверьте день-1 периметр с безопасным первым контуром.
- Старт и UI: x.ai/bot, Grok Bot 101, /start.