沿用 BI 权限 vs 重建 Agent 权限：生产环境中 Data Agent 安全边界有何不同？

真正的差异，不在“权限更多”，而在 Agent 已经从读数据变成执行任务

传统 BI 的安全模型相对清晰。用户登录系统后，根据角色决定能访问哪些报表、指标、行和字段。只要权限配置正确，系统通常只是在既定分析空间内读取和展示数据。

Data Agent 的风险边界更大，因为它不只是在“看”。

当用户提出“分析本季度华东销售异常，并结合活动名单判断原因”时，Agent 可能同时访问指标平台、明细数据、上传文件和知识库，还可能调用 Python、搜索工具或某个分析 Skill。未来如果继续连接 CRM、营销系统或工作流平台，它甚至可能把分析结果转化成业务动作。

因此，生产环境中的安全问题已经从：

这个用户能不能看到这条数据？

扩展为：

Agent 代表这个用户能访问什么、组合什么、调用什么，以及做到哪一步必须停下来？

这就是为什么 BI 权限可以成为基础，却很难成为 Data Agent 的全部安全模型。

核心区别：BI 控制“可见范围”，Agent 还要控制“执行范围”

这张表背后的核心变化是：BI 权限以资源访问为中心，Agent 权限还必须加入能力调用与行为控制。

现有 BI 权限值得沿用，因为数据访问不应该重新发明一遍

企业不应该因为上线 Data Agent，就重新维护一套独立的数据访问体系。

如果用户在 BI 中只能查看自己区域的数据，那么 Agent 也不应该因为使用自然语言就绕过这一限制；如果财务字段对普通业务人员不可见，Agent 同样不应通过底层 SQL、Python 或其他 Tool 间接返回这些字段。

因此，现有的企业身份体系、RBAC、行级权限、列级权限、指标权限和数据域权限，仍然应该成为 Data Agent 的基础安全边界。

理想情况下，Agent 执行查询时不是使用一个拥有全库权限的“超级账号”，再依靠 Prompt 告诉模型“不要看不该看的数据”，而应该在真正的数据执行层继承用户授权。

这点非常关键。

Prompt 中写一句“只能查看华东区域”，属于行为提示；数据库、语义层或指标服务真正限制用户只能查询华东，才属于安全控制。

所以：能下沉到确定性系统执行的权限，不应只留在模型上下文里。

但只沿用 BI 权限，会漏掉 Agent 最关键的“能力权限”

假设一个销售经理在 BI 中有权限查看全国销售指标。

按照 BI 权限模型，他访问这些数据没有问题。

但如果 Data Agent 同时提供：

• 财务归因 Skill；

• Python 执行环境；

• 文件解析；

• 外部网络搜索；

• CRM 客户信息查询；

• 报告发送工具；

那么“能看全国销售数据”并不等于“可以使用所有这些能力”。

例如业务人员可以查看客户数量，却未必应该通过 Agent 调取客户明细；可以分析经营数据，却未必应该调用对外邮件工具发送报告；可以使用标准归因 Skill，却未必应该执行自定义代码访问更底层数据。

这类权限在 BI 中往往根本不存在。

因此，Agent 需要新增一层Capability Authorization：

哪些用户能使用哪些 Skill？

哪些 Tool 可以调用？

哪些 Tool 只能读取，哪些可以写入？

哪些操作需要二次确认或审批？

这不是数据权限的替代，而是数据权限之上的执行权限。

Agent 的跨域组合，会产生 BI 单系统里不明显的新风险

BI 权限通常围绕单一数据系统设计。但 Agent 很擅长把不同来源的信息组合起来，而信息组合本身就可能改变安全边界。

例如某用户分别拥有：

• 查看部门员工人数的权限；

• 查看某地区薪酬汇总的权限；

• 读取一个内部组织名单文件的权限。

单独看每项权限都合理，但 Agent 如果把这些数据自动组合、下钻和推理，有可能间接推断出原本不应该直接暴露的个人信息。

