为什么你的AI智能体的“记忆”是一场潜在的数据泄露。

我们都在构建具有“记忆”的AI智能体。让单租户智能体在本地运行非常容易。但一旦我们尝试将其扩展到多租户SaaS，几乎所有人都会采取完全相同的捷径。我们将10,000个用户塞进一个共享的向量数据库（如Pinecone、pgvector等），然后在查询中附加一个 `{"tenant_id": "123"}` 过滤器。人们称之为“租户隔离”，但说实话，它只是一个 `WHERE` 子句。以下是关于AI的可怕之处。如果在普通SaaS应用中，元数据过滤器遗漏或触发错误，用户通常只会看到空白的面板或500错误。你会注意到并修复它。但如果这个过滤器在AI检索路径中遗漏了呢？这个漏洞是完全无声的。向量搜索会直接从整个数据库中拉取最近的邻居。你的LLM在无声中摄取用户A的专有文档或私人聊天记录，并自信地将这些秘密幻化成用户B的答案。你无意中交叉污染了你客户的私有数据。这就是为什么逻辑隔离（命名空间、RBAC、元数据标签）对AI来说是一颗定时炸弹。你所有的安全控制都位于与应用程序代码完全相同的错误半径内。如果你在服务真实客户，保证零数据泄漏的唯一方法就是物理隔离。每个用户都需要自己物理上独立的数据库环境。如果检索漏洞发生，AI实际上无法读取其他租户的数据，因为数据根本不在其连接的数据库中。我知道管理1000个隔离的数据库听起来像一场DevOps噩梦（Terraform蔓延、代理路由等），但实际上现在存在编排工具可以使其变得可管理。我很好奇这里真正构建AI智能体的人。你们是否为每个用户物理隔离了向量存储？还是你们只是祈祷元数据过滤器永远不会遗漏子句？