Как настроить командную песочницу Cursor Agent в 2026 году? Схема Apple Container по ролям

Не выдавайте всей команде одну широкую конфигурацию: для обычной разработки оставьте нативную песочницу Cursor, зависимости и рискованные сценарии переносите в Apple Container, а подпись, производственные ключи и публикацию сохраняйте за ручным подтверждением в отдельной среде Mac. Такой подход и есть базовая настройка командной песочницы Cursor Agent по ролям, а не попытка одинаково ограничить или одинаково расширить права всех сотрудников.

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

Решение на первую неделю: разделите права до выдачи доступа

В первый рабочий день соберите список ролей и запретите общий профиль «можно всё». На второй день закрепите базовый режим Cursor для повседневных задач. Затем отделите задачи, которые должны запускаться в Apple Container, от операций, для которых потребуется независимый Mac с ручным подтверждением. К концу недели у каждого исключения должны быть владелец, причина, срок пересмотра и сценарий отката.

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

Официальные режимы запуска Cursor Agent позволяют выбрать, когда команда разрешает автоматическое выполнение, а когда требует подтверждения. Документация по Terminal и защитным механизмам Cursor нужна для проверки поведения команд, запросов разрешений и защитных ограничений. Эти функции образуют первый уровень контроля; Apple Container — не замена им, а дополнительная граница для отдельных сценариев.

Базовый профиль личного разработчика

Личный разработчик часто первым просит постоянный режим без подтверждений: иначе Agent не сможет быстро создать файл, запустить проверку или исправить тест. Но такой режим не должен давать доступ к произвольной файловой системе и сети. Безопасная повседневная область включает:

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

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

В Cursor следует разделить три класса действий. Генерация и редактирование исходников могут выполняться в более свободном режиме внутри рабочей области. Статический анализ и тесты разрешаются после проверки команд. Установка пакетов, удаление файлов, изменение конфигурации оболочки и сетевые запросы за пределы списка требуют отдельного подтверждения. Официальные поля и модель ограничений нужно сверять с актуальной справкой по sandbox.json, поскольку конфигурация является политикой доступа, а не универсальным «режимом доверия».

На этом уровне Apple Container обычно не нужен для каждой команды: постоянное помещение обычного редактора в Linux-среду добавит сложность и может сломать нативные инструменты macOS. Но как только задача затрагивает неизвестный установочный скрипт или массовую перезапись, разработчик должен перейти к профилю сопровождаемой изоляции.

Проектный профиль для участника функциональной разработки

Участник команды должен работать с текущим репозиторием, а не с Mac владельца. Здесь важно не смешивать три источника правил:

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

Перед внедрением проверьте в официальной документации Cursor имена полей, допустимые значения и правила объединения. Не переносите пример из старого обсуждения без проверки: политика может выглядеть корректно, но не применяться из-за неверного расположения файла или несовместимого ключа.

Логика проектного профиля должна быть такой:

• рабочий каталог репозитория — доступен для чтения и записи;
• каталог сборочных результатов — доступен для записи, но очищается отдельной процедурой;
• общие схемы, документация и эталонные файлы — только для чтения;
• реестры пакетов, зеркала и тестовые сервисы — разрешены по конкретным доменам;
• домашний каталог — не монтируется;
• каталоги с SSH-ключами, облачными токенами, файлами окружения и связкой ключей — запрещены;
• произвольные внешние URL и команды с повышением привилегий — требуют ручного решения.

Нельзя считать безопасным монтирование всего ~/Developer только потому, что там лежат проекты. В соседней папке могут находиться незакоммиченные секреты, конфигурации CI или экспериментальный код другого продукта. Лучше передать Agent один путь проекта и отдельный временный путь для результатов.

Пример политики следует хранить без секретов и производственных адресов. Схематично она может выглядеть так:

{
  "filesystem": {
    "read": [
      "/work/repository",
      "/work/shared-docs"
    ],
    "write": [
      "/work/repository",
      "/work/build-cache",
      "/work/tmp"
    ]
  },
  "network": {
    "allowedDomains": [
      "registry.example.invalid",
      "packages.example.invalid"
    ]
  }
}

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

Рабочая зона сопровождающего репозиторий

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

Рекомендуемая цепочка выглядит так:

1. Создайте временную копию репозитория без локальных секретов и файлов окружения.
2. Проверьте список входных файлов и удалите всё, что не требуется для операции.
3. Запустите Linux-нагрузку в Apple Container на Mac с Apple Silicon и macOS 26, если это соответствует требованиям текущей стабильной версии проекта. Официальное описание Containerization от Apple и репозиторий Apple Containerization описывают архитектурную основу такого запуска.
4. Смонтируйте копию проекта в рабочий путь контейнера, а каталог результата — отдельным доступным для записи томом.
5. Оставьте сеть выключенной, если операция не требует загрузки; при необходимости разрешите только утверждённые домены.
6. Выполните одну операцию, сохраните журнал и сравните результат с ожидаемым набором файлов.
7. Перенесите изменения обратно через проверку diff, а контейнер и временную копию удалите после завершения срока хранения.