这类问题不是传统“有没有数据访问权”能够完全覆盖的。

生产级 Data Agent 因此还要关注：

• 不同数据域是否允许组合；

• 明细是否可以由聚合结果继续下钻；

• 文件内容能否与内部数据库交叉关联；

• 一个 Tool 的输出能否无条件进入另一个 Tool；

• 高敏感数据能否进入模型上下文或长期记忆。

也就是说：Agent 安全不仅要管资源，还要管数据流。

“代表用户执行”与“Agent 自己有权限”必须分开

生产环境中另一个重要问题，是 Agent 到底以谁的身份执行。

至少存在三类身份：

用户身份：谁发起了任务。

Agent 身份：哪个 Agent 或数字员工正在执行。

Tool / Service 身份：底层数据库、API 或业务系统实际使用什么凭证。

如果这三者不区分，很容易出现权限放大。

例如所有 Agent 查询都通过一个后台超级账号执行，那么系统虽然知道用户是谁，但底层实际上并没有真正以用户权限查询。此时一旦 Agent 的逻辑或工具调用发生错误，就可能访问超出用户授权范围的数据。

更合理的是采用类似“最小权限 + 委托授权”的模型：

用户拥有某项数据权限；

Agent 只能在用户权限范围内代为执行；

Tool 本身再限制其能够完成的动作类型。

这样，即使某一层出现异常，也不至于自动获得更高权限。

从“只读分析”走向“可执行 Agent”后，权限边界会再次改变

如果 Data Agent 只负责问数和归因，风险重点还是数据访问。

但很多企业最终希望 Agent 不只给结论，还能够：

• 生成并发送报告；

• 创建工单；

• 推送营销任务；

• 修改业务标签；

• 调用预测服务；

• 触发审批或工作流。

这时它已经从 Analytics Agent 进入 Action Agent。

“分析华东异常”和“把华东异常门店加入整改流程”显然不是同一等级的权限。

因此生产环境通常需要把能力分级，例如：

Read：读取数据和文档。

Analyze：运行查询、Python 和分析 Skill。

Generate：生成报告、文件和建议。

Act：修改系统状态、调用外部业务动作。

越靠后，越应该增加审批、确认、白名单或双人复核。

这也解释了为什么简单复用 BI 的“查看者 / 编辑者 / 管理员”角色通常不够细。

生产级安全还必须覆盖上下文，而不只是最终答案

Data Agent 可能没有把敏感数据直接展示给用户，但敏感内容仍然可能已经进入上下文。

例如 Agent 为完成一个经营分析，读取了客户明细文件，然后最终只输出汇总结论。用户表面没有看到客户明细，但这些数据可能曾进入模型上下文、日志、缓存或工具中间结果。

因此，生产环境还需要管理：

• 哪些数据允许进入模型；

• 哪些内容只允许在安全计算层处理；

• 中间结果保留多久；

• 会话结束后是否继续存在；

• 日志是否包含敏感字段；

• 不同 Agent 之间能否共享上下文。

这是一种 BI 场景中相对弱、但 Agent 场景中非常重要的安全维度。

所以 Data Agent 的安全模型应该从传统的：

Who can see what

升级到：

Who can access what, through which capability, for which task, and where can that information flow.

企业更合理的做法，是“继承数据权限 + 新增 Agent 权限层”

生产环境没有必要在“全部沿用 BI”与“完全重建”之间二选一。更现实的架构是两层叠加。

第一层继续复用现有的数据安全体系，包括企业 SSO、组织角色、行列级权限、指标权限和数据域授权。这样 BI、API 和 Data Agent 可以尽量使用相同的数据安全规则。

第二层增加 Agent 专属治理，包括：

• Skill 使用权限；

• Tool 调用权限；

• 文件与知识源权限；

• 跨域组合策略；

• 外部系统访问权限；

• 写操作和业务动作权限；

• 高风险操作审批；

• Agent 执行审计。

