多租户 Agent 的长期记忆怎么做隔离、加密和可删除？

先这样答

多租户 Agent 的长期记忆需要通过存储分区、应用层加密和级联清理来实现隔离、加密与可删除。隔离工作在租户与用户两个维度展开。系统在底层数据库建立集合级或行级隔离。检索记忆时，系统直接从当前会话身份提取过滤条件。系统强制将这些条件注入底层数据库的检索语句。系统绝对不能信任大模型生成的参数。依赖模型传参引发越权访问的风险很高。

记忆数据的加密主要针对敏感字段。系统在应用层执行加密操作。系统按租户维度分配和管理加密密钥。每个租户拥有独立的密钥。系统在数据写入底层存储前完成加密。系统在读取数据后在应用层完成解密。

删除记忆必须满足 GDPR 等隐私合规要求。系统接收到用户的删除请求后，触发级联清理流程。系统依次定位并删除向量库、缓存系统和数据备份中的对应条目。系统必须保证删除结果可验证。开发人员在处理缓存层时经常漏掉隔离条件。缓存键如果没有包含租户标识，就会直接导致数据越权。

面试官会怎么追问

• 「为什么说检索时不能信任模型传参？」 模型存在幻觉和提示词注入风险。用户可以构造恶意提示词。模型受诱导后会输出其他租户的参数。系统如果直接使用该参数查询数据库，就会发生数据越权。后端必须从会话身份中提取过滤条件并强制注入。

• 「敏感字段应用层加密的密钥怎么管理？」 系统按租户维度分配和存储密钥。系统在业务逻辑层拦截读写请求。系统根据当前会话的租户身份获取对应密钥。系统在内存中完成加解密。底层数据库只存储密文。

• 「级联删除备份条目怎么做到可验证？」 系统执行删除操作后需生成清理日志。日志带有时间戳。日志详细记录向量库、缓存和备份的清理状态。系统提供专用接口供审计人员查询校验。这能满足 GDPR 等合规要求的举证需要。

回答的坑

候选人误以为底层数据库做了行级隔离就足够，忽略了缓存层的越权风险。

候选人提出让大模型自己判断并过滤敏感数据，这直接违背了不信任模型传参的安全原则。