Командный шаблон должен отражать именно временный характер среды:

#!/bin/sh
set -eu

SOURCE_DIR="${1:?укажите путь к временной копии}"
OUTPUT_DIR="${2:?укажите путь для результата}"

container run --rm \
  --mount "type=bind,source=${SOURCE_DIR},target=/workspace" \
  --mount "type=bind,source=${OUTPUT_DIR},target=/output" \
  --workdir /workspace \
  --network none \
  <утверждённый-образ> \
  sh -lc '<команда задачи>'

Перед использованием сверяйте синтаксис container run, параметры томов и сетевой режим с документом Apple Container о командах запуска и руководством по сети Apple Container. В шаблоне нет команды удаления, публикации или изменения хоста: её нельзя добавлять «для удобства» без отдельного согласования.

Apple Container запускает Linux-рабочие нагрузки, а не приложения macOS. Поэтому Xcode, симулятор, связка ключей, нативная подпись и инструменты публикации не становятся доступными автоматически. Описание архитектуры Containerization полезно использовать для проверки этой границы: контейнерная изоляция подходит для скриптов и воспроизводимых Linux-инструментов, но не превращает контейнер в полный Mac.

Профиль инженера сборки: кеш, зависимости и сетевые исключения

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

Разделяйте ресурсы по назначению:

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

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

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

Apple Container поддерживает отдельные монтирования и режимы доступа; перед внедрением проверяйте официальное руководство по томам. Нельзя приписывать контейнеру измеримый выигрыш в скорости без официального источника или теста вашей команды: изоляция и воспроизводимость не равны гарантированному ускорению.

Публикация и подпись остаются отдельным контуром

Код можно подготовить и проверить в изолированной среде, но сертификат, закрытый ключ, связка ключей, производственный токен и право отправить сборку должны быть исключены из обычной сессии Cursor Agent. Даже контейнер с ограниченными томами не решает проблему, если секрет был передан в переменную окружения, журнал или доступный процесс.

Разделите процесс на четыре действия:

• подготовка исходников и конфигурации — в профиле разработчика или контейнере;
• сборочная проверка и тесты — в изолированной среде инженера сборки;
• подпись — на контролируемом Mac после просмотра diff и артефакта;
• публикация — отдельное действие с ручным подтверждением и журналированием.

Для подписи и публикации нужен владелец, который понимает, какой артефакт разрешено отправлять и куда. Agent может подготовить команду или список изменений, но не должен самостоятельно получать производственный ключ, искать сертификат в связке ключей или отправлять пакет после автоматического «исправления» сборки. Linux-контейнер не заменяет Xcode, нативные Apple-инструменты и связанные с ними разрешения.

Если команда часто публикует приложения, независимая среда Mac может быть оправдана не ради «большей мощности», а ради разделения доверия. На рабочем ноутбуке одновременно находятся исходники, личные данные и локальные ключи; отдельный Mac с ограниченным доступом позволяет связать публикацию с конкретной задачей и журналом. В руководстве по проверке интеграций App Store Connect мы также рассматриваем контроль публикационных процессов и точки, где автоматизация не отменяет проверки человеком.

Решающее дерево для выбора уровня изоляции

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

• [ ] Задача изменяет только текущую рабочую копию, не читает секреты и не требует доступа к системным каталогам?
  Если да, выбирайте нативную песочницу Cursor. Если нет, переходите к следующему условию.

• [ ] Задача запускает миграцию, генератор, массовую перезапись, непроверенный установочный сценарий или код из временной копии?
  Если да, используйте Apple Container с отдельной копией репозитория, минимальными томами и отключённой сетью либо списком конкретных доменов. Если нет, возвращайтесь к базовому профилю и не расширяйте права заранее.

• [ ] Нужны пакетный реестр, тестовый сервис или кеш сборки?
  Если да, выдавайте только отдельные пути и утверждённые домены, фиксируя владельца и срок действия исключения. Если кеш или сеть не обязательны, сначала запускайте задачу в режиме без них.

• [ ] Нужны Xcode, симулятор, связка ключей, сертификат, производственный токен или отправка артефакта?
  Если да, не используйте обычный сеанс Agent и не пытайтесь решить задачу контейнерным монтированием. Перенесите подпись и публикацию в контролируемую среду Mac с ручным подтверждением.

• [ ] Несколько сотрудников должны одновременно выполнять рискованные операции или работать с чувствительным репозиторием?
  Если да, оцените независимые облачные Mac-среды. Если нет, временного контейнера или отдельного локального профиля может быть достаточно.