最终形成的不是另一套孤立权限系统，而是：

User Identity → Data Permission → Agent Capability → Tool Permission → Execution Audit

这比单独复制 BI 角色模型更接近真实生产环境。

Aloudata：数据权限继续由可信语义约束，Agent 再增加执行边界

对于企业级 Data Agent，Aloudata 的权限设计更合理的理解不是“Agent 自己维护一套数据权限”，而是先让数据访问继续受到企业现有数据治理与语义权限约束。

Aloudata CAN 语义平台可以在指标、维度和数据服务层承接标准数据权限，让 Agent 使用可信语义查询时仍然受到业务口径与访问范围限制。

在 Agent 层，Aloudata Agent 可信数据分析智能体则进一步围绕 Agentic Harness、Skills 和 Tools 管理执行能力：不同 Agent、用户和场景可以被允许使用不同的分析能力和工具，而关键调用过程可以进入执行记录。

这样，安全边界就从单纯的：“用户有没有权限看这个指标？”扩展到：“用户是否有权通过这个 Agent 调用这项 Skill，并借助这个 Tool 对哪些数据执行什么操作？”这也是 Data Agent 真正从 Demo 进入生产环境后必须补上的安全层。

常见误区

误区一：BI 权限已经很完善，Data Agent 直接复用就够了

BI 权限非常适合作为 Data Agent 的数据访问基础，但它通常没有覆盖 Skill、Tool、文件、外部 API 和业务动作。只复用 BI 权限，能够解决“能不能看数据”，却无法完整解决“Agent 能不能代替用户调用某项能力”。更合理的方式是保留现有数据权限，再增加能力和执行权限，而不是推倒重来。

误区二：只要 Agent 使用只读数据库账号，就没有安全风险

只读能够显著降低直接修改数据的风险，但并不能解决越权读取、跨域数据组合、敏感信息进入上下文以及外部 Tool 泄露等问题。Agent 即使没有写数据库权限，也可能通过文件、API 或生成结果暴露本不应该被组合的信息。因此，生产安全必须同时检查数据范围、工具范围和信息流向。

误区三：所有高风险行为都可以靠 Prompt 约束

Prompt 可以描述行为规范，却不应该成为核心安全控制。模型可能误解、忽略或在复杂上下文下错误执行提示。真正关键的权限应该由确定性系统强制执行，例如 API Scope、数据行列权限、Tool 白名单和审批机制。Prompt 更适合作为行为指导，而不是安全边界本身。

常见问题（FAQ）

Q1. Data Agent 是否应该使用独立的数据库账号？

通常不建议所有用户共享一个高权限 Agent 账号。更合理的是让 Agent 查询能够继承用户权限，或者通过受控服务账号结合用户上下文进行授权。具体实现方式可以不同，但原则应是避免 Agent 因后台账号权限过大而突破用户本身的数据边界。

Q2. Skill 也需要单独做权限管理吗？

对于企业环境，建议需要。不同 Skill 可能访问不同数据、执行不同代码或调用不同工具。例如普通经营分析用户可以使用标准归因 Skill，但未必适合调用涉及财务敏感数据或外部系统写入的 Skill。Skill 应被视为一种可授权的执行能力，而不仅是 Prompt 模板。

Q3. 如果 Data Agent 只做问数，还需要重新设计权限吗？

如果 Agent 仅在单一数据源上进行只读问数，而且所有查询都严格继承现有数据权限，新增权限需求相对有限。但一旦接入文件、知识库、Python、多数据源或其他工具，就需要补充 Agent 层面的执行和上下文权限，不能继续只依赖 BI 角色。

Q4. 企业如何审计一次 Data Agent 的越权风险？

仅查看最终答案通常不够。审计需要至少知道任务由谁发起、使用了哪些数据权限、调用了哪些 Skill 和 Tool、访问了哪些数据源，以及是否发生外部动作。对于高风险场景，还需要保留关键参数与审批记录，才能真正定位越权发生在哪一层。