Песочница AI-агента в Apple Container на macOS 26

По состоянию на 17 августа 2026 года в официальном репозитории Apple Container последним опубликованным релизом указан 1.2.2; сам проект требует Apple Silicon и поддерживает macOS 26. Это позволяет использовать Apple Container как отдельную лёгкую виртуальную машину для каждого AI-агента, но не превращает его в готовую систему безопасности. В первую неделю мы рекомендуем запускать только тестовый репозиторий, не монтировать домашний каталог, ограничить сетевые направления и проверять разрушительные сценарии. Если потребуется Linux-мультитенантность и распределённое выполнение, лучше сохранить тот же OCI-образ и перейти на Firecracker, а не пытаться масштабировать Mac-схему за пределы её назначения.

Официальные требования Apple Container и список релизов подтверждают поддержку Apple Silicon и macOS 26, а страница релизов проекта показывает актуальную ветку 1.2.x.

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

Последнее обновление: 17 августа 2026 года. Данные сверены с официальным репозиторием Apple Container, документацией командной строки, документацией Firecracker и публичными материалами OpenAI.

Сначала определите, какую угрозу закрывает Apple Container

Apple Container подходит для узкой, но важной задачи: дать AI-агенту Linux-среду с отдельной виртуализационной границей, где он сможет устанавливать зависимости, запускать тесты и менять рабочую копию проекта. В официальном описании проект назван инструментом для запуска Linux-контейнеров внутри лёгких виртуальных машин на Mac, оптимизированным для Apple Silicon. Это принципиально отличает его от обычной схемы Docker Desktop, где контейнеры также работают через виртуальную машину на macOS, но пользовательская модель и границы доступа могут быть другими.

Нужно разделять четыре уровня риска:

1. Файловый доступ. Агент может выполнить rm, перезаписать конфигурацию, изменить скрипт сборки или прочитать случайно примонтированный каталог. Виртуальная машина не делает безопасным каталог, который мы сами экспортировали внутрь неё с правом записи.
2. Сетевой выход. Изолированный процесс всё ещё может отправлять исходный код, журналы, токены или результаты выполнения во внешний сервис, если сеть оставлена открытой.
3. Секреты. Переменная окружения, SSH-сокет, файл конфигурации CLI или общий каталог с ключами становятся доступными агенту, если их передать без ограничения области и срока действия.
4. Жизненный цикл. Остановленный контейнер не означает автоматически удалённые тома, образы, логи и экспортированные результаты. Для одноразовых задач нужно проверять, что именно осталось на хосте.
5. Человеческое одобрение. Команда, которая удаляет большой каталог, меняет инфраструктуру или публикует пакет, должна проходить через внешний контроль, даже если процесс запущен внутри виртуальной машины.

Именно поэтому Apple Container — это слой исполнения, а не вся политика безопасности. В публичных материалах OpenAI изоляция, ограничение инструментов и контроль среды рассматриваются как отдельные элементы защиты, а не как замена друг другу. Материал OpenAI о критически важных кибернетических возможностях и контролях полезен здесь именно как ориентир по модели угроз, а не как описание возможностей Apple Container. События вокруг Astra можно учитывать только как фон спроса: на 17 августа 2026 года эта модель остаётся непредставленной публично, поэтому мы не используем её предполагаемые характеристики в техническом выборе.

Выбор среды зависит от границы доверия и масштаба

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

Firecracker использует KVM и запускает отдельные microVM, сочетая виртуализационную границу с небольшим набором устройств и управляемым API. Официальная документация также требует Linux и доступ к /dev/kvm, поэтому Firecracker не является прямой заменой Apple Container на macOS. Руководство Firecracker по подготовке среды описывает эти условия.

Наше решение по умолчанию такое:

• для личного Apple Silicon и первых итераций — Apple Container;
• для удалённого Mac с небольшим числом независимых задач — Apple Container плюс внешний диспетчер, журналирование и контроль доступа;
• для Linux-кластера, недоверенных арендаторов и массовых параллельных запусков — Firecracker или другой microVM-слой;
• для задачи, которой нужны физические USB-интерфейсы, macOS-инструменты или Xcode на хосте, — отдельная схема с минимальным числом проброшенных ресурсов.

