Как давать Codex доступы к рабочим сервисам и не открыть лишнее

Когда Codex работает только с одним файлом, вопрос доступа кажется простым. Открыли папку, дали задачу, посмотрели результат. Но как только агент начинает помогать в реальном проекте, появляется новая зона ответственности: к каким сервисам он имеет доступ, что может менять, куда может отправлять данные и где обязан остановиться.

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

В документации OpenAI по sandboxing Codex описывается через границы: где он может читать, где редактировать, когда требуется подтверждение. В разделе про agent approvals and security отдельно показаны режимы, где действия внутри границы идут быстрее, а выход за нее требует контроля. Для владельца бизнеса это не техническая мелочь. Это язык управления агентом.

Доступ не должен быть "вообще"

Главное правило: Codex получает доступ не к компании, а к задаче. Не "вот тебе весь Google Drive", а "вот папка с исходниками для коммерческого предложения". Не "вот админка сайта", а "вот черновик страницы и право предложить изменения". Не "вот все пароли", а "вот способ прочитать нужный отчет без права менять настройки".

Если доступ описан слишком широко, Codex будет честно пытаться помочь в рамках того, что видит. Но ответственность за рамку лежит на человеке. Агент не должен сам догадываться, что ему нельзя трогать платежи, менять DNS, удалять файлы, отправлять письма клиентам или публиковать на сайте. Это должно быть написано до запуска.

Минимальная карта доступов выглядит так:

Эта таблица не про паранойю. Она про снятие тумана. Codex работает лучше, когда понимает, где его свобода, а где граница.

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

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

Рабочая постановка может выглядеть так:

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

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

Что проверяет не-программист

Владелец проекта не обязан разбираться в sandbox, CLI-флагах и конфигурационных файлах. Но он обязан понимать четыре вещи.

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

Вторая: какие действия разрешены. Читать - одно. Редактировать - другое. Публиковать - третье. Отправлять наружу - четвертое. Эти действия нельзя складывать в одно слово "сделай".

Третья: где стоп-сигнал. Например: "если нужно отправить письмо, остановись"; "если нужно менять live-сайт, остановись"; "если найден секрет или персональные данные, остановись"; "если источник не публичный, остановись".

Четвертая: как отзывается доступ. После задачи полезно спросить Codex: "Какие доступы использовались, какие больше не нужны, где остались следы работы?" Это простой вопрос, но он превращает доступ из вечного разрешения в временную операцию.

Почему approvals не заменяют карту прав

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

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

Простая карточка доступа

Перед запуском серьезной задачи можно завести короткую карточку:

Эта карточка хороша тем, что ее понимает не только разработчик. Ее может заполнить руководитель, редактор, консультант, владелец продукта. Codex уже переведет ее в рабочие действия.

Вывод

Codex становится "must have" не тогда, когда ему открыли все двери. Он становится полезным, когда доступы выданы осмысленно: под задачу, с границами, с понятным стоп-сигналом и с человеческим решением на опасных шагах.

Если коротко: не давайте Codex общий ключ от проекта. Дайте ему карту. Где работать, что можно менять, что только читать, где остановиться и какой артефакт вернуть. Тогда агент получает достаточно свободы, чтобы делать работу, но не получает права молча превращать помощь в риск.