公司大脑拒绝回答？Need-to-Know让AI先问权限

企业AI助手总面临一个灵魂拷问：它会不会把工资表泄露给实习生？大多数演示产品避而不谈，而开发者Mayur Khan在Graph Hacks黑客松上构建的Need-to-Know选择了正面硬刚——这个公司大脑的第一职责，不是回答所有问题，而是弄清楚谁有权知道什么。

项目演示地址和代码已开源，它基于图数据库FalkorDB，用一套权限链路来约束AI的每个回答。

访问权限的本质，是一张图

在真实企业里，访问权很少是“这个人能打开这个文件”这么简单。更常见的是这样的链条：Priya属于Support组，Support组属于All Staff，All Staff组在2023年被临时加入Drive迁移项目，而该项目拥有工资表的访问权。没人记得最后一环，也没人能自信地回答“到底谁能看到这份工资表”。

而一个从所有文档中找答案的聊天机器人，会让这条隐藏链变成所有人的麻烦。Need-to-Know的解法是把成员关系链建模为图数据库中的边。在FalkorDB中，一段Cypher查询就能沿着MEMBER_OF关系遍历最多8层嵌套组，找出某人（或某个AI代理）能读取的所有内容。查询的中位耗时是0.45毫秒，快到可以在每个问题、每个代理步骤上实时运行。并且权限从不缓存，不存在过期访问的隐患。

Cypher 是 Neo4j 公司主导的图数据库查询语言，语法上借用 ASCII 艺术描绘图模式，例如 (p:Person)-[:MEMBER_OF*1..8]->(g:Group) 表示从人节点出发沿 MEMBER_OF 边遍历 1 到 8 跳。FalkorDB 兼容 Cypher 的一个子集，因此原文才能用一条查询把嵌套组链一次性展开。与传统 SQL 需要反复递归 JOIN 不同，Cypher 把“图”当作一等公民，遍历成本与路径长度近似线性，这使得亚毫秒级的实时权限判定成为可能。

一个会“思考”的大脑

开发者生成了一个逼真的公司Northwind Labs作为测试环境：211名员工、9个团队、19个嵌套组、21份文档和对话、3个客户和3个AI代理，还刻意埋了三个现实中的权限错误。

整个公司图谱被绘制成一个大脑的形状：领导层位于额叶，客户团队在后部，文档在记忆叶，AI代理在小脑，FalkorDB是脑干。当你提问时，信号从你开始，穿过你所属的组，到达每个被允许的文档；被阻止的文档会收到红色信号并中途停止。动画严格遵循数据库实际使用的路径，因此是对答案查找过程的一次忠实呈现。

同一问题，不同的人，不同的答案

以Support实习生Priya的身份询问“Acme公司10月的发票为什么涨了？”，她会从定价政策中得到答案：忠诚折扣持续12个月且不会自动续期，每个事实都标注了来源和负责人。但她不会看到合同金额和发票流水，取而代之的是一行锁定提示：“合同金额与折扣。需要财务或领导层权限。请联系Arjun Mehta。”

而换成财务负责人Meera问同样的问题，那些隐藏的行就变成了真实的答案。大脑不会假装受限制的东西不存在，也不会泄露它——它告诉你缺了什么，以及该找谁。

“我为什么能看到这个？”

每个事实都有一个按钮，可以展示其背后最短的组链，比如“Priya → Support → All Staff → 公司手册”。访问权不再是谜。

每个人和每个代理的私有记忆

大脑会记住你之前问过的问题。每个记忆挂在图中其所有者的节点上，并且每个记忆查询都从你的节点开始。这意味着从我的节点到你的记忆根本没有路径。演示中直接证明：“Priya有4条记忆，Meera能触达0条。”

AI代理遵守和人类相同的规则

代理也像人一样是组的成员，因此它们获得的权限恰好是其所属组所拥有的。在演示中，Support Agent和Finance Agent共享客户工单#4821。Finance Agent添加了一条仅财务可见的合同细节备注。当案例回到Support Agent时，那条备注被脱敏，因此给客户的回复不可能泄露它。如果草拟的回复确实包含财务私有数据，批准步骤会拒绝发送。

