Песочница Seatbelt в DeepSeek Harness для Mac

В официальном README DeepSeek Harness веб-интерфейс по умолчанию запускается на 127.0.0.1:3080 — это конкретный локальный сетевой endpoint, а не доказательство полной изоляции процесса. (github.com) Победитель для первой проверки — локальный или удалённый Mac с отдельным тестовым пользователем и низкорисковым репозиторием; Seatbelt следует считать дополнительным ограничителем процессов, а не полной системой Agent безопасности. Сначала необходимо подтвердить фактическую политику для файлов, дочерних процессов, сети и ключей. Только после этого можно расширять права или переносить задачу в постоянную среду.

Эта статья предназначена:

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

Последнее обновление: 18 августа 2026 года. Данные проверены по официальному репозиторию DeepSeek Harness, его архитектурным и эксплуатационным документам, а также материалам Apple по App Sandbox и системной защите macOS.

Что именно подтверждено в официальной архитектуре

В официальной архитектуре DeepSeek Harness sandbox описан как сменная возможность. Для ограничения запускаемых процессов используется backend ctx.sandbox, а потребители должны оборачивать аргументы команд перед созданием процесса. Это важная формулировка: ограничение применяется к процессу, который запускается через соответствующий путь, а не автоматически ко всей операционной системе или ко всем подключённым инструментам. (github.com)

Та же архитектура показывает, что файловая система и subprocess-провайдеры находятся в одном execution world. Если shell, PTY или LSP направляются в отдельную среду, меняется именно провайдер выполнения. Это полезнее, чем вывод по названию пакета: реальная граница определяется тем, какой provider подключён в загруженном профиле. (github.com)

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

dsh --profile web --dump-config

Ожидаемый результат должен позволить увидеть строки, отвечающие за sandbox, approval policy, инструменты и подключённые плагины. Если в фактически загруженной конфигурации нет ожидаемого backend или preset, нельзя считать Seatbelt активным только потому, что соответствующая идея присутствует в архитектуре.

Важно разделять три утверждения:

1. официальный проект предусматривает sandbox как системную capability;
2. macOS имеет механизм Seatbelt, связанный с ограничением доступа приложений;
3. конкретная сборка, профиль или сценарий DeepSeek Harness действительно применяет нужную Seatbelt-политику.

Первые два пункта ещё не доказывают третий. Официальный репозиторий на 18 августа 2026 года обозначает DeepSeek Harness как developer preview и предупреждает о совместимых изменениях. Поэтому поведение нужно подтверждать по версии, профилю и тестовой команде, а не по имени каталога. (github.com)

Для общей оценки вариантов размещения DeepSeek Harness полезно сопоставить не только модель Mac, но и правила изоляции, удалённый доступ и порядок приёмки среды. Внутренний обзор вариантов работы с Mac помогает отделить вопрос размещения от вопроса фактической политики Seatbelt. Сам по себе выбор отдельного устройства не заменяет проверку.

Файлы и рабочая область

Рабочая область против системной политики

Выбор Harness workspace отвечает на вопрос «какие файлы Agent должен видеть в рамках работы». Seatbelt отвечает на другой вопрос: «какие операции может выполнить конкретный процесс с точки зрения политики macOS».

Это не один и тот же контрольный слой.

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

• родительскому каталогу;
• домашнему каталогу пользователя;
• ~/.ssh;
• конфигурации Git;
• кэшу пакетного менеджера;
• временным файлам;
• сокету локального сервиса.

Если процессная политика не запрещает такие обращения, одного выбора workspace недостаточно. Apple описывает App Sandbox как механизм ограничения доступа к файлам, сетевым соединениям и другим ресурсам через разрешения и entitlements. При этом сама модель Apple не означает, что любое приложение получает одинаковую политику: доступ зависит от конкретных разрешений и способа запуска. (developer.apple.com)

Автоматически ли DeepSeek Harness включает Seatbelt на macOS?

На этот вопрос нельзя отвечать без проверки конкретной сборки и профиля. Официальная архитектура подтверждает наличие точки расширения ctx.sandbox, но название backend или наличие sandbox-пакета не доказывает, что он включён по умолчанию именно в установленном preset. На тестовом Mac нужно сохранить версию, профиль и вывод --dump-config.

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

