2026 DeepSeek Harness: безопасна ли песочница Mac — чек-лист Seatbelt

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

Быстрое решение: победитель для контролируемого кода — Seatbelt в режимах read-only или workspace-write, но только после проверки отказа в записи, режима fail-closed и отдельного согласования расширенных прав; недоверенный репозиторий следует переносить на выделенный удалённый Mac или в более сильную среду изоляции.

Кому нужен этот чек-лист

Локальному разработчику он поможет проверить, сможет ли DeepSeek Harness изменить файлы за пределами рабочего каталога. Инженеру по безопасности и платформе — превратить документацию Seatbelt в воспроизводимые приёмочные тесты.

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

Важно: на 21 августа 2026 года DeepSeek Harness остаётся developer preview. Официальный проект предупреждает о возможных несовместимых изменениях, а видимый в Releases вариант — v0.1.0-rc.8, опубликованный 19 августа 2026 года. Перед внедрением необходимо сверить актуальные документы и выпуск проекта: официальная страница Releases может измениться.

Seatbelt ограничивает файлы, а не весь Mac

Главная ошибка при оценке DeepSeek Harness — называть локальную песочницу полноценной изоляцией хоста. В документации проекта macOS-бэкенд описан через Seatbelt и sandbox-exec; сам sandbox-exec помечен как устаревший системный механизм, хотя пока поставляется вместе с macOS. Это означает, что проверяется конкретная политика доступа, а не гарантируется полное отделение процесса от операционной системы. Описание подсистемы приведено в официальной документации Harness о sandbox.

Seatbelt в первую очередь влияет на файловые эффекты команд:

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

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

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

Первый критерий: read-only против workspace-write

В режиме read-only команда должна получать доступ для чтения в разрешённых областях, но не должна изменять рабочие файлы. В режиме workspace-write разрешается запись в рабочую область, однако выход за её пределы должен отклоняться. Точные разрешения зависят от сформированной политики и актуальной реализации проекта, поэтому режим нельзя оценивать только по названию параметра. Проверять нужно фактически разрешённый путь после его нормализации. Сведения о разборе политик опубликованы в документе Harness о sandbox policy.

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

Минимальный набор проверок:

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

В read-only успешное чтение не доказывает возможность записи: нужна отдельная операция создания или изменения файла. В workspace-write успешная запись внутри проекта также ничего не говорит о защите соседнего каталога. Оба результата должны быть зафиксированы.

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

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

Как отличить обычный отказ от поломки sandbox-exec

Безопасный раннер обязан прекращать выполнение, если локальная песочница недоступна. В документации Harness это выражено принципом fail-closed: при отсутствии пригодного sandbox-бэкенда процесс не должен автоматически переходить к выполнению без ограничений. Проверять это следует по описанию Shell-подсистемы и документации sandbox, а не по одному сообщению в терминале.

В приёмочном журнале нужно разделять три события:

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

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

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

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

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

Второй критерий: разовое повышение прав против постоянного доступа

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

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

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

Фраза «нужен полный доступ» не является достаточным обоснованием. Одобрение должно относиться к конкретному вызову, а не к проекту навсегда. Если после одной успешной операции последующие вызовы получают тот же доступ без нового решения, граница полномочий нарушена.

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

Как защитить ключ и endpoint при подключении DeepSeek V4

Seatbelt не решает проблему доверия к модели и сетевому endpoint. Ограничение файловых эффектов не означает, что запросы к модели, сетевые соединения и секреты автоматически защищены. Harness поддерживает пользовательские OpenAI-compatible provider, поэтому при подключении самоуправляемого DeepSeek V4 нужно проверять отдельную цепочку конфигурации. Порядок параметров и источники настроек следует сверять с официальным руководством по Provider.

Архитектуру лучше разделить на два компонента:

• хост, на котором запускаются Harness, Agent и команды;
• сервер вывода, принимающий запросы через собственный endpoint.

Для каждого компонента фиксируются:

• Provider ID;
• base URL;
• источник токена;
• способ передачи ключа в процесс;
• журналы запросов и срок их хранения;
• допустимые каталоги конфигурации;
• процедура замены или отзыва секрета.

Ключ не должен лежать в редактируемом рабочем каталоге. Иначе модель, команда сборки или пользовательская конфигурация могут изменить файл, из которого доверенный процесс получает endpoint или токен. Особенно опасна схема, при которой проект содержит конфигурацию с перенаправлением на другой base URL, а секрет подставляется автоматически из окружения.

Приёмочный тест должен создать в рабочей области поддельный Provider ID и безопасный тестовый endpoint. Затем проверяется, может ли проектная конфигурация изменить адрес, на который доверенный процесс отправляет секрет. Для этой проверки нельзя использовать настоящий ключ. В журнале фиксируются фактический URL, источник значения и факт отсутствия секрета в командной строке, файлах проекта и обычных логах.

