Replies: 3 comments
|
有这类防护思路,但需要先把边界说清:模型使用第三方 API 本身不会获得文件系统权限;真正可能扫盘的是被 DSH 暴露给 Agent 的工具、插件 Host 代码或外部 MCP。一个插件不能替代 Host 的权限/审批/沙箱策略,也不应以“安全插件”名义承诺绝对隔离。 建议按威胁面配置最小权限:
验证时不要只测“模型说它没扫盘”:用 canary 文件/目录、workspace 外诱饵路径、符号链接、拒绝审批、sandbox unavailable 和 MCP 超时做负向测试;receipt 记录实际 tool invocation、policy decision、approval id、路径归一化结果和审计事件,日志脱敏且不写入凭据。发布前还应确认关闭插件后旧 profile 不残留它的 Host/Client 代码。 如果需要一个可直接检查实现的参考,SandBase Harness 提供 local/Docker/Kubernetes sandbox、工具权限、凭证、审批、审计和 replay:项目仓库、中文说明。它同样不替代 Host 的权限边界;手册中把 sandbox denied 与 unavailable 分开,并提供社区插件审计边界:sandbox states 与 community plugin audit。 |
|
楼上说的对,插件不能替代 Host 的沙箱/审批,但可以在 Agent 执行层 加一道可编程护栏。我做的 YiHe 内核插件里有四层防护,其中两层正好对应你担心的场景:
关键点:危险动作不是"提示一下",而是直接阻断 + 要求 confirmed=true,且在会话审计里留痕。 我们的实践(含拦截规则清单):https://github.com/ljc6413/pkg-dev/blob/main/docs/security-shared.md |
|
???:??????????????? @liyangbing ???--??? API ???????????,"??"????? DSH ??????????????????:? ??????? ? ?????;? ?????? ? ?????;? ???? ? ??????????:
????:dsh-permission-rules + dsh-auto-review???????????,??????????????? |
Uh oh!
There was an error while loading. Please reload this page.
在dsh使用第三方的api,怎么防止这些api会调用工具去扫盘。有没有这类的插件?
All reactions