mkdir -p "$HOME/dsh-seatbelt-test/project"
printf 'inside\n' > "$HOME/dsh-seatbelt-test/project/allowed.txt"
printf 'outside\n' > "$HOME/dsh-seatbelt-test/outside.txt"

pwd
cat "$HOME/dsh-seatbelt-test/project/allowed.txt"
cat "$HOME/dsh-seatbelt-test/outside.txt"

Положительный результат для первого cat ещё ничего не доказывает. Нужен также отрицательный результат для второго:

allowed.txt: inside
outside.txt: Operation not permitted

Если внешний файл читается, это не обязательно означает уязвимость. Возможно, активен другой профиль, workspace-провайдер не использует sandbox backend или тест выполняется не через тот subprocess-путь. Но в любом случае расширять права после такого результата нельзя.

Может ли Seatbelt закрыть доступ Agent к другим каталогам?

Да, если фактическая политика применяет запреты к соответствующему процессу и его дочернему дереву. Нет, если разработчик проверил только интерфейс workspace, но не проверил реальный fs- и subprocess-provider. Отдельно нужно протестировать чтение, запись, создание файла и переход через символьную ссылку. Для каждого действия требуется сохранить команду, exit code и текст ошибки.

Команды и дочерние процессы

Shell не равен одной команде

Agent редко выполняет только одну бинарную программу. Типичная цепочка выглядит так:

DeepSeek Harness
  └── shell
      └── script
          ├── package manager
          ├── compiler
          ├── test runner
          └── вспомогательный процесс

Даже без злонамеренного поведения операция npm test, xcodebuild, swift test или пользовательский скрипт может запустить несколько дочерних процессов. Каждый новый инструмент расширяет поверхность доступа: читает конфигурацию, создаёт кэш, обращается к сети, открывает сокет или запускает другой shell.

В официальной архитектуре DeepSeek Harness процессное ограничение описано именно как backend, который используется перед запуском команд. Поэтому нужно проверить не только прямой вызов, но и цепочку потомков. (github.com)

Проверка может выглядеть так:

printf '#!/bin/sh\n' > "$HOME/dsh-seatbelt-test/project/child-test.sh"
printf 'echo "parent=$PPID child=$$"\n' >> "$HOME/dsh-seatbelt-test/project/child-test.sh"
printf 'sh -c "pwd; id; env | sort | sed -n \"1,20p\""\n' >> "$HOME/dsh-seatbelt-test/project/child-test.sh"
chmod +x "$HOME/dsh-seatbelt-test/project/child-test.sh"

Ожидаемые артефакты проверки:

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

Нужны ли approvals, если включена песочница?

Да. Seatbelt ограничивает технические возможности процесса, но не понимает бизнес-риск команды. Для политики macOS одинаково может выглядеть безопасный просмотр файла и команда, которая удаляет большое количество файлов внутри разрешённого каталога. Системная sandbox не знает, что исходный код важен, а временный файл нет.

Поэтому approvals должны остаться отдельным слоем. Для первого запуска разумно использовать режим, при котором:

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

Граница между «запрещено политикой» и «разрешено после approval» должна быть записана отдельно. Иначе отказ Seatbelt можно ошибочно принять за approval-механику, а подтверждение — за доказательство безопасности.

Сравнение контрольных слоёв

Ниже — рабочая матрица для первой оценки. Она не заменяет тестирование конкретной версии.

Сеть, MCP и внешние инструменты

Три разные границы подключения

Сетевой риск нельзя свести к вопросу «включён ли Seatbelt». Необходимо разделить:

1. возможность локального процесса открыть исходящее соединение;
2. сетевые правила самого окружения;
3. поведение MCP-сервера или плагина.

Apple отдельно документирует entitlements для исходящих и входящих соединений, включая com.apple.security.network.client и com.apple.security.network.server. Это показывает, что сетевой доступ является самостоятельной категорией политики, а не побочным эффектом файловой изоляции. (developer.apple.com)

Нельзя утверждать, что Seatbelt по умолчанию блокирует все внешние соединения. Даже если локальный shell ограничен, MCP-плагин может иметь собственный процесс, прокси или удалённый endpoint. Поэтому в первом тесте используются только безопасные адреса и фиктивные данные:

