Как работают плагины dsh и как их безопасно проверить

Что такое плагин dsh и что он может делать?

Плагины dsh — это пакеты Node, которые DeepSeek Harness загружает в свой собственный процесс. Установка плагина запускает сторонний код с правами вашего агента на машине, к которой у агента уже есть доступ. Между загруженным плагином и остальными компонентами harness нет никаких ограничений. Поэтому перед установкой плагина следует задаться вопросом, к чему этот код может получить доступ и как минимизировать этот риск.

dsh (DeepSeek Harness) — это open-source агентная оболочка DeepSeek AI, построенная на plugin framework под названием Cordis. Именно это промежуточное слово имеет значение, поскольку agent harness — это программа, которая окружает модель и управляет циклом работы, инструментами и разрешениями, а plugin подключается именно на этом уровне. В README проекта указано, что всё является plugin. Адаптер модели — это plugin. Веб-интерфейс, в который вы вводите текст, — это plugin. Всё, что вы устанавливаете из внешних источников, попадает в то же дерево и получает тот же уровень доверия, что и поставляемые с проектом компоненты. Если вы ещё не развернули его, начните с DeepSeek Harness на VPS и вернитесь к этому тексту, прежде чем добавлять в него что-либо.

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

• LLM (большая языковая модель): провайдер, оплачиваемый через ваш API key
• Shell: возможности bash с провайдерами local и pwsh
• Filesystem: доступ к файлам, контролируемый политиками
• Web: провайдеры для поиска и получения данных
• Subprocess: провайдер для работы с деревом процессов
• Workflow: рабочие потоки
• Subagent: делегирование задач другим агентам
• Settings and credentials: ваши сохранённые настройки и переменные окружения

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

Как dsh находит и загружает плагины?

Глобального каталога плагинов не существует. Запущенный dsh представляет собой дерево плагинов, которое формируется при загрузке из упорядоченных слоев, а единицей хранения ваших настроек является профиль. $DSH_HOME по умолчанию использует ~/.dsh, и каждый профиль находится в $DSH_HOME/profiles/<name>. Профили web и headless создаются автоматически при первом использовании на основе поставляемых шаблонов.

Каталог профиля содержит два файла, которые определяют всё:

• package.json, содержащий внешние зависимости плагинов, а также манифест dsh.profile с упорядоченным списком bundles
• cordis.patch.yml, ваш собственный слой исправлений поверх этих пакетов

ls ~/.dsh
ls ~/.dsh/profiles/web

При загрузке слои применяются в следующем порядке, при этом последующие слои имеют приоритет:

1. пустой корень
2. пакеты профиля в порядке, указанном в манифесте
3. cordis.patch.yml профиля
4. $DSH_HOME/cordis.patch.yml
5. любые наложения --patch <path>, переданные через командную строку

Два флага позволяют вывести результат этой композиции без запуска каких-либо процессов:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

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

Одно предостережение относительно этих файлов исправлений. Конфигурация здесь не является пассивными данными, так как формат позволяет использовать значения с тегом !!js в блоке config плагина. Фрагмент cordis.patch.yml, скопированный с форума, является кодом, поэтому относитесь к нему так же, как к shell-скрипту из того же источника.

Что именно запускает dsh plugin add?

dsh plugin --profile <name> <args> передает свои аргументы утилите pnpm внутри директории профиля, поэтому pnpm должен находиться в PATH. Используются команды pnpm:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

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

Начиная с версии pnpm 10, скрипты сборки зависимостей по умолчанию не выполняются, а одобрение требуется для каждого пакета через onlyBuiltDependencies или pnpm approve-builds. Проверьте установленную версию pnpm:

pnpm --version

Это значение по умолчанию полезно, однако это самая игнорируемая функция безопасности в экосистеме. Блокировка скриптов сборки предотвращает выполнение кода во время установки. Это никак не влияет на сам плагин, так как основная задача плагина заключается в том, что управляющая программа (harness) импортирует его и вызывает при следующей загрузке. Плагину не нужен хук postinstall. Он был вызван намеренно.

Что нужно прочитать перед установкой плагина dsh

Скачайте опубликованный tarball и изучите его содержимое. Распаковка архива не приводит к выполнению кода.

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