• [ ] Требуются физический интерфейс, постоянная тяжёлая нагрузка или непрерывная привязка к одному рабочему месту?
  Если да, сравните отдельное оборудование с арендой: временная удалённая среда не является универсальной заменой локальному Mac.

Такой список превращает абстрактную безопасность AI Agent в воспроизводимое решение. В нём отдельно учитываются не только роль сотрудника, но и конкретное задание, срок доступа, тип ресурса и последствия ошибки.

Командная матрица и ответственность за исключения

Платформенный или security-ответственный должен утвердить не только права, но и владельца каждого перехода на более строгий уровень. Минимальная матрица распределяется так:

• разработчик получает рабочую копию, тесты и статический анализ; запрещены домашний каталог, секреты и произвольная сеть; при рискованном скрипте он передаёт задачу сопровождающему;
• функциональный участник работает только с текущим репозиторием и разрешёнными доменами; запрещены общие каталоги и ключи; при необходимости массовой операции используется временный контейнер;
• сопровождающий получает контейнерную среду для миграций и генераторов; запрещены производственные токены и прямой доступ к публикации; результат проходит просмотр diff;
• инженер сборки получает выделенные кеши, каталоги зависимостей и сетевые исключения; запрещён полный доступ к домашней папке; при расширении сети задача эскалируется владельцу платформы;
• специалист по подписи работает в отдельном контролируемом Mac-контуре; Agent готовит артефакт, но не получает ключ и не отправляет сборку без подтверждения;
• security-ответственный владеет политиками, сроками исключений, журналами и процедурой отката.

Порядок управления политикой стоит закрепить в репозитории инфраструктуры:

1. Каждой политике присваивается версия и владелец.
2. Любое расширение прав сопровождается задачей и сроком пересмотра.
3. Раз в установленный командой период проверяются неиспользуемые домены, пути и токены.
4. Разрушительные тесты выполняются только на копии с заранее описанным восстановлением.
5. После инцидента ответственный отзывает исключение, сохраняет журнал и обновляет профиль, а не просто добавляет ещё один запрет.
6. Перед изменением версии Cursor или Apple Container проверяются поля конфигурации, сетевое поведение, монтирования и совместимость с macOS 26.

Для сложных команд полезно вынести выбор между локальным Mac, Apple Container и удалённой машиной в отдельное решение с расчётом стоимости владения. В материале о командном управлении средами Mac можно продолжить оценку распределения доступа, а актуальные варианты аренды следует сопоставлять с длительностью проекта, требованиями к физическим инструментам и числом параллельных пользователей, а не только с ценой месяца.

Важное ограничение: Apple Container — это Linux-изоляция на Mac, а не универсальная оболочка для macOS. Если в задаче появляется ключ из связки ключей, Xcode или production-токен, контейнерный профиль нужно остановить и передать операцию в отдельный контролируемый контур.

Частые вопросы команды

Единый sandbox.json для всех участников

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

Дополнительный Apple Container для рискованных задач

Второй слой нужен, когда операция может выйти за пределы исходной рабочей копии или запускает код, которому нельзя доверять заранее. Это миграции, массовая генерация, сторонние установщики и эксперименты с чувствительным репозиторием. Передайте контейнеру временную копию, ограниченные тома и минимальную сеть. Для обычного редактирования и локальных тестов такой слой может только усложнить работу и не даст доступа к нативному Mac-инструментарию.

Кеши инженера сборки

Кеш и каталог зависимостей — разные ресурсы. Первый можно сделать доступным для записи, второй обычно безопаснее открыть только для чтения; оба пути должны быть отдельными от домашнего каталога. Разрешения сети задаются доменами реестров и тестовых сервисов, а не флагом «весь интернет». Если кеш устарел или сеть недоступна, сборка должна либо использовать зафиксированные локальные материалы, либо завершаться понятным отказом без расширения прав.

Секреты подписи и публикации

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

Если после заполнения этой матрицы выясняется, что сотрудникам постоянно нужны отдельные Mac, параллельные изолированные рабочие места или публикационный контур, сравните локальную схему с условиями аренды Mac. У локального варианта остаются три типичных недостатка: секреты соседствуют с повседневной разработкой, ресурсы трудно разделить между несколькими сотрудниками, а временный проект требует ручной подготовки и очистки каждой машины. Отдельная среда JexMac может быть разумнее именно для временного доступа, параллельных задач и вынесения рискованного исполнения с рабочих устройств — при этом физические интерфейсы и постоянная тяжёлая нагрузка по-прежнему нужно оценивать отдельно. Для запуска такого сценария используйте страницу заказа Mac-среды только после того, как роль, срок и границы доступа уже определены.

FAQ