curl -I https://example.invalid
curl -I https://www.apple.com

Смысл теста не в проверке доступности конкретного сайта. Нужно зафиксировать:

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

Если в тесте участвует MCP, результат локального curl нельзя переносить на MCP автоматически. У каждого внешнего инструмента должны быть собственные разрешённые endpoints, журнал и процедура отключения.

API-ключи и журналы

Credentials не входят в стандартную гарантию sandbox

Песочница не решает проблему, если секрет уже виден процессу. API-ключ может попасть:

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

Официальный development guide DeepSeek Harness указывает, что адаптер может читать ключ из окружения или из gitignored .env. Это удобный механизм для разработки, но он не определяет безопасную область видимости ключа и не предотвращает его вывод дочерней командой. (github.com)

На тестовом Mac нельзя использовать настоящий производственный ключ. Создаётся ограниченный ключ с минимальными правами, после чего выполняется поиск только по тестовым артефактам:

env | grep -E 'DEEPSEEK|TOKEN|SECRET|KEY' || true
find "$HOME/dsh-seatbelt-test" -type f -maxdepth 3 -print
grep -R "sk-" "$HOME/dsh-seatbelt-test" 2>/dev/null || true

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

DEEPSEEK_API_KEY=sk-test-********

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

Удалённый Mac и постоянный запуск

Отдельная машина снижает смешение, но не исправляет конфигурацию

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

На этапе приёмки нужно разнести проверки по четырём плоскостям:

• удалённый вход: SSH, VNC или веб-доступ;
• системный пользователь: права, shell, автозапуск;
• рабочая область: репозиторий, секреты, кэши;
• выполнение: sandbox, plugins, MCP, approvals и фоновые процессы.

SIP также действует на уровне политики macOS для процессов, включая процессы с административными правами, но он не заменяет настройку пользовательских каталогов, сетевых входов или инструментов Agent. (support.apple.com)

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

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

Первая проверка после публикации

Ниже — последовательность, которую можно выполнить без превращения статьи в полноценную инструкцию по настройке sandbox.

Шаг 1. Зафиксировать версию

Сохраните дату, commit или номер пакета, версию macOS, архитектуру процессора и способ запуска:

sw_vers
uname -m
node --version
pnpm --version
dsh --version

Официальный development guide DeepSeek Harness указывает поддержку Node.js 22.19+ и 24+, а также закреплённый pnpm@11.7.0; эти требования относятся к проверенному исходному окружению и не должны автоматически переноситься на каждый готовый пакет. (github.com)

Шаг 2. Вывести фактический профиль

dsh --profile web --dump-config > dsh-config.txt
grep -niE 'sandbox|approval|credential|mcp|workspace' dsh-config.txt

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

Шаг 3. Проверить файлы

Используйте отдельные allowed.txt, outside.txt, символьную ссылку и попытку записи. Нужны результаты как минимум для чтения, записи и удаления. Каждый отказ должен иметь понятную причину.

Шаг 4. Проверить дерево процессов

Запустите shell, скрипт, тестовый runner и инструмент, который создаёт потомка. Нельзя ограничиваться командой pwd. Цель — увидеть, сохраняется ли ограничение у всех дочерних процессов.

Шаг 5. Проверить сеть и MCP

Сначала тестируются фиктивные данные. Затем — разрешённый endpoint. После этого отдельно запускается каждый MCP-сервер. Успешный curl не означает, что каждый плагин находится в той же политике.

Шаг 6. Проверить credentials

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

Шаг 7. Подготовить откат

До расширения прав должна существовать команда остановки:

pkill -f 'dsh'

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

Главный вывод для 18 августа 2026 года прост: Seatbelt в DeepSeek Harness — перспективный системный ограничитель процессов, но не сертификат полной изоляции. До расширения прав необходимо доказать четыре вещи: какие файлы доступны, какие потомки запускаются, куда уходят сетевые запросы и где могут оказаться credentials. Только после этого имеет смысл выбирать постоянный Mac, временный удалённый стенд или откладывать запуск до появления подтверждённой политики.