Как принять Apple Container для AI Agent перед релизом в 2026 году?
Apple Container для AI Agent можно принимать к работе только после успешных проверок файловой границы, секретов, сети, ресурсов и полного восстановления после остановки; сам факт запуска задачи ничего не говорит о качестве изоляции. Для низкорисковых однопользовательских задач допустимо оставить dsh с локальной политикой или Docker, а при провале критического теста для недоверенного кода следует усиливать среду либо переходить к Firecracker на Linux/KVM.
Эта инструкция предназначена для платформенных инженеров, которые строят повторяемую среду на Apple Silicon. Специалистам по безопасности она поможет зафиксировать доказательства выхода за границы и утечки ключей. Руководителям команд — принять решение между локальным Mac, удалённой средой Mac и Linux microVM.
Последнее обновление: 22 августа 2026 года. Версии и границы совместимости сверены с официальным README Apple Container, журналом релизов, документацией dsh, Docker и Firecracker.
Три результата приёмки: выпускать, ограничить или менять среду
Приёмка должна заканчиваться не общим впечатлением, а одним из трёх статусов.
Можно выпускать. Все обязательные проверки завершены, отрицательные тесты действительно блокируются, секреты выдаются через ограниченный механизм, сеть подчиняется явной политике, а после остановки не остаются процессы, монтирования и временные данные. Такой статус всё равно относится к проверенному классу задач, а не ко всему возможному коду.
Только низкорисковые внутренние задачи. Запуск разрешается для доверенного пользователя, тестового репозитория или агента без доступа к чувствительным данным. Такой режим подходит для прототипирования и отладки, но не для произвольных инструкций из внешнего запроса, автоматического изменения production-кода или нескольких независимых арендаторов.
Не прошла. Хотя бы один критический тест показывает чтение хоста, доступ к секрету, неограниченный выход в сеть, неконтролируемое потребление ресурсов или неполное завершение. В этом случае нельзя компенсировать проблему формулировкой «агент работает». Для опасного кода безопаснее изменить архитектуру, чем отключить ограничение.
Каждый результат должен иметь пакет доказательств: идентификатор сборки, применённую конфигурацию, команду запуска, входные данные, системные журналы, результат вызова инструмента и запись о ручной проверке. Скриншот интерфейса без исходных логов — слабое подтверждение.
Первый рубеж: Apple Container, dsh и Docker дают разные границы
Платформа не должна принимать решение по названию технологии. Нужно зафиксировать фактический рубеж изоляции.
Apple Container строит рабочий процесс на лёгкой виртуальной машине Linux на Mac. Архитектурные сведения проекта описаны в документации Containerization. Это сильнее, чем простое ограничение процесса, но не означает автоматически, что любой том, сокет, сетевой маршрут или секрет настроен безопасно. Граница виртуальной машины не отменяет ошибок конфигурации вокруг неё.
В dsh локальный sandbox использует Seatbelt, bubblewrap и Landlock как доступные бэкенды; проект официально обозначен как developer preview. Конкретный результат зависит от выбранного backend и его параметров. Конфигурация локальной песочницы DeepSeek Harness также описывает custom runner. Это интерфейс расширения, а не готовый переключатель на Firecracker.
Docker удобен для воспроизводимых рабочих процессов, но контейнер разделяет ядро хоста. Seccomp, пользовательские пространства имён, capability-политики, read-only режим и точные монтирования должны проверяться отдельно. Официальная документация Docker по seccomp прямо связывает профиль системных вызовов с уменьшением поверхности атаки, но профиль не заменяет проверку секретов, сети и жизненного цикла.
Для приёмки полезно заранее записать ограничения:
- Файлы: какие каталоги разрешены, какие запрещены, доступны ли сокеты и устройства.
- Секреты: какие значения получает процесс и в какой момент.
- Сеть: какие имена и адреса разрешены, кто применяет блокировку.
- Ресурсы: какие лимиты действуют для памяти, CPU, диска и процессов.
- Жизненный цикл: что удаляется после завершения и кто подтверждает очистку.
Файлы: проверка выхода из рабочей области
Главная ошибка — протестировать только чтение исходного репозитория. Агенту нужно дать задания, которые имитируют вредоносный инструмент, а не обычную разработку.
Шаг 1. Зафиксируйте разрешённый каталог
Создайте отдельную рабочую область с уникальным маркером. В соседнем каталоге разместите другой маркер. В тестовой среде также создайте ложные файлы с названиями, похожими на конфигурации, ключи и журналы. Настоящие секреты в эту проверку не помещают.
Политика должна явно отвечать на вопросы:
- может ли процесс видеть родительский каталог;
- разрешено ли создание новых монтирований;
- доступен ли Unix-сокет управляющего сервиса;
- можно ли менять права и владельца файлов;
- сохраняется ли рабочая область после завершения.
Шаг 2. Проверьте обходы
Последовательно передайте агенту задания на чтение через абсолютный путь, .., символическую ссылку и жёсткую ссылку. Отдельно проверьте архивирование каталога и поиск по файловой системе. Успешным считается не ответ модели, а отказ системного вызова либо отсутствие запрещённого маркера в результате.
Проверка должна выполняться при каждом способе запуска. Политика dsh может отличаться от политики Apple Container, а Docker получает совершенно иной набор границ через --mount, права пользователя и capabilities. Одинаковый сценарий нужно прогнать на каждой конфигурации.
Шаг 3. Проверьте запись и восстановление
Попытка записи за пределами рабочей области должна завершаться отказом. Внутри разрешённого каталога нужно проверить, не получает ли агент возможность изменить сценарий запуска, конфигурацию политики или файл, который затем читается привилегированным процессом.
После удаления среды повторите поиск маркеров. Остаточные временные файлы, слои, кэш сборки или подключённые тома фиксируются как отдельный результат, а не прячутся под общим статусом «контейнер остановлен».
Секреты: не путайте отсутствие вывода с отсутствием доступа
AI Agent может получить данные не только через прямой cat. Доступ возможен через переменные окружения, диагностический endpoint, историю команд, кэш пакетов, журнал вызова инструмента, SSH-agent или вспомогательный процесс.
Шаг 4. Проведите тест с ложными ключами
В тестовую среду помещают нерабочие маркеры, например отдельные строки для API, SSH и конфигурационного файла. Агенту дают задания:
- вывести переменные окружения;
- найти файлы конфигурации;
- прочитать историю команд;
- перечислить сокеты и процессы;
- упаковать найденное в архив;
- передать данные через специально имитируемый инструмент.
Параллельно журналируется фактический системный доступ. Если модель утверждает, что не нашла ключ, но инструмент смог прочитать маркер, тест провален. Если секрет не виден агенту, но его получает дочерний процесс через наследуемое окружение, это также провал.
Долговременная передача чувствительного ключа с хоста — важный сигнал риска. Даже если ключ ограничен по правам, команда должна показать область действия, срок жизни, аудит и механизм отзыва. «Ключ нужен для запуска» не является достаточным обоснованием production-статуса.
Отдельно проверяются сборочные кэши. Они часто содержат исходные URL, токены загрузки, логи и артефакты предыдущих задач. После завершения процесса кэш либо очищается, либо маркируется как совместно доступный ресурс с понятной политикой.
Сеть: изоляция контейнера не является сетевым фильтром
Apple Container, Docker и локальные sandbox-политики не следует считать готовым межсетевым экраном только потому, что код запущен не на основном процессе. Приёмка должна показывать, где именно принимается решение о разрешении.
Шаг 5. Разделите направления доступа
Тестовая матрица должна включать:
- обычное исходящее соединение;
- DNS-запрос к разрешённому имени;
- DNS-запрос к запрещённому имени;
- обращение к loopback и адресу хоста;
- попытку доступа к частному адресу сети;
- запрос к метаданным облачной среды;
- соединение с локальным сервисом управления;
- передачу данных через разрешённый прокси.
Для каждого результата сохраняются DNS-журнал, сетевой журнал и запись политики. Если соединение просто «не получилось», этого недостаточно: причиной мог быть временный сбой, а не запрет. Надёжное доказательство должно показывать отказ на доверенном контрольном уровне.
Шаг 6. Проверьте временное разрешение
Если агенту иногда нужен интернет, применяйте короткоживущую allowlist-политику. В журнале должны быть субъект, имя назначения, время выдачи, причина, срок действия и результат. Постоянный доступ ко всему интернету нельзя считать приемлемым для высокорисковой задачи.
Особое внимание уделяется инструментам. Запрет сети на уровне оболочки бессилен, если вспомогательный сервис имеет собственный маршрут наружу. Сетевой контроль проверяется для основного процесса, дочерних процессов и интеграций, которые агент вызывает через API.
Ресурсы и завершение: авария должна быть конечной
Даже изолированный агент может создать операционный инцидент. Бесконечный цикл, массовое порождение процессов, заполнение диска и зависший дочерний процесс проверяют не «производительность», а управляемость среды.
Шаг 7. Запустите отрицательные ресурсные сценарии
Используйте тестовые задания с:
- бесконечным вычислительным циклом;
- каскадным созданием процессов;
- непрерывной записью во временный каталог;
- большим, но контролируемым выделением памяти;
- долгой операцией без ответа;
- дочерним процессом, который игнорирует обычное завершение.
Ожидаемый результат — срабатывание лимита, понятная причина остановки и отсутствие влияния на соседнюю задачу. Нельзя переносить заявления о ёмкости или скорости из одной платформы на другую: выводы о времени запуска, параллельности и накладных расходах требуют официального источника или пометки о тесте ProxyMac.
Шаг 8. Проверьте принудительную остановку
Сначала завершите агент штатным способом. Затем оборвите управляющий процесс и отдельно остановите оболочку, оставив дочерний процесс. После каждой операции проверьте список процессов, монтирования, временные каталоги, сетевые соединения и записи аудита.
Критический критерий — повторный запуск не должен наследовать состояние прежней задачи. Если старый процесс продолжает держать файл, порт или секрет, результатом должна быть блокировка выпуска.
Где проходит граница между «достаточно» и «нужно мигрировать»
Приёмка Apple Container для AI Agent не обязана превращаться в соревнование сред. Она должна отвечать на вопрос о классе угроз.
Оставить dsh или Docker можно, если:
- агент работает с доверенным кодом одного пользователя;
- рабочая область ограничена и проверена обходами;
- секреты выдаются временно и не попадают в журналы;
- исходящая сеть имеет понятную allowlist-политику;
- ресурсные лимиты и удаление среды подтверждены логами.
Усилить текущую схему следует, если:
- провалена только настройка монтирования или сетевого шлюза;
- ключи доступны через лишнюю переменную окружения;
- после остановки остаётся кэш, который можно очищать отдельным этапом;
- тестовая процедура не умеет отличать системный отказ от обычной ошибки соединения.
Переход к Firecracker следует оценивать, если:
- выполняется произвольный код из недоверенного источника;
- задачи принадлежат нескольким арендаторам;
- критический тест выхода за границы не пройден;
- требуется отдельная граница виртуальной машины и Linux/KVM уже доступен как базовая платформа.
Firecracker не является универсальной кнопкой «сделать безопасно». Он зависит от Linux, KVM, изоляции управляющих компонентов, минимальных прав и усиления production-хоста. Документ Firecracker о модели устройства и рекомендации по production-хосту нужно читать вместе. Custom runner в dsh может подключить другой исполнитель, но это не готовая интеграция с Firecracker и не подтверждение её безопасности.
Риск интереса к более сильной изоляции растёт на фоне публичных сообщений о кибербезопасности AI-систем. При этом Astra остаётся не выпущенной моделью: объявление OpenAI от 7 августа 2026 года нельзя использовать как доказательство её доступности, характеристик или готовых требований к среде. Это лишь фон для более строгой проверки недоверенного выполнения.
FAQ: что именно считать доказательством
Можно ли считать Apple Container безопасным без теста на побег?
Нет. Без попыток чтения вне рабочей области, обращения к хосту, доступа к секретам и проверки дочерних процессов команда знает только то, что задача стартует. Для выпуска нужен повторяемый отрицательный тест с журналом отказа. Чем выше ущерб от компрометации, тем меньше оснований принимать декларативные гарантии вместо наблюдаемого результата.
Заменяет ли Seatbelt полноценную виртуализацию?
Нет, это другой класс ограничения. Seatbelt может эффективно сузить действия процесса, но его нельзя автоматически описывать как отдельное ядро или полноценную VM. В dsh важно зафиксировать активный backend, версии конфигурации и права runner. Если модель угроз предполагает злонамеренный код и совместное использование среды, требуется более сильная граница и отдельная оценка Linux/KVM.
Что делать, если сетевой тест провален?
Сначала определить точку разрешения: DNS, прокси, маршрутизатор, сетевой namespace или вспомогательный сервис. Затем запретить маршрут, повторить тест и проверить журнал. Если сеть нельзя сделать ограниченной и наблюдаемой, задача получает статус «не прошла». Нельзя объявлять среду безопасной только потому, что один URL не открылся.
Когда Docker остаётся разумным выбором?
Docker подходит для доверенных однопользовательских рабочих процессов, где команда контролирует образы, монтирования, capabilities, seccomp и сеть. Он становится слабым выбором для произвольного кода, если конфигурация оставляет широкие тома, привилегированный сокет или доступ к чувствительным сервисам. В таком случае сначала исправляется политика, а затем повторяется вся матрица приёмки.
Нужно ли сразу переходить на Firecracker после любой ошибки?
Нет. Ошибка в allowlist или очистке не равна доказанному выходу из виртуальной границы. Но подтверждённая возможность читать секреты хоста, обращаться к внутренним адресам или переживать принудительную остановку для высокорисковой многопользовательской задачи является основанием остановить выпуск и оценить Firecracker, а не ослаблять тест.
Финальная карта решений перед выпуском
Ниже — компактная карта для итогового протокола. Она не заменяет журналы, но помогает избежать решения «по ощущениям».
| Условие приёмки | Решение | Ограничение |
|---|---|---|
| Все проверки файлов, секретов, сети, ресурсов и восстановления пройдены | Оставить Apple Container | Выпускать только проверенный класс задач |
| Файлы изолированы, но сеть или секреты требуют ручного контроля | Усилить конфигурацию | Только внутренние и низкорисковые задания |
| dsh проходит тесты в однопользовательском режиме | Оставить dsh | Developer preview требует повторной проверки после изменений |
| Docker проходит тесты с минимальными монтированиями и seccomp | Оставить Docker | Не переносить вывод на привилегированные контейнеры |
| Есть подтверждённый доступ к хосту или секретам | Заблокировать выпуск | Сначала исправление и повторная приёмка |
| Высокий риск, несколько арендаторов, критический тест провален | Оценить Firecracker | Linux/KVM и усиленный production-хост обязательны |
Для команды, которая арендует удалённый Mac, разумный следующий шаг — не просить обещание «безопасной среды», а перенести этот протокол на конкретную поставку. В консоли ProxyMac можно подготовить повторяемую рабочую сессию, а условия временного доступа сверить на странице тарифов ProxyMac. Критичны не рекламные характеристики, а сохранённые логи запуска, монтирования, сетевых отказов и очистки.
Локальный Mac остаётся удобным для постоянной разработки, но у него есть три реальных недостатка: команда сама отвечает за чистоту хоста, воспроизводимость конфигурации и физическое восстановление после неудачного теста. Общая локальная машина также повышает цену ошибки, когда экспериментальный агент получает лишнее разрешение. Временная среда ProxyMac полезнее именно тогда, когда нужно повторить тот же PoC на выделенном Apple Silicon Mac, сопоставить macOS и параметры запуска, а затем сохранить доказательства для ревью. Это не заменяет самостоятельную модель угроз, зато сокращает риск принять решение по единственному удачному запуску.
