分析型 Agent 权限设计：让恶意 Prompt 也拿不到敏感数据

一个分析型 Agent 收到了恶意指令：返回所有客户的未脱敏支付标识符。

关键问题在于，系统允许该 Agent 读取哪些数据——即使模型决定遵从这条指令。

这正是我在 MerchantLens 中探索的边界。MerchantLens 是一个基于 Databricks、Delta Table 和 Unity Catalog 构建的商户分析数据湖平台。

演示使用的是合成支付数据，项目中没有任何真实的持卡人数据。

将调用者身份放入查询路径

MerchantLens 将数据流转经 Bronze、Silver 和 Gold 三层。Agent 搜索实时目录元数据，并使用工具查询指标或 SQL。

Agent 在自己的服务主体（Service Principal）下执行查询。Unity Catalog 在返回查询结果之前，会针对该主体应用列级掩码（column mask）和行过滤器（row filter）。权限决策由查询引擎负责。

README 中包含了一份对比：在同一 SQL 语句下，分别以两个不同主体执行——分析师看到的是更广泛的数据集，而 Agent 只能看到受限的区域和被掩码处理的标识符。

将可靠性控制与授权分离

项目包含多个层次的防护：

前两层用于控制 Agent 的行为，第三层的目录策略负责数据访问。

但这并不能使整个应用免受攻击。防护效果取决于身份配置、授权授予、掩码和过滤器是否正确，以及每条查询是否都使用了指定的主体。

测试受保护的表

仓库中记录了一条实践教训：仅检查成员资格表达式（membership expression），可能会对掩码的实际效果产生误导。

更好的验证方式是：在实际身份下执行对受保护表的查询，检查返回了哪些行和值，然后将结果与预期的权限范围进行对比。

仓库还记录了在新服务主体上的环境级授权（ambient grants）。创建新身份并不自动构成默认拒绝（deny-by-default）的安全设置。

指标定义也需要边界

MerchantLens 将拒付（chargeback）归因到原始交易的月份。如果使用拒付单打开的日期，可能导致事件看起来跨越了不同月份，因为争议处理会有延迟。

这个定义应该放在语义层（semantic layer），这样仪表盘和 Agent 就能使用同一套指标。正确的权限配置无法弥补分母不一致或时间定义混乱的问题。

在给 Agent 开放仓库工具之前，先问自己：

• 哪 个主体执行它的查询？
• 它能否通过其他表或授权获取受限列？
• 受保护表的查询结果是否在那个主体下测试过？
• 工具调用是否被记录到 Agent 无法修改的地方？
• 指标定义是否明确且共享？

你的分析型 Agent 的访问控制执行在哪里：在 prompt 里、在应用层、还是在数据库？

阅读架构与平台相关发现。

本文由 AI 根据公开项目文档起草。演示观察结果来自仓库报告，并非新的验证运行。

如需进一步行动，可考虑屏蔽此人或举报滥用。