Открытый код Harness распространяется по лицензии MIT, но это не делает бесплатными вызовы модели, сервер вывода или аренду среды. Лицензия проекта и стоимость эксплуатации — разные вопросы. Официальное описание продукта доступно на странице DeepSeek Harness.

Сводная таблица перед допуском

Вариант запуска	Файловая политика	Риск для ключей	Когда допускать	Когда выбрать другой вариант
Локальный Mac, read-only	Только чтение в разрешённых областях; запись должна быть отклонена	Низкий только при внешнем хранении секрета	Личный доверенный код, короткие задачи	Недоверенный репозиторий или общий пользователь
Локальный Mac, workspace-write	Запись в рабочей области, отказ за её пределами	Средний; проект не должен управлять доверенной конфигурацией	Контролируемая разработка после тестов путей	Длительный Agent с чувствительными ключами
Выделенный удалённый Mac	Та же политика, но с отдельной учётной записью и каталогами	Ниже при раздельном хосте и ротации токенов	Командная работа, постоянный запуск, удалённый доступ	Требуется сильная изоляция ядра или неизвестный код
danger-full-access	Файловое ограничение фактически снято	Высокий	Только разовая диагностика с ручным контролем	Для штатной эксплуатации Agent
Песочница недоступна	Выполнение должно остановиться по fail-closed	Нельзя считать приемлемым	Только после восстановления раннера и повторной проверки	Любой запуск без доказанной изоляции

Таблица не заменяет тесты. Она помогает выбрать следующий шаг после тестов. Если неизвестен результат хотя бы одной строки, итоговая оценка должна быть «не принято», а не «вероятно безопасно».

Сценарий: общий Mac, отдельный Mac или более сильная изоляция

Для личного проекта с доверенным исходным кодом и короткими запусками локальная машина может быть достаточной. Условие — успешные проверки read-only, workspace-write, путей, отказа раннера и разовых разрешений. Доступ к секретам при этом остаётся отдельной задачей.

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

Выделенный удалённый Mac предпочтительнее, когда:

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

На практике удалённая среда также требует контроля SSH, VNC, журналов, сетевых правил и ротации секретов. Seatbelt закрывает только часть этой картины.

Если обрабатывается неизвестный репозиторий, нельзя доказать fail-closed, требуется постоянный полный доступ или нужны более сильные гарантии по процессам и сети, следует перейти к отдельному хосту либо к среде с более высоким уровнем изоляции. Фраза «песочница включена» не должна заменять анализ модели угроз.

Финальная приёмка: что записать в акт

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

• версия Harness и дата проверки;
• режим политики;
• рабочая область и канонические пути;
• результат чтения и записи внутри каталога;
• результат обращения за пределами каталога;
• результат теста временного пути;
• поведение при неработающем sandbox-exec;
• статус команды после runnerFailed;
• текст обоснования повышения прав;
• результат отказа, отмены и повторного вызова;
• Provider ID и base URL без публикации секрета;
• расположение ключа и правила его ротации;
• владелец среды и план восстановления.

Для горячего релиза это особенно важно. Статья актуальна на 21 августа 2026 года; данные сверены с официальным Release-каналом проекта, документацией sandbox и Provider. При выходе версии v0.1, изменении backend песочницы, смене семантики режимов или исчезновении sandbox-exec приёмку необходимо повторить в течение суток.

Текущий Mac против выделенного Mac для Harness

Обычный текущий Mac удобнее для первого эксперимента: не нужно ждать выдачу среды, рабочая папка уже доступна, а локальный интерфейс быстрее для отладки. Но у такого варианта есть реальные недостатки — общие пользовательские каталоги, соседние SSH- и облачные ключи, отсутствие гарантированного сброса после запуска и риск того, что длительный Agent будет конкурировать с обычной работой.

Выделенный удалённый Mac стоит рассматривать не как «магическое усиление Seatbelt», а как дополнительный операционный слой: отдельная учётная запись, ограниченный каталог, контролируемый доступ, очистка и повторяемость. Если собственная машина не обеспечивает постоянную доступность, изоляцию пользователя или быстрый сброс окружения, аренда Mac у ProxyMac может дать более предсказуемую площадку для тестового и временного Harness-сеанса. Условия доступной среды следует проверять на странице аренды Mac, а параметры доступа — через консоль ProxyMac.

До передачи проекта полезно сохранить этот чек-лист в системе изменений и провести тесты на пустом репозитории. Если все границы подтверждены, доверенный код можно оставить на локальном Mac. Если хотя бы одна граница не доказана, безопасное решение — не расширять danger-full-access, а перенести Agent и endpoint на выделенную среду с отдельно управляемыми полномочиями.