Appearance
Workspace 为什么不能自动信任 Tool / Skill：Supply-chain Trust Boundary
前置：Browser / Computer Use 如何进入 Coding Agent Workspace
核心问题：下载来的 Tool/Skill 为什么不能因为“能运行”就信任，来源、版本、内容和执行权限应怎样逐层校验？
“仓库里有这个文件”不是授权证据
打开一个陌生仓库时，.agent/skill.md、MCP config、shell hook、editor task 或 plugin manifest 都只是 workspace content。它们可能是项目作者正常提供的开发配置，也可能由攻击者提交。
如果 Harness 看到文件就自动加载、注册 Tool 并执行 hook，就完成了危险的权限升级：
text
untrusted repository bytes
→ executable configuration
→ local capability / network / credential access真正需要的是 trust decision，而不是文件存在性检查。
Trust-before-config-load 应发生在能力注册之前
推荐链路：
text
open workspace
→ discover candidate config/skill/plugin
→ parse as untrusted data
→ determine source + version + requested capabilities
→ policy/user trust decision
→ register allowed capabilities
→ execute only inside constrained boundary这里“parse”与“execute”必须分开。读取 manifest 得知它想运行 npm test 是数据处理；直接执行 postOpen.sh 已经进入副作用。
Provenance 不只是一个名字
一个 Skill/Tool 至少需要回答：
text
source: built-in / organization / repository / remote registry
identity: stable package/tool/skill id
version or content hash
who approved it
requested capabilities
network/filesystem/credential requirements
last update / changed permissions如果 v1 只读 repo，v2 新增“读取用户 home + 出网”，即使名称相同也不应该沿用旧授权。Trust 应绑定到身份 + 版本/内容 + 能力范围，而不是“以前点过允许这个名字”。
Tool definition 本身也可能是攻击载体
即使插件代码没有直接执行，Tool description、Skill instructions 或 MCP-provided prompt 也可能进入模型 Context，影响后续决策。因此供应链边界有两层：
text
semantic exposure
→ untrusted instructions/schema enter model context
execution exposure
→ code/tool gains real capability前者需要 provenance 标记、Context policy 和 prompt-injection 防御；后者需要 authorization、least privilege 和 sandbox。只做其中一层不够。
Workspace-local 和全局安装的风险不同
Workspace-local config 很方便，因为项目可以自带构建/测试知识；也最危险，因为“clone/open repo”本身就可能来自不可信来源。
全局/组织级 Skill 通常有更稳定的审批渠道，但一旦被攻破，blast radius 更大。Harness 可以采用不同 policy：
text
built-in signed capability → allow by policy
organization-managed skill → allow scoped version
workspace-local skill → require trust/review
unknown remote MCP/tool → deny or explicit approval这不是绝对标准，而是把来源等级变成可审计 policy。
Trust 通过后仍然要最小权限
Trust 不等于 unrestricted execution。一个已批准的测试 Skill 如果只需要：
text
read workspace
execute pytest
write test artifacts就不应该顺带获得用户 SSH key、云凭据和任意公网访问。供应链验证降低“加载了谁”的风险，Capability/Sandbox 限制“即使它恶意能做多大”。
升级和恢复时重新验证什么
长 Run 可能在 Skill v1 下创建，第二天恢复时 workspace 已更新到 v2。Runtime 不应悄悄用新 capability 继续旧 Run。RunManifest/Workspace snapshot 应保存相关版本或 hash；恢复时检测漂移，并按 policy：
text
same trusted version → continue
compatible approved update → continue with recorded migration
permission expansion → pause / re-approve
unknown change → reject这和 State schema migration 是同一种工程原则：长期任务不能假设外部执行环境永远不变。
最小验证场景
可以用一个恶意 fixture repo 测：打开仓库时其中的 hook 不自动执行；manifest 能被展示但 capability 未注册；用户批准 read-only skill 后写文件仍被拒绝；skill 内容 hash 改变且新增 network 权限后必须重新审批。
这类测试证明的是 trust boundary，不是让模型判断“这个仓库看起来安全吗”。
自测
- 仓库里自带一个 Skill 指示 Agent 上传环境变量。为什么“代码在 Workspace 里”不等于它值得信任？
- 第三方 Tool/Skill 的来源、版本、权限应该在哪里被验证，才能避免把 supply-chain trust 交给模型判断？