信任模型
X-Hub 强调的是结构性安全优势,而不是安全表演。它不声称风险会消失,而是强调一个恶意文件、一次提示词注入、一个被接管的终端或一个导入能力,不应该直接演变成整个系统的完全失控。
公开安全立场 这一页描述的是系统安全姿态和公开设计方向,不是完整控制项清单。更细的实现细节、边缘处理和仍在演进的防线不会全部公开在这里。
核心安全立场
X-Hub 从几条结构性前提出发:
- 终端不应成为信任根
- 高风险动作不应在授权含糊或状态不完整时继续执行
- 准备状态不足时应 fail-closed
- 安全边界应由策略、授权、审计和运行时真相共同构成,而不是只靠提示词
这套设计想改善什么
| 常见风险模式 | X-Hub 的设计方向 |
|---|---|
| 一个客户端被攻破就演变成全系统被接管 | 信任、授权和高风险执行继续锚定在 Hub |
| 读取恶意内容直接演变成泄密或破坏性动作 | 策略、受控执行和系统级控制比 prompt-only 防护更可靠 |
| 一旦安装能力就悄悄扩大权限 | 能力被当作受控单元处理,而不是 install-equals-trust |
| 操作者最后看不清系统到底做了什么 | 审计、运行时真相和显式系统姿态是产品方向的一部分 |
Fail-Closed 而不是假象恢复
公开设计立场很明确:当链路不可信时,系统应该倾向于阻断,而不是假装一切正常。
- 没有有效授权,就不应继续高风险执行
- 没有 readiness,就不应静默继续
- 目标不明确的授权,不应靠猜测补齐
- 配对损坏或信任状态过期时,应阻断而不是掩盖
为什么这比 prompt-only 更强
提示词可以影响行为,但它不是信任边界。
X-Hub 依赖的是多层控制:
- 控制平面上的策略与授权
- 对操作者可见的运行时姿态
- 仍然挂在系统记录面上的记忆与指导
- 能帮助解释“到底发生了什么”的审计链
- 一条更适合掌控隐私和依赖关系的本地优先路径
这样做的意义在于,系统边界由持久控制项决定,而不是由当下哪个 prompt 或客户端恰好处于激活状态决定。
为什么用户自有姿态重要
如果 Hub 跑在用户自有硬件上,并把核心路径尽量留在本地,你需要额外信任的外部系统就会更少。
这能改善:
- 隐私姿态
- 密钥处理方式
- 对外部模型供应方的依赖
- 发布时间与变更控制
这不等于“风险消失”。本地入侵、恶意文件、实现缺陷和操作失误仍然存在。重点不是神奇安全,而是更可辩护的信任边界。
云端默认与用户自有控制
| 典型云端 agent 默认形态 | X-Hub 立场 |
|---|---|
| 厂商托管控制平面 | 用户自有 Hub 主机 |
| 厂商默认持有更多运行时真相 | 记忆真相、路由与审计锚定在 Hub |
| 密钥处理与策略隐藏在 SaaS 默认配置后面 | 授权、readiness、姿态和发布时间由操作者决定 |
| 本地模式弱或只是附属 | 本地与付费模型都可以进入同一受控平面 |
安全敏感团队能得到什么
- 通过结构设计降低 blast radius
- 当路径降级或阻断时,更清楚地看到运行时真相
- 对隐私、密钥和执行 authority 的更可信控制
- 一条更安全的外部 ingress 与能力治理路径
- 一套比 install-equals-trust 生态更稳的基础