Четыре поля в файле package.json содержат основную информацию, которая вам потребуется. Проверьте scripts на наличие записей preinstall, install и postinstall. Изучите dependencies на предмет имен, которые вам незнакомы или отличаются от известных вам имен всего на один символ. Проверьте bin, чтобы узнать, какие пути пакет пытается добавить в ваш PATH. Изучите main или exports, чтобы найти точку входа, затем откройте этот файл и проанализируйте его содержимое.

После этого изучите код, который будет загружен. У плагина, заявленного как инструмент уведомлений, нет причин читать ~/.ssh, обращаться к неизвестному вам хосту или запускать оболочку (shell). Если пакет поставляется только в виде упакованного или минифицированного JavaScript, а исходный код отсутствует в публичном репозитории — это повод для отказа от установки. Отдавайте предпочтение плагинам с доступным для чтения исходным кодом и выбирайте наиболее компактные решения.

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

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

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

Фиксация версии и сохранение lock-файла

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

dsh plugin --profile web add --save-exact '<package-name>@<version>'

Расположение флагов зависит от версии pnpm, поэтому проверяйте результат, а не полагайтесь на команду. После выполнения откройте package.json профиля и убедитесь, что зависимость указана как конкретная версия без символов ^ или ~ перед ней. Этот файл определяет, что именно будет установлено.

Затем сохраните lock-файл, который фиксирует всё дерево зависимостей, а не только имя верхнего уровня:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

Скопируйте его в место, где вы храните резервные копии, вместе с package.json профиля. Эти два файла позволяют восстановить идентичное дерево зависимостей на новом сервере. Запускайте dsh plugin --profile web update только тогда, когда вы приняли решение обновить версии, а не в качестве рутинной очистки, и всегда просматривайте diff lock-файла после этого.

Для плагина, установленного из git, а не из реестра, фиксируйте коммит, а не ветку. Спецификация вида github:owner/repo#<full commit sha> обеспечивает фиксированное дерево зависимостей. Имя ветки означает, что при следующем разрешении зависимостей pnpm установит то, что находится в этой ветке на текущий момент, — решение, которое вы делегируете кому-то другому. Сама инфраструктура требует такой же дисциплины, поскольку каждая опубликованная сборка dsh является релиз-кандидатом, и нефиксированная установка может разрешиться в разные версии в разные дни. Именно это является причиной большинства ошибок установки и версий dsh.

Рынок плагинов и ценность «курируемого» контента

dsh имеет маркетплейс, который устанавливается как плагин, что многое говорит об архитектуре:

dsh plugin --profile web add dshmarket

После перезапуска он появляется в разделе Settings, а затем в Plugin Market. В его README прямо указаны ограничения. Установка разрешена только из источников, включенных в курируемый реестр; любые другие отклоняются. Скрипты сборки по умолчанию заблокированы, и для включения каждого из них требуется отдельное одобрение для каждого пакета. Плагины для терминала помечаются специальными флагами перед добавлением в веб-профиль. Самое важное утверждение заключается в том, что наличие в списке не является гарантией качества, так как плагины представляют собой сторонний код.

Курируемый список повышает минимальный уровень безопасности. Он не проверяет код за вас и не может предсказать, что сделает следующая версия плагина после смены владельца учетной записи сопровождающего. Относитесь к установке в один клик так же, как вы относились бы к curl | bash от того же автора. Стоит повторить еще одну строку из этого README: экспортированная резервная копия может содержать учетные данные из конфигурации вашего профиля, поэтому никогда не прикрепляйте ее к публичным тикетам или на сайты для обмена кодом. Если вам нужен готовый список, а не метод, плагины dsh, которые стоит установить — это сопутствующая статья к данной.

Запуск dsh от имени отдельного пользователя, а не root

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

Создайте для инструмента отдельную учетную запись Unix с собственным домашним каталогом и никогда не запускайте его от имени root:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

В рамках этой сессии запустите инструмент, чтобы он записывал данные в домашний каталог этой учетной записи:

npx @deepseek-ai/dsh web

Веб-интерфейс по умолчанию работает на http://127.0.0.1:3080. Оставьте этот порт. Если вы переходили по ссылке, которую выводит программа, с другого компьютера и не получали ответа, в том, что означает адрес, выводимый dsh объясняется причина. Любой, кто получит доступ к этому порту, сможет управлять агентом, имеющим доступ к оболочке (shell), поэтому публикация порта 3080 равносильна публикации удаленной оболочки без прав root с удобным интерфейсом. Вместо этого подключайтесь к нему со своего ноутбука через SSH-туннель:

ssh -L 3080:127.0.0.1:3080 you@your-vps

Затем убедитесь, что ни один сервис не прослушивает публичный адрес:

ss -lnt | grep 3080

Локальный адрес должен выглядеть как 127.0.0.1:3080. Если там указано 0.0.0.0:3080, то ваш брандмауэр — это единственное, что отделяет постороннего от вашего агента. Принципы, описанные в безопасном запуске Claude Code на VPS, применимы к dsh без изменений. Выделите агенту один рабочий каталог, который ему разрешено повредить, и не храните на этой машине ничего, что вы не сможете восстановить. Еще лучше — рассматривайте этот сервер как одноразовую виртуальную машину для агентов-разработчиков, поскольку пересоздание VPS занимает час, а аудит безопасности — неделю.

Где хранятся ваши ключи и почему прав доступа к файлам недостаточно

dsh хранит API-ключи в $DSH_HOME/.credentials.yaml, переменные окружения в $DSH_HOME/.env, настройки моделей в $DSH_HOME/settings.yaml, а историю сессий в $DSH_HOME/storages. Какой ключ в каком файле должен находиться и что именно покидает сервер в каждом из режимов — тема раздела настройка API-ключей, моделей и эндпоинтов dsh. Разобраться с этим стоит до добавления плагинов, так как любой подключенный ключ становится доступным для чтения плагином. Ограничьте доступ к двум наиболее чувствительным файлам:

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

Режим 600 предоставляет владельцу права на чтение и запись, а всем остальным — никаких прав. Это полезно знать в обоих форматах записи (числовые и символьные режимы chmod). Будьте реалистичны в отношении того, что это дает. Права доступа защищают файлы от других учетных записей на сервере. Они никак не защищают от плагина, так как плагин выполняется от имени пользователя-владельца внутри процесса, который эти файлы читает. Именно поэтому ограничение доступа AI-агента к секретам подразумевает, что их вообще не следует хранить на машине. На сервере с dsh должен находиться только один ключ модели, необходимый для работы. Ваши облачные учетные данные и ключи подписи должны храниться в другом месте.

Почему плагин для чтения веб-страниц меняет модель угроз

Веб-интерфейс предоставляет плагинам инструменты для поиска и получения данных. Плагин, который загружает страницу в вашу сессию, извлекает текст, написанный злоумышленником. Модель промптов не разделяет инструкции и данные, поэтому загруженная страница может содержать команду, адресованную вашему агенту. Если среда выполнения (harness) обладает правами доступа к оболочке (shell), выполнение такой команды — лишь вопрос одного послушного шага.

Средства контроля уже встроены в среду выполнения. dsh-base, первый пакет в каждом профиле, содержит песочницу и политику подтверждения действий. Используйте их. Сессия, способная загружать недоверенные страницы, должна требовать подтверждения для любых операций записи или выполнения. Это предотвратит превращение загруженной инструкции в самостоятельное действие. В разделе Ограничение действий агента через подтверждение описано, как определить границы таких ограничений. Взаимосвязь работает в обоих направлениях: ваш собственный сервер — это тоже страница, которую может загрузить чей-то агент, что рассматривается в разделе блокировка AI-краулеров на вашем сервере.

Как проверить, что изменил плагин?

Сделайте снимок до установки, выполните установку, сделайте снимок после, а затем изучите разницу.

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

Diff показывает, какие записи плагина были добавлены в составное дерево при установке. Если плагин, установленный ради одной небольшой функции, добавляет несколько записей, которые вы не можете объяснить, это повод остановиться и изучить исходный код перед запуском. dsh plugin --profile web why <package-name> отвечает на другой вопрос: какая из ваших прямых зависимостей потянула за собой конкретный пакет.

Установленные пакеты попадают в $DSH_HOME/profiles/node_modules, поэтому вы также можете просмотреть дерево на диске:

ls ~/.dsh/profiles/node_modules

Держите второй профиль, в котором вы никогда не проводите эксперименты. Если установка нарушает работу системы, запуск dsh --profile <clean-name> за секунды покажет, был ли причиной плагин.

