一个 DSH 插件就是在你的智能体运行时里运行的包，它拥有与运行时相同的权限。整个安全模型就这一句话。这里没有市场把关方，没有评审委员会，也没有签名要求，所以判断权在你手上。本指南给出一个可复用的方法，帮你快速做出这个判断。
四个权限面
插件的风险大多集中在四处。安装之前，先判断一个插件真正需要其中哪几项、需要多少。
| 权限面 | 含义 | 合理的请求 | 危险信号 |
|---|---|---|---|
| 文件系统 | 读写你的工作区 | 相对于工作区的路径、已声明的根目录 | 路径穿越、写入工作区之外 |
| Shell | 执行命令 | 一份具名的、受约束的命令集合 | 无限制执行且不做确认 |
| 网络 | 访问外部服务 | 某个具体的 API 主机 | 宽泛的访问权加上凭据处理 |
| 凭据 | 持有密钥和令牌 | 从本地配置读取，绝不注入提示词 | 把密钥发送到第三方端点 |
一个视觉插件需要网络访问，别的都不需要。一个 SSH 运维插件合理地需要 shell 和网络访问，这正是它的命令白名单值得一读的原因。
第 1 步：确认来源
打开安装命令所声称的来源仓库。你希望看到的是：不是单次压平导入的提交历史、一份说明插件做什么与需要什么的 README，以及一个有人提问并得到回复的 issue 跟踪。
单次提交、没有历史、包名又靠近某个热门插件的仓库，正是值得警惕的那种模式。
第 2 步：把安装规格和仓库对着读
安装规格是手工敲上去的，也常被不加思索地复制。把条目页上的规格与仓库自身文档里的包名核对一遍。当两者不一致时，要么是条目写错了，要么是插件改过名，两种情况都值得先停下来。
第 3 步：看加载时跑了什么
在源码里搜寻那些在激活阶段、而不是在你调用工具时才执行的代码路径。真正值得读的，是那些在你没要求的情况下自己运行的部分：安装脚本、postinstall 钩子、任何在 apply 期间打开 socket 的代码，以及任何读取环境变量的代码。
第 4 步：检查密钥是怎么处理的
需要 API key 的插件，应当从本地配置读取它，并只用在自己的请求里。要避免的模式是：插件拿到 key 之后把它注入模型上下文，因为上下文里的任何东西都可能被回显进对话记录、日志或共享会话。
第 5 步：让验证等级与风险匹配
验证等级告诉你一个插件被测到什么程度，而不是它有多可信。把它们理解为对其行为的信心递增，并且随着插件权限面的扩大，对它的要求也要更高。
| 等级 | 含义 | 足以用于 |
|---|---|---|
| L1 | 找到仓库且内容非空 | 单凭这一项什么也不够；开始读代码 |
| L2 | 清单有效、字段完整 | 评估阶段，还不适合安装 |
| L3 | 安装命令可解析、目标版本已声明 | 只读的、纯本地的插件 |
| L4 | 在隔离沙箱中安装成功且无依赖错误 | 日常工具，仍需审阅源码 |
| L5 | 能加载并运行；冒烟测试通过 | 具备文件系统或网络访问的工具，仍需审阅 |
完整规则见验证页面。
第 6 步：从最小范围开始
用一个够用的最小范围来安装高风险插件：只读凭据、单个仓库、工作区下的一个子目录、一台远程主机。等插件稳定运行一段时间之后再放宽权限，而不是一开始就放宽。
如果某个插件提供了公开网络暴露模式，比如从手机远程访问，请把启用该模式视为一次部署决策。在它前面加上身份验证，不用的时候就关掉。
第 7 步：预留一条移除路径
安装之前就要知道你将如何移除它，以及它会留下什么数据。把状态存在 profile 目录里的插件容易清理。写入全局缓存的插件会留下残留，而这些残留会比你卸载的决定活得更久。
FAQ
DeepSeek 会审查 DSH 插件吗？
不会。官方团队不运营注册表，也不审查社区插件。像本站这样的目录站点会执行各自的检查。
星标高是安全信号吗？
那是流行度信号。热门项目会得到更多审视，这有帮助，但它替代不了读权限面。
如果插件要求一个范围很宽的令牌怎么办？
如果服务方支持，就改为创建一个范围受限的令牌，并在授权任何东西之前，先读一遍使用它的代码路径。
插件能读我的其他会话吗？
插件运行在运行时内部，能访问运行时暴露出来的东西。请假定一个拥有文件系统访问权的插件，可以读到你用户账号能读的一切。