隐私是设计出来的

这一页是写来给人核查的。如果你处理的是别人的法律、移民或医疗事务，下面这些说法，你的客户迟早会要你拿出证据。

两道互相独立的边界

隔离由数据库强制，不靠应用代码。 行级安全策略意味着一条忘了加过滤条件的查询返回的是空，而不是别人的数据。应用层的范围限定，离一次数据泄露只差一个漏写的 WHERE；这是另一个量级的保障，也正是平台把边界放在那一层的原因。

加密与之互不依赖。 就算拿到了数据库，对话和文档内容也是密文。

信封结构

加密字段按固定布局存储：

这个形状带来两个结果。

密钥可以轮换，无需数据迁移。 版本号跟着密文走，所以一个用户可以同时持有多把数据加密密钥：新写入用当前生效的那把，读取时按密文写入时用的那把来选。轮换于是变成一场渐进的重加密，而不是一次全线停摆——这很重要，因为需要停机的轮换方案，往往永远不会被真正执行一次。

密文搬不了家。 AEAD 的附加认证数据把每个值绑定到它的 (tenant, user, space, field)。把一段密文复制到另一行、另一个字段或另一个租户的记录里，结果是解密失败，而不是悄悄吐出内容——所以数据库层面的篡改尝试，不会演变成数据泄露。

密钥放在哪儿

每位用户的数据加密密钥由一把密钥加密密钥包裹，背后是一层密钥提供方抽象。当前实现从应用密钥配置中读取 KEK。留这个接缝，是为了让 KMS、密钥保管库或按租户自带密钥能够通过配置引入——不必改动数据模型，也不必改动任何调用代码。

把当下的状态说清楚：今天 KEK 由应用持有。这对现阶段的部署是合适的，但它和「客户自管密钥」不是一回事。

任何托管型智能体都有的上限，以及该怎么办

敏感对话可以再加一层端到端加密：客户端发送一把临时 ECDH（P-256）公钥，服务端通过 ECDH 和 HKDF 派生会话密钥，每一段流式输出用 AES-GCM 加密并在浏览器里解密。它在 TLS 之上，进一步降低了流式传输层的暴露面。

它不是零知识，任何托管型智能体也做不到零知识。 这一点值得直说，因为这是问题本身的性质，而不是这套实现的缺陷：要从你的知识库里检索，服务端就必须对你的内容做向量化和比对；要作答，就必须基于检索到的片段生成。一个读不了材料的系统，既搜不了它，也没法从它出发作答。「零知识知识库」是个自相矛盾的说法，任何同时兜售这两样的供应商，至少有一样说得很含糊。

所以诚实的问法不是「运营方能不能读到内容」，而是运营方是谁。

在我们的云上，我们把暴露面压到最小

• 内容在静态存储时用按用户的密钥加密，导一份数据库出去也读不出东西。
• 隔离由数据库强制，不靠应用代码。
• 送进模型的只有当前这条消息、为它检索到的片段，以及该终端用户的记忆——绝不会整库送，也绝不会送别人的数据。
• 端到端那一层保护响应流。

这是实打实的暴露面缩减。但它不等于我们读不了一段对话——与其让你从客户的审计师那里听到这句话，不如我们自己先说。

如果要求是绝对的，那就自己跑

如果你的义务意味着内容确实不能落到第三方手里，答案不是一句更强硬的加密宣称，而是一种把我们从链路上拿掉的部署方式。

平台可以部署到你自己掌控的基础设施，包括你自己的云账号，模型端点指向你自己托管的模型。在这种形态下，你的文档和对话不会离开你的网络，能接触到它们的运营方就是你自己。它比共享资源贵，这就是那笔交易：合规是用基础设施买来的，不是用形容词买来的。

专属部署如何划定范围、如何运维、如何计费，见企业版。

有什么会送到模型那里

回答一条消息时，送给模型的是：这条消息、为它检索到的片段，以及为该终端用户召回的记忆。 不是整个知识库，也绝不会是另一位用户的数据——在拼装任何东西之前，检索就已经被限定在空间之内。

如果你配置了自己的模型供应商，内容会依你与对方的约定送到该供应商，适用的是他们的留存与训练条款。那是你的合同，不是我们的，值得读一读。

删除

删除一份文档时，它对派生记忆的贡献也会一并移除，而不是让内容通过一条比来源活得更久的记忆被找回来。留存期限以及账户关闭时的删除路径写在隐私政策里，面向企业客户的处理承诺写在 DPA 里。

这在实际使用中意味着什么

• 一个查询的 bug 不可能暴露另一位客户的对话，因为数据库直接拒绝。
• 一份被偷走的数据库导出，读不出可用内容。
• 密钥可以在日常运维中轮换，所以轮换才真的会发生。
• 端到端选项是真的，但有边界——而当要求是绝对的，答案是换一种部署模式，而不是对共享模式说一句更硬的话。