面向 Agent Harness 的可信扩展注册表与沙箱
为开源编程 Agent harness 打造的安全层:经过审核的扩展注册表、OAuth Token 安全安装,以及可阻止危险操作的原生权限引擎。
可直接粘贴到 Claude Code、Cursor 或任何编程助手的需求说明(英文)。
总分6.1/10
痛点6
付费意愿5
时机8
市场空白7
护城河5
可行性6
支持
- 谁会付费
- 20–200 人公司中采用开源 agent harness(Pi 及其衍生版本)的工程负责人与资深开发者,每团队每月愿意从开发工具或安全预算中支付 $50–200;个人高级用户每月支付 $10–20。
- 讨论中的声音 · 4
- 因为开源 harness 缺少内置的 auto mode 来阻止危险操作,而且对热门第三方模块没有任何审核,所以他们转回了 Claude Code。 查看评论 ↗
- 不愿把 OAuth Token 交给第三方扩展,理由是多次出现用户在 Token 泄露和滥用后被封号的报告。 查看评论 ↗
- 为了降低 agent 执行破坏性操作的风险,他们在 Pi 之上自行搭建了沙箱层。 查看评论 ↗
- 手动配置模式匹配规则,让危险的 CLI 调用和文件编辑需要审批,以此复现 harness 未提供的安全默认行为。 查看评论 ↗
内容转述自讨论,原评论请点击链接查看。
- 竞争对手与空白
开源 harness 的扩展生态快速增长,却几乎没有供应链审核,也缺少原生的运行时安全默认配置。通用依赖扫描器无法检测 agent 扩展中的 OAuth Token 外泄、隐藏的 prompt injection 或权限范围蔓延,目前也没有产品填补这一空白。
- 为什么是现在
- 过去约 12 个月里,Pi 等开源 harness 生态爆发式增长,基于订阅的 OAuth 访问方式也随之普及。这既带来了新的攻击面(Token 被盗进而导致账号被封),也带来了新型扩展供应链风险,而目前还没有人把相应的防护能力产品化。
- 护城河 · 5/10
- 经过审核的扩展注册表,加上持续更新的 agent 扩展攻击模式威胁情报,会随采用率增长而不断累积优势。一旦成为默认信任层,就会形成类似包管理器注册表的分发锁定效应。
反对
- 红队
- 开源 harness 扩展生态存在真实且独特的供应链风险,包括 OAuth Token 盗用和扩展中的 prompt injection。通用扫描器和 IDE 扩展完整性方案都无法覆盖这些风险,而且这一威胁窗口确实是新出现的。
- 最可能的失败原因
- Pi(或其他 harness 厂商)推出原生沙箱和官方审核注册表,在市场足够大之前就压缩了第三方的机会空间。
起步
- 最初三步
- 开发静态分析器,扫描 Pi 扩展中的 Token 外泄、网络调用和 prompt injection 模式,并发布带评分的公开注册表。
- 为 Pi 推出权限策略扩展,实现 auto mode(阻止危险命令、审批规则),让用户原生获得媲美 Claude Code 的安全能力。
- 发布「加固配置」套件(沙箱启动器加经审核的扩展),以团队席位方式销售,并支持组织级策略强制执行。
- 原始讨论
- Goodbye Claude, hello Pi ↗ 605 点391 条评论源自评论原文链接
本文译自英文。 阅读原文