Проект agentkernel заявляет поддержку Apple Container на macOS 26 и Firecracker на Linux, но это декларация стороннего проекта, а не гарантия Apple. Поэтому его можно использовать как пример единого интерфейса задач, однако не следует считать его доказательством одинаковой безопасности всех бэкендов. Таблица бэкендов agentkernel разделяет Apple Containers, Docker/Podman и Firecracker.

Подготовьте хост, образ и безопасный откат

До первого запуска мы создаём отдельную тестовую область и фиксируем исходное состояние Mac. Это экономит время после неудачного обновления или ошибочной настройки сети.

Шаг 1. Проверьте платформу и версию системы

Выполните:

uname -m
sw_vers -productVersion

Для Apple Container ожидается Apple Silicon и macOS 26. Старую версию macOS нельзя описывать как равнозначный запасной путь: официальный репозиторий прямо предупреждает, что проект не поддерживает старые версии и обычно не рассматривает проблемы, которые нельзя воспроизвести на macOS 26.

После установки проверьте службу и версию:

container system start
container system status
container system version

Команды system status и system version присутствуют в официальном справочнике CLI. Справочник команд Apple Container нужно сверять с конкретным тегом релиза, потому что документация ветки main может опережать установленный пакет.

Шаг 2. Зафиксируйте релиз и способ возврата

Не устанавливайте обновление непосредственно перед важным экспериментом. Сначала запишите:

container system version
container system property list
container image list
container volume list
container network list

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

Шаг 3. Соберите минимальный OCI-образ

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

Пример базовой проверки:

container build --tag agent-test:local .
container image list

Образ должен собираться из воспроизводимого Dockerfile или Containerfile, а не из ручных изменений внутри уже работающего контейнера. Это важно при переносе на удалённый Mac: образ, параметры запуска и политика доступа должны генерироваться одинаково.

Шаг 4. Подготовьте одноразовый репозиторий

Сделайте копию проекта в отдельном каталоге:

mkdir -p "$HOME/agent-lab/input" "$HOME/agent-lab/output"
cp -R ./demo-project "$HOME/agent-lab/input/"

Внутри не должно быть настоящих ключей, production-конфигураций и рабочих веток, которые нельзя потерять. Если агент должен открыть pull request, на первом этапе замените этот сценарий локальным патчем и отчётом тестов.

Первый запуск должен быть максимально коротким

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

Официальный CLI поддерживает --read-only, --volume, --env, --network, --cpus, --memory, --tmpfs и --rm. Мы используем эти параметры как отдельные элементы политики, а не как набор флагов для копирования без проверки.

Пример ограниченного запуска:

container run \
  --name agent-once \
  --rm \
  --read-only \
  --volume "$HOME/agent-lab/input/demo-project:/workspace:rw" \
  --volume "$HOME/agent-lab/output:/results:rw" \
  --tmpfs /tmp \
  --network default \
  agent-test:local \
  sh -lc 'cd /workspace && ./run-agent.sh'

Здесь:

• корневая файловая система контейнера монтируется только для чтения;
• изменяемым остаётся лишь тестовый проект;
• результаты выводятся в отдельный каталог;
• временные файлы уходят в tmpfs;
• домашний каталог, ~/.ssh, ~/.config и сокет SSH-агента не передаются;
• --rm удаляет контейнер после остановки, но не заменяет проверку томов, образов и логов.

Параметр --read-only не делает автоматически доступными для записи все необходимые каталоги. Поэтому агент может завершиться ошибкой при попытке записи в /tmp, кэш пакетов или каталог сборки. Лучше заранее определить несколько временных путей, чем разрешать запись всему корневому дереву.

После завершения проверьте:

container list --all
container volume list
container image list
find "$HOME/agent-lab/output" -maxdepth 2 -type f -print

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

Apple Container и доступ к файлам Mac требуют явной границы

Apple Container может предотвратить прямой доступ агента к файлам хоста, которые не были экспортированы внутрь гостевой среды. Но если мы монтируем /Users/имя-пользователя или весь проект с правом записи, то сами расширяем эту границу до уровня, опасного для автоматического процесса.

Практическое правило для рабочей папки:

• /workspace/input — только чтение, если агент анализирует исходные данные;
• /workspace/project — отдельная копия с правом записи;
• /results — только экспорт патча, отчёта и журнала;
• /tmp — временная область;
• секреты — отдельный механизм инъекции на время задачи;
• домашний каталог пользователя — никогда не монтировать по умолчанию.

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

Проверка должна включать попытку чтения типичных путей:

container run --rm \
  --read-only \
  --volume "$HOME/agent-lab/input/demo-project:/workspace:rw" \
  agent-test:local \
  sh -lc 'for p in /Users /root/.ssh /workspace; do
    printf "%s: " "$p"
    test -e "$p" && echo visible || echo hidden
  done'

Результат visible ещё не означает, что данные доступны для чтения: нужно отдельно проверять права. Но неожиданная видимость каталога — повод остановить эксперимент и пересмотреть образ.

Сеть и ключи нужно ограничивать в первый час

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

1. API модели;
2. реестр OCI-образов;
3. репозиторий пакетов;
4. система контроля версий;
5. служебный endpoint для журналов.

Мы не объединяем их в один «разрешённый интернет». Для каждой категории фиксируем домен, порт, направление и причину доступа. Если проекту не нужна сеть после установки зависимостей, агент запускается без неё или в отдельной сети с внешним фильтром.

Важно учитывать и скрытые каналы:

• DNS-запросы;
• загрузку скриптов установщика;
• Git hooks;
• постинсталляционные сценарии пакетов;
• отправку диагностических архивов;
• публикацию артефактов через CLI.

Ключи должны быть короткоживущими, ограниченными одной задачей и отозванными после завершения. Не помещайте секреты в Dockerfile, OCI-слои, шаблон .env, общий том или командную строку, если журнал запуска может их сохранить.

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

Перенос на удалённый Mac начинается с одинакового образа

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

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

1. Соберите образ с фиксированным тегом и сохраните его digest.
2. Передайте образ в удалённый реестр или экспортируйте OCI-архив.
3. Создайте на удалённом Mac отдельные каталоги для входных данных и результатов.
4. Повторите container system version и проверку архитектуры.
5. Запустите тот же контейнер с теми же монтированиями.
6. Выполните одинаковый набор тестов и сравните логи.
7. Добавьте тайм-аут, остановку по превышению лимита и удаление неуспешной задачи.

Удалённый Mac дополнительно требует:

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

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

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

Firecracker нужен не после первой ошибки, а при изменении масштаба

Переход с Apple Container на Firecracker оправдан, когда требования уже не соответствуют Mac-узлу:

• задачи принадлежат разным недоверенным пользователям;
• нужно размещать много независимых Linux-сред на одном хосте;
• требуется Linux KVM и автоматическое создание microVM;
• нужны квоты CPU, памяти, дисковых операций и сетевого трафика;
• выполнение должно распределяться между узлами;
• Mac нужен только для разработки, а production-исполнение должно работать в Linux-кластере.

Firecracker запускает каждую microVM отдельным процессом и использует KVM; официальная документация описывает собственное гостевое ядро, rootfs, виртуальные устройства, сетевые ограничения и jailer. Поэтому перенос требует не только сменить команду запуска: нужно подготовить Linux-хост, /dev/kvm, ядро, rootfs, сетевую модель, журналирование и уничтожение VM. Официальный репозиторий Firecracker подчёркивает его назначение для безопасного мультитенантного выполнения.

Лучший способ сохранить инвестиции в Mac-разработку — стандартизировать интерфейс задания: образ, входной каталог, результат, переменные, сетевую политику и код завершения. Тогда Apple Container остаётся локальным и удалённым путём для Mac, а Firecracker становится Linux-бэкендом с той же логикой задачи.

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

Обычный тест «агент исправил код и прошёл тесты» недостаточен. На первой неделе мы проверяем, что произойдёт при ошибке, остановке, подозрительной команде и частично выданном секрете.

Минимальный набор испытаний:

Выход за пределы рабочей папки

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

Чтение ключей

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

Несанкционированная сеть

Запускается запрос к адресу, которого нет в разрешённом списке. Проверяется DNS, TCP-соединение, повторные попытки и запись события в журнале.

Исчерпание ресурсов

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

Прерывание и восстановление

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

Полное удаление

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

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

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

Итоговое решение для текущей схемы и Mac-среды

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

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

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