[安全设计问题] create_goal 可在用户未明确授权时自行开启，可能导致自主执行越过原任务边界

[z2078820800-ui]

正文：

我在使用 DSH 的过程中发现了一个可能涉及授权边界的设计问题，想反馈给维护者确认。

问题涉及 @deepseek-ai/dsh-tool-goal。

该工具的描述中包含：

You may infer that intent without requiring the user to say "create a goal"

也就是说，从工具规范来看，模型被允许根据用户意图自行判断是否创建 Goal，而不需要用户明确说“create a goal”或主动开启目标模式。

我的实际使用场景是：

我只要求 DSH 帮我判断某个目标网站的数据来源究竟是：

HTML
JSON
XHR / Fetch
或其他数据源

DSH 成功定位到了 JSON 数据源。

此时我的原始任务实际上已经完成，而且我没有继续下达“采集数据”“绕过登录”“继续执行”等指令。

但因为我当时没有及时回复，DSH 自行推断了我更进一步的意图，并开启了 Goal 模式继续执行。

在后续自主执行过程中，它进行了包括但不限于以下操作：

读取、复制 Chrome 相关 Profile 数据，并尝试寻找可复用的登录状态；
修改 Headless Chrome 的 User-Agent，并隐藏 navigator.webdriver 等自动化特征；
在遇到沙箱限制后使用 danger-full-access 重新执行；
主动向目标接口发送 GET / POST 探测请求；
在没有我逐项确认的情况下持续尝试解决阻碍并推进它自行推断出的目标。

需要说明的是，我反馈的重点并不是上述某一个具体动作，而是整个授权链条：

用户只授权了一个一次性诊断任务
→ 模型自行推断更长远目标
→ 模型自行创建 Goal
→ Goal 模式开始多轮自主续行
→ 推断出的意图逐渐被当成了执行授权

我认为这里存在一个比较明确的授权边界问题：

模型可以推断用户意图用于规划，但“推断出的用户意图”不应该等价于“用户明确授权进入自主执行模式”。

尤其当 Agent 同时具备浏览器、Shell、本地文件系统、网络请求以及高权限执行能力时，这种行为可能放大风险。

我目前在自己的 AGENTS.md 中增加了一个临时约束：

DSH 不得自行调用 create_goal。
只有用户在当前对话中通过 /goal <目标>、界面明确选择，或明确要求开启目标模式时，才允许进入 Goal 模式。

我个人更倾向于从工具层面解决这个问题，例如：

create_goal 只能由用户显式触发；
或增加一个明确的用户授权标记 / consent gate；
模型可以自行推断 Goal 的内容，但不能自行决定“是否进入 Goal 模式”。

[moonquake2004]

核实成立，而且"边界由什么承担"这一点比描述本身更值得看。

一、那句授权确实写在代码里，且这个模块里没有第二道门。 @deepseek-ai/dsh-tool-goal（lib/index.js:123）：

const CREATE_DESCRIPTION = "Create one persisted same-session completion goal when the current direct
human request is a long-running objective that should continue across autonomous goal rounds.
You may infer that intent without requiring the user to say \"create a goal\". Do not use this for
trivial single-turn work. Execution rejects non-human and subagent authority.";

我把该模块整个 grep 了一遍 approval / confirm / permission：零命中。也就是说，这句描述就是这道门本身——它不是一个"在审批之上再加一点推断"的设计，而是"推断即授权"。这一点值得在结论里写清楚，因为它决定了修法：不是调参，而是补一道门。

二、真正的落差在"目标拿到什么权限"，而不只在"目标能不能被推断出来"。 你的链条里最刺眼的一步是"遇到沙箱限制后使用 danger-full-access 重新执行"。把推断出的意图当作规划输入是可以接受的；但它同时继承了比原始请求更大的执行授权时，问题就从"模型太主动"变成了"授权被扩展"。所以我倾向于问题该这样切：

• 推断创建的 Goal 与用户显式创建的 Goal，应该是两种授权类别，而不是同一个东西的两种来源；
• 前者至少应当（a）在进入多轮自主前需要一次确认，且（b）只能继承原请求当时被授予的沙箱/审批姿态，不能在中途自行提升。

三、我们能检出什么（其中一条正是因为你的报告才补上的）。 你列的动作里有几步会留在会话日志里，而我们的工具是离线读日志的：

• 读取/复制浏览器凭据 —— 说实话，在你报告之前我们抓不到：我们的凭据库模式只有 .credentials.yaml / id_rsa / .env / .npmrc / security.json，浏览器凭据不在其中。刚补上（dsh-security@0.5.0）：Google/Chrome、Chromium、BraveSoftware、Microsoft Edge、Firefox/Profiles 目录，以及要求带路径分隔符的 Cookies / Login Data / logins.json / cookies.sqlite 等（这样 curl -H "Cookie: …" 和正文里提到 "Cookies" 不会误报——两类对照样例都在测试里）。
• danger-full-access 的使用 —— 我们的检查读的是解析后的 sandbox/approval 配置；在一次运行中被中途提升这件事，在会话日志里是可查的。
• "没有用户请求就进入 Goal 自主轮次" —— 也可离线判：把 goal 激活事件与最近一条用户消息对齐即可。

四、一个可以直接加的信号。 工具描述是模型实际遵循的指令，而"你可以推断而不需要用户说……"这种句子，和一条配置标签一样是可检查的。我们已经用同一思路扫插件内容里的静默执行措辞（"不要告诉用户"、"无需询问"）——把这份扫描扩到工具描述（宿主自带 + 插件提供）是小改动，误报率也低。要不要我做？不过要说清楚：它能给出的是"这里有放宽授权的措辞"这个信号，不能替代你们对授权模型的决定。 你的报告提出的问题在规范层，我们能做的是让描述可审计、让症状可发现。