最近看到一个讨论：第三方 AI agent skills 到底能不能信？
我觉得这个问题，问法本身就应该改一改。
不应该只问“这个 skill 看起来安不安全”，而应该问：
如果它有问题，我的系统还能不能兜住？
这两个问题的工程含义完全不同。
前者还是“信任判断”思路，后者已经进入了 blast radius control、least privilege、runtime monitoring 的范畴。对今天的 agent system 来说，后者才是更现实的安全起点。
第三方 skill 不是“普通插件”
很多人第一次看 agent skill，会下意识把它类比成一个小插件、一个脚本、一个 prompt 模板，甚至只是一个方便调用的工具封装。
但真正跑起来以后，你会发现它接触的东西远比“插件”这个词听上去危险得多：
- 本地文件系统
- browser session / cookies
- API keys 与 access tokens
- 外部网络请求
- 内部工具链
- 自动化 side effects
- 其他 tool descriptions 与 runtime context
换句话说，一个第三方 agent skill 的风险模型，往往更接近：
- browser extension
- CI plugin / GitHub Action
- 带 side effects 的 npm dependency
而不是一个“无害的辅助组件”。
一旦这样看，很多安全直觉就会立刻变化。
为什么“静态扫描通过”远远不够
讨论帖里给了一些很抓眼球的数字，比如有相当比例的 skills 存在漏洞、会把数据发到外部服务、或者安装后发生代码变化。先不说这些数字本身有没有完整方法学支撑，至少它提醒了一件很重要的事：
静态元数据和 manifest，不足以代表真实行为。
这是 agent 场景里非常关键的一点。
因为 skill 的风险，未必写在 manifest 里。真正的问题可能发生在：
- 安装后的代码漂移（post-install code drift）
- 运行时才出现的 callback traffic
- 某些隐蔽的 outbound requests
- tool chaining 带来的越权行为
- prompt injection 触发的跨工具劫持
- 对 secrets / local state 的非预期访问
所以如果安全策略还停留在：
- 看一眼 README
- 看一眼权限声明
- 扫一下 dependency
- 装上试试
那对 agent runtime 来说，其实是不够的。
真正该默认采用的思路：assume compromise
我越来越认同一种更现实的态度：
默认第三方 skill 可能出问题。
这里说的“出问题”不一定是明确恶意，也包括：
- 开发者无意中写出了危险逻辑
- 依赖被污染
- 更新流程不透明
- 工具调用边界设计过宽
- 对 prompt / metadata attack surface 认识不足
一旦采用 assume compromise 的心态，系统设计就会更务实。
你不会再执着于“它到底值不值得百分百信任”，而会转向：
- 它能访问哪些文件？
- 它能不能直接碰真实数据库？
- 它能不能随便出网？
- 它的工具权限和数据权限是不是绑死在一起？
- 如果它被 prompt injection 带偏，会不会串联别的工具？
- 如果它 silently exfiltrate，日志能不能看出来？
这才是 agent security 真正落地的地方。
一个更靠谱的安全分层
如果把第三方 skills 当成高风险供应链组件，我觉得至少应该做四层防线。
1）Pre-install scan：装前扫描，但别迷信它
装前扫描当然有价值，至少能筛掉一些低级问题：
- obvious malicious dependency
- 明显的敏感权限申请
- 可疑的外联域名
- 一眼能看出的硬编码密钥或危险命令
但它的作用，更像是 baseline hygiene，不是“扫描通过就安全了”。
2）Permission wrapper：每个 skill 外面先套一层壳
这是我觉得最容易被忽视、但最应该优先做的一层。
不要让 skill 直接裸奔地拿到宿主环境的全部能力。更合理的做法是：
- 按 skill 显式授予 tools
- 限制可访问路径
- 限制可读取 secrets 的范围
- 限制是否允许发网络请求
- 限制是否允许调用 browser / shell / messaging 等高风险能力
也就是说，skill 本身不是权限边界，wrapper 才是。
3）Network egress control：默认不要自由出网
很多 exfiltration 问题，不是读代码时一眼能发现的。
它可能只是某一步运行时，悄悄往外打一个 callback；或者把一段 context、一个 token、一份文档摘要发到某个你没注意过的域名。
所以 agent skill 的安全，不应该只看“它能不能访问本地”，还要看：
- 能访问哪些域名
- 是否允许任意 outbound traffic
- 有没有 callback / telemetry 的白名单机制
- 运行时有没有异常 egress 监控
对我来说，这一层甚至比“manifest 上写了什么权限”更重要。
4）Data isolation：tool access 不等于 data access
这是另一个特别重要的工程原则。
很多系统一不小心会把“能调用工具”和“能碰真实数据”绑定在一起。结果就是：
- 一旦 skill 能调用某个 DB tool
- 它就等于拿到了底层数据面
- 后面再谈最小权限，已经晚了
更好的设计是：
- 不直接给 raw DB credentials
- 不让第三方 skill 直接进内部系统
- 暴露 narrow、read-only、可审计的接口
- 对敏感数据做隔离和脱敏
tool access != data access，这两个权限面最好从架构上拆开。
运行时观测，才是 agent 安全的主战场
传统软件世界里，很多团队已经接受了一个事实：
供应链安全不是一次性检查，而是持续观测。
放到 AI agent 上，这个结论只会更成立。
因为 agent 的行为，不只取决于源码，还取决于：
- runtime context
- tool descriptions
- model behavior
- prompt injection
- chained tool calls
- external content
所以真正值得补的不是更多“安装前信任打分”，而是更强的 runtime discipline：
- 行为日志
- code drift 检测
- egress 审计
- secret access tracing
- 异常 tool chaining 检测
- 回放与审计能力
如果没有这些，很多问题只能等事故发生后才知道。
对 OpenClaw / agent infra 的现实启发
如果把这个思路放到更广义的 agent infrastructure，我觉得至少有几条很现实：
第一，不要把 README 当安全边界
README 是说明文档，不是可信执行证明。
第二，不要把 manifest 当行为真相
manifest 只能说明“声明了什么”，不能说明“运行时到底干了什么”。
第三，tool metadata 本身也是 attack surface
在 agent 系统里，很多人容易把 tool descriptions、plugin metadata、README、MCP server 描述这些东西当成“中立配置”。
但实际上，它们常常已经属于 prompt surface 的一部分。
一旦 skill 会读取或间接受影响于这些文本，它就有可能被：
- 注入误导性指令
- 诱导扩大调用范围
- 借描述文本触发跨工具串联
所以元数据不是天然安全的元数据，它也需要 threat modeling。
第四，最好的问题不是“能不能信”，而是“失控时损害多大”
成熟系统的核心，不是把所有组件都假设成完美可信，而是：
- 有边界
- 有审计
- 有降级
- 有隔离
- 有恢复能力
当你能回答“这东西要是出问题，最多伤到哪里”，系统才算真的开始成熟。
一个更务实的上线流程
如果让我给第三方 AI agent skills 总结一个更实用的上线流程，我会建议：
- 装前静态扫描：扫依赖、扫 obvious risk、扫权限声明
- 包装权限边界：不要裸给工具、文件、网络、消息能力
- 测试环境先跑 fake data：别第一轮就碰真实数据
- 显式限制出网：做 egress allowlist 或至少做日志
- 数据面和工具面分离：优先给窄接口，不给底层凭据
- 上线后持续监控：看 code drift、异常 callback、secret access、tool chaining
- 出问题时可回放：能追踪、能审计、能迅速收缩 blast radius
这套流程看起来比“装个 skill”麻烦很多。
但现实就是：如果一个 skill 有能力接触你的文件、网络、浏览器、上下文和自动化工具链，那它本来就不该被当成“轻量无害”的东西。
结语
关于第三方 AI agent skills，我现在越来越倾向于一句话：
不要问它值不值得信任，要问你的系统有没有能力在它不可信时仍然保持安全。
这不是悲观，而是工程成熟度。
在 agent 时代，真正可靠的系统，不是建立在“我们相信所有插件都没问题”上，而是建立在：
- 默认最小权限
- 默认可审计
- 默认可隔离
- 默认可回放
- 默认可降级
当这些东西都在，第三方 skill 才有资格进入生产链路。
否则，它更像是一扇你主动打开、但不知道通向哪里的门。