FalkorDB 是一个基于稀疏矩阵与线性代数引擎的图数据库，主打低延迟的并发图查询。它把图邻接关系映射为稀疏矩阵乘法，因此在多跳遍历和路径查找上往往比传统图数据库更快，也适合在本例这种“每个问题、每个代理步骤都要现场算一遍权限”的场景。它支持 OpenCypher 查询、内置向量索引，可通过 Docker 部署，并提供 GRAPH.COPY 这类多图（key）管理命令，这正是后文“在副本上测试修复”所用到的能力。

权限检查的三种方式，只有图是对的

开发者用Python独立重写了一遍权限规则作为基准真相，然后让54个提问者×8个问题跑过三种访问检查方式。结果极具说服力：

访问检查方式	泄露次数	错误拒绝	有用性
图遍历（Need-to-Know）	0	0	100%
扁平权限列表（仅直接组）	0	521	37.5%
无检查（普通文档聊天机器人）	840	0	100%

图遍历与Python基准在全部6,634个（人，段落）对上100%一致。扁平权限列表虽然安全但几乎无用：人们只能看到其应见内容的37.5%。无检查虽然有用，但泄露了840次。只有图既能保证安全又有用，因为只有图理解组中组。

扁平权限列表指的是只检查“用户是否直接属于某个被授权组”的实现，它不展开组中组。这样做的后果是不对称的：一方面不会泄露（因为它只会误判为无权），另一方面会把大量用户挡在理应可见的内容之外，这正是表中 521 次错误拒绝、有用性仅 37.5% 的来源。它与图遍历的关键差别不在“是否安全”，而在“是否理解传递性成员关系”——企业权限链的真实语义恰恰是传递的。

大脑会自我体检

Health check功能会比较“谁应该打开每份敏感文档”和“谁实际能打开”，并找到了三个预埋问题：

• 2026薪酬区间表： 211人能打开，而不是3人，全部通过那个被遗忘的“Drive迁移2023（临时）”组。
• Q3董事会更新： 34人而不是5人，通过一个项目组。
• Ravi Kumar从财务转到工程，却仍在财务组。仅这一个过期成员关系就解锁了5样东西。

最精彩的部分是：每个建议的修复方案都先在公司的完整副本上测试，使用FalkorDB的GRAPH.COPY。大脑fork图谱，应用修复，检查正确的人失去了访问权并且应该保留访问权的人仍然拥有它，然后删除副本。只有在这之后，人类才批准，变更被保存为大脑日后可以解释的决策记录。

GRAPH.COPY 是 FalkorDB 的多图管理命令之一，用于在同一个实例内复制出一个独立命名的图副本。在这个项目里，它充当了“权限变更的沙盒”：先复制整张公司图谱，在副本上应用修复，再验证“不该有权限的人确实失去访问、该有的人仍然保留”，最后删除副本。这种 fork-test-discard 的模式把权限修复从不可逆操作变成了可回滚实验，也是 Health check 能安全给出建议的前提。

踩过的坑与下一步

开发过程并非一帆风顺。Windows上无法原生运行FalkorDB，开发者索性在GitHub Actions上连接真实FalkorDB运行一切，结果每次推送都跑13个测试、基准测试、容器构建和所有界面的截图，然后重新部署在线演示。答案漂移也出现过：最初搜索时，任何提到“Acme”的段落都排名很高，导致问发票涨价却返回了责任上限。现在会丢弃仅匹配客户名称的段落，并对“为什么”类问题优先考虑政策和决策。

下一步计划包括：从Google Workspace、Slack和Notion导入真实组和文档的连接器；当新的共享突然扩大敏感内容的访问范围时发出实时警报；以及时间旅行——“去年三月谁能看到这份文档？”

结语

Need-to-Know的价值不在于技术堆栈有多新，而在于它重新定义了公司大脑的信任基础：一个AI助手只有在清楚“谁被允许知道什么”之后，才值得被信任。对于所有正在构建企业级AI应用的人来说，这个黑客松项目提供了一个可运行、可验证的权限优先范式。