Skip to content

信任模型

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 生态更稳的基础