Как удалить плагин dsh?

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

Удаление зависимости не всегда приводит к удалению конфигурации. Записи, внесенные в cordis.patch.yml профиля, остаются на месте, так как этот файл принадлежит вам, и инструментарий не будет перезаписывать его автоматически. Откройте файл и удалите все блоки, в которых упоминается удаленный пакет.

less ~/.dsh/profiles/web/cordis.patch.yml

Затем перейдите к этапу, который не может исправить ни одна команда удаления. Если вы удалили плагин из-за потери доверия к нему, считайте, что все данные, к которым он имел доступ, уже скомпрометированы. Смените API-ключ DeepSeek в консоли провайдера и обновите все остальные секреты, которые хранились в $DSH_HOME. После этого проанализируйте, к каким ресурсам в вашей сети имел доступ системный аккаунт, под которым работал плагин.

Краткая версия

• Изучите опубликованный tarball перед установкой, начиная с scripts и файла входа.
• Фиксируйте точную версию или конкретный commit для git-спецификации и сохраняйте lockfile.
• Выполняйте установку в один профиль и держите чистый профиль, который можно загрузить в случае сбоя.
• Сравнивайте --dump-config до и после каждой установки.
• Запускайте harness от имени отдельного unix-пользователя, на loopback-интерфейсе, с доступом по SSH.
• Храните на сервере только один API key и обновляйте его в день удаления плагина, которому вы больше не доверяете.

Всё это не является поводом отказываться от плагинов. Модель плагинов — причина, по которой dsh полезен, а harness, который нельзя расширить, — это harness, который вы в итоге замените. Это повод знать, что именно вы установили, от кого, какой версии, и запускать всё это там, где вы сможете выполнить пересборку.

FAQ

Изолирует ли dsh плагины друг от друга?

Нет. Плагин загружается в процесс harness через Cordis и получает доступ к документированным интерфейсам взаимодействия, включая shell, файловую систему, web, подпроцессы, субагенты и учетные данные. dsh-base, первый пакет в каждом профиле, поставляет песочницу и политику одобрения, которые определяют допустимые действия инструментов агента; именно эта политика обеспечивает вашу защиту. Границы разрешений для отдельных плагинов отсутствуют, поэтому честная модель безопасности подразумевает, что установка плагина означает распространение вашего доверия на его автора и на каждый пакет в дереве его зависимостей.

Можно ли установить плагин dsh, не запуская его скрипты установки?

pnpm 10 и более поздние версии блокируют скрипты сборки зависимостей по умолчанию, а dsh plugin ... add перенаправляет запросы в pnpm, поэтому в актуальных версиях pnpm установка не запускает скрипты пакетов, если вы не одобрили этот пакет. Проверьте свою версию с помощью pnpm --version. Это не делает непроверенный плагин безопасным. Код самого плагина будет запущен при следующей загрузке, так как harness загружает его намеренно, на что не влияют никакие ограничения этапа установки.

Где фактически хранятся плагины dsh и их конфигурация?

$DSH_HOME по умолчанию использует ~/.dsh. Профили находятся в $DSH_HOME/profiles/<name>, каждый из них содержит package.json с зависимостями плагинов, манифест dsh.profile с упорядоченными пакетами и слой исправлений cordis.patch.yml. Установленные пакеты размещаются в $DSH_HOME/profiles/node_modules. Ключи находятся в $DSH_HOME/.credentials.yaml, значения переменных окружения — в $DSH_HOME/.env, а файл $DSH_HOME/cordis.patch.yml на уровне домашней директории применяется ко всем профилям. Запустите dsh --profile web --dump-config, чтобы увидеть итоговую конфигурацию без запуска системы.

Безопасно ли устанавливать плагины из маркетплейса dsh?

Маркетплейс ограничивает установку источниками из проверенного реестра и блокирует скрипты сборки, если вы не одобрили их для каждого пакета отдельно, что является реальным улучшением по сравнению с копированием имени пакета из чата. В README маркетплейса указано, что размещение не является одобрением, так как плагины представляют собой сторонний код от других разработчиков. Изучайте исходный код и фиксируйте версии. Запускайте harness под учетной записью пользователя и, по возможности, на машине, потерю данных на которой вы можете себе позволить.