数据权限设计经常卡在同一个地方。角色建了不少，报表也配了权限，换成自然语言提问，或者让 Agent 代为执行之后，边界又开始漏。原因通常出在权限对象变了。过去只需要回答某个员工能看哪张报表，现在还要回答这个 Agent 代表谁、能碰哪些数据、能做到哪一步。
Agent 开始替人查数、改数据、发消息之后，权限问题会从页面可见性扩展到任务执行链路，Agent 安全与治理 的边界也随之变化。一套能上线的方案，至少要回答五个问题。谁在访问，代表谁访问，能看哪些数据和字段，允许做到哪一步，出了问题能不能还原。
下面按权限模型、人员权限、Agent 身份、强制执行点、动作分级、审计、越权测试和落地顺序展开。
先定权限模型，主体、数据、动作、环境都要写清
NIST SP 800-162 将基于属性的访问控制 ABAC 定义为一种逻辑访问控制方法。授权时，系统会评估主体、对象、请求的操作，以及某些场景下的环境条件，再对照策略、规则或关系，判断这组属性允许哪些操作。这个定义把权限从一张静态名单，变成了可以计算的判断。
落到企业里，可以先把权限拆成四个维度。
| 维度 | 要回答的问题 | 示例 |
|---|---|---|
| 主体 | 谁发起，代表谁 | 华东区运营；财务 Agent 代表张三 |
| 数据对象 | 哪些数据集、指标、行、列 | 订单表、毛利字段、本人负责的客户 |
| 动作 | 能做什么 | 查询、下钻、导出、写回、调用接口 |
| 环境 | 在什么条件下 | 内网、工作时间、审批通过、任务有效期内 |
权限矩阵先写清主体、数据、动作和环境，角色名称放在后面。 很多权限事故来自角色名称看起来合理，实际范围没有定义。比如大区负责人这个角色，如果没有绑定组织维度，换一个大区之后仍能看到原区域数据；再比如分析师角色给了全量只读，却没有限制导出，数据会从导出通道流走。
角色和属性可以组合使用。基于角色的访问控制 RBAC 适合描述稳定的职责边界，前面提到的 ABAC 适合描述会变化的范围。角色给粗边界，属性管动态范围。 组织架构、区域、客户归属、项目成员这些条件经常变化，适合写成属性表达式；岗位职责相对稳定，适合用角色承载。
权限还要分层。身份层回答账号、组织归属和租户隔离；功能层回答能不能使用问数、导出、订阅、分享；数据层回答能看哪些数据集、指标、维度和行；动作层回答只读、导出，还是写回业务系统。四层里任何一层缺失，都会留下缺口。
人员权限，角色管边界，属性管范围
人员权限的第一条原则是角色按职责建，不按人名建。人会转岗、离职、兼岗，职责相对稳定。角色名称可以对应大区负责人、客服专员、财务专员、数据分析师这类职责，人员通过组织关系进入角色，再由属性决定具体能看到哪些行。
行级权限控制范围。大区负责人绑定区域编号，客户经理绑定责任人字段，客服绑定自己处理的工单。条件最好写成动态表达式，跟随组织架构和客户归属自动变化，不要维护一批固定名单。
列级权限控制暴露程度。手机号、身份证号、成本价、毛利、合同金额这些字段，要明确是可见、掩码、区间展示，还是完全不可见。数值级权限控制呈现方式，比如小样本分组不展示、金额按区间展示、聚合人数低于阈值时拒绝返回。行级管范围，列级管暴露程度，数值级管呈现方式。
权责分离要写进角色设计。平台管理员负责权限配置、角色维护和审计导出，默认不看业务数据；审批人负责批准高权限申请，不默认拥有执行权；配置权限的人、审批权限的人、使用数据的人尽量分开。管理员改了什么、什么时候改的，同样要进入审计。
角色叠加要有明确规则。一个人同时属于多个角色时，建议取交集或按最严格策略生效，超出默认范围的权限走单独申请。简单取并集看起来方便，实际会让权限在叠加中悄悄放大。
| 岗位类型 | 数据范围 | 字段与呈现 | 动作边界 |
|---|---|---|---|
| 决策层 | 全组织，聚合为主 | 屏蔽个人身份信息和成本明细 | 查看、订阅，导出走审批 |
| 业务负责人 | 本业务线，绑定组织维度 | 保留业务字段，敏感字段掩码 | 查看、下钻，导出需授权 |
| 一线执行岗 | 本人负责的客户、订单或工单 | 屏蔽成本、毛利、联系方式 | 只读，默认禁止导出 |
| 数据分析师 | 按数据域放宽 | 敏感字段统一脱敏 | 查询与导出留痕 |
| 平台管理员 | 不含业务数据内容 | 不适用 | 配置权限，修改全程留痕 |
如果企业的主要场景是智能问数，行列权限、脱敏和岗位分工可以按智能问数的数据权限设计逐项对照。那篇文章把问数场景里的越权组合、敏感字段外泄和过程不可追溯拆得更细，这里重点补充 Agent 带来的身份与委托问题。
Agent 权限，独立身份加可计算的委托
每个 Agent 都要有独立身份。 身份信息至少包含 Agent 标识、所属租户、业务负责人、版本和当前任务。不要让多个实例共用一个账号，也不要用员工个人账号代替 Agent 身份。员工账号代表一个人的完整权限，Agent 借用了这个账号，后面就很难分清一次操作是人做的，还是 Agent 做的。
Agent 代表用户执行时，要同时保留三层信息。用户身份，Agent 身份，以及这次任务的委托范围。Agent 的有效权限取用户权限、Agent 权限和任务范围的交集。 用户没有的权限，Agent 不能因为自己是自动化程序就拥有；Agent 自身没有被授予的工具，也不能因为用户有权限就自动获得。
凭证要按任务签发，任务结束立即撤销。长期密钥不要写进提示词、记忆或日志。OWASP 在 Agentic Top 10 2026 中把身份与权限滥用列为 ASI03，典型情形包括凭证泄露、共享服务账号、继承范围过大的权限，以及低权限 Agent 把指令转交给高权限 Agent。多 Agent 协作时，每一次转交都要重新鉴权，不能沿用上一跳的凭证。
委托链要能回答四个问题。这个 Agent 是谁，受谁委托，委托允许它做什么，委托什么时候失效。缺少任何一项，事后追责都会变成猜测。委托范围要写成可计算的策略，不要停留在自然语言说明里。 比如财务 Agent 可以读取本部门报销单，可以发起退款申请，但不能直接确认退款；市场 Agent 可以读取聚合后的活动数据，但不能导出用户名单。
Agent 的权限还要跟随版本和工具变化。新增一个 MCP 服务、换一个模型、接一个第三方 Skill，都可能改变它能触达的系统。上线前把 Agent 可调用的 API、MCP 服务、Skills、浏览器和代码执行环境登记成工具清单，写清用途、负责人、可访问的数据范围和审批记录。默认只允许白名单内的工具，未知工具直接阻断。更完整的检查项可以参考智能体安全清单。
权限要在查询生成前生效
权限校验要放在查询生成之前。 用户输入一句话之后，系统通常要经过意图解析、语义匹配、查询生成和执行几个环节。权限校验落在查询生成之前，由策略引擎按当前身份注入行级过滤条件，并在生成阶段排除无权限字段，或者把它替换成脱敏表达式。用户看不到、改不了，也很难通过换一种问法绕开。
把权限绑在语义层上，维护成本会更低。指标、维度和逻辑模型在这里有统一定义，一份权限策略可以同时约束问数、报表和下游分析，不必为每个新报表重新配一遍。指标口径不统一，权限就没有稳定的绑定对象。同一个活跃用户指标在两条业务线指代不同范围，行级条件很难判断该收窄到哪一层。
提示词可以影响模型如何理解问题，不能决定数据是否可见。 模型可以提出查询计划，是否可以执行，由策略引擎和下游系统判断。OWASP 在 LLM06:2025 的建议里也强调，授权应在下游系统执行，所有通过扩展发出的请求都要按安全策略校验，不能依赖模型自己判断某个动作是否允许。
默认拒绝要成为策略的起点。没有明确授权的数据对象、字段和动作，先拒绝，再按申请开通。无权限时优先使用脱敏、范围收敛或聚合展示，减少用户被反复拒绝后回到线下取数的路径。拒绝信息也要控制，不要返回表结构、字段名或策略细节，避免帮助对方试探边界。
接口直连是常见的绕过路径。页面上的筛选器可以隐藏，服务端的校验不能省。所有查询接口、导出接口、分享接口和 Agent 工具调用接口，都要走同一套策略判断。前端筛选是体验功能，服务端策略才是安全边界。
读、导出、写入、执行分开授权
数据权限经常只回答了能不能看，没有回答能不能带走、能不能改、能不能代替人执行。把动作拆开，权限才有可控的粒度。
| 动作类别 | 典型行为 | 控制重点 |
|---|---|---|
| 读取 | 查询、下钻、查看看板 | 行级范围、列级脱敏、聚合阈值 |
| 导出 | 下载、批量复制、分享外链 | 单独授权、行数上限、水印、有效期、审批 |
| 写入 | 修改、删除、写回业务系统 | 最小字段、事务与回滚、双人复核 |
| 执行 | 调用 API、运行代码、发消息 | 工具白名单、沙箱、频率限制、人工确认、紧急关停 |
导出是独立权限，不能跟着查询权限默认放开。 能看一万行，和能带走一万行，风险完全不同。导出要单独授权，配合单次行数上限、频次限制、水印、链接有效期和审批。分享链接要绑定身份，继承原数据权限，不能生成一个谁拿到都能打开的公网链接。
高风险动作默认转人工，审批超时按拒绝处理。 支付、退款、删除数据、修改权限、变更生产配置、批量导出客户信息、对外发布内容、代表企业作出承诺，这些动作不适合由 Agent 独立完成。中低风险动作可以授权执行，高风险动作转人工确认。审批系统异常、审批人无响应、找不到对应规则时，不要默认放行。
OWASP 在 LLM06:2025 中把过度代理归为三类原因，功能过多、权限过大、自主过高。对应的控制手段也比较明确。只保留任务需要的最小工具集，只授予完成任务所需的最小权限，对高影响动作设置人工确认，对工具调用和下游系统保留日志与监控。最小权限之外，还要有最小自主性。 有些任务适合 Agent 给出建议、由人确认后执行；有些任务可以自动完成，但要限制频率、范围和可回滚性。
代码执行、网页操作、文件删除这类能力要放进沙箱或容器，和生产密钥、核心数据库隔离。批量操作要设置速率限制，给监控留出发现异常的时间。紧急关停开关要放在模型之外，由授权人员随时暂停或关闭 Agent，关停后能撤销凭证、隔离环境、回滚数据并保留现场证据。
审计要能还原一次访问的完整链路
审计要回答谁在什么授权下对什么数据做了什么，结果如何。 只记录一句任务成功，事后无法定位问题。审计事件至少包含下面这些字段。
| 字段 | 记录什么 |
|---|---|
| 任务标识 | trace_id、task_id、会话标识 |
| 人员主体 | 账号、组织、角色 |
| Agent 主体 | Agent 标识、版本、所属租户、业务负责人 |
| 委托关系 | 代表谁执行、授权来源、授权有效期 |
| 数据对象 | 数据集、指标、字段、行级范围 |
| 策略决策 | 命中哪条策略，允许、拒绝还是脱敏 |
| 动作与结果 | 查询、导出、写入、执行，返回行数、是否成功 |
| 审批与环境 | 审批人、审批时间、来源 IP、设备、环境 |
同一个任务标识要串起人的提问、Agent 的推理和工具调用、策略判断、数据返回和审批记录。只看最终结果，很难判断是意图理解错了、权限配宽了，还是工具调用越界。Agent 的可观测能力和审计可以共用一条链路，具体字段和定位方法可以参考Agent 可观测。
日志要防篡改、控访问、可检索。 日志写进去之后不能被普通管理员随意修改，查看日志本身也要有权限。保存期限由适用法律、行业监管、合同和内部追责要求共同决定，高风险场景通常需要更长。日志里的手机号、身份证号、密钥和原始对话内容要脱敏或截断，避免审计系统变成新的泄露源。
监测要覆盖几类信号。短时间内的批量导出，连续被拒绝的越权尝试，跨区域或跨租户的查询组合，Agent 突然调用新工具，权限策略被修改，Agent 版本发生变化。发现异常后要有告警，告警后要有人处理。季度做一次全量权限复核，转岗、离职、组织合并、Agent 下线这类事件触发即时回收。权限系统要能随组织变化回收，才算闭环。
上线前用这组越权测试验收
权限配完不等于生效。上线前用低权限账号跑一遍真实路径，重点看下面的用例。
| 测试项 | 怎么做 | 通过标准 |
|---|---|---|
| 换一种问法 | 用同义表达，换区域、渠道、时间口径提问 | 结果始终收敛在授权范围 |
| 聚合反推 | 用多维分组把样本切得很小 | 触发阈值保护或拒绝 |
| 明细下钻 | 从汇总一路点到个人级记录 | 列级策略每一步都生效 |
| 多角色叠加 | 给测试账号同时挂两个角色 | 按既定交集或最严格规则生效 |
| Agent 继承员工权限 | 让 Agent 借用员工账号查数 | 不能获得超出委托范围的权限 |
| 多 Agent 委托链 | 让低权限 Agent 转交高权限 Agent | 每一跳重新鉴权，越权请求被拒 |
| 导出与分享 | 超量导出、导出敏感字段、生成外链 | 被限制或进入审批 |
| 接口直连 | 绕过界面直接调用查询接口 | 服务端同样校验 |
| 提示词注入 | 在文档、邮件或网页里埋入越权指令 | 任务目标不被改写，工具调用被拦截 |
| 权限变更回归 | 调整组织或策略后重跑上述用例 | 新范围按预期生效，旧权限被回收 |
越权测试要用低权限账号跑真实路径。 测试记录至少保留请求内容、命中的策略、返回结果和日志片段。发现问题后先修策略，再重跑同一组用例，不要只修某一次查询。
落地顺序，先收权限，再扩展智能
权限建设不需要一开始就做成大平台。按下面的顺序推进，能比较快地收住高风险口子。
- 盘数据与主体。列出数据域、敏感字段、岗位角色、Agent 清单、工具清单和委托关系。先知道有哪些数据、哪些主体，再谈策略。
- 收身份与凭证。给每个 Agent 独立身份，清理共享账号、长期管理员权限和写在配置里的密钥，任务凭证按需签发、到期撤销。
- 配策略与执行点。先覆盖行级范围、列级脱敏和导出权限，再把策略绑到语义层和查询入口，默认拒绝，服务端强制执行。
- 建审计与告警。统一任务标识，补齐人员、Agent、委托、数据、动作、策略和审批字段，设置导出、越权、权限变更等告警。
- 做复核与变更管理。季度全量复核，转岗离职即时回收，Agent 新增工具或更换版本时重新做权限评审和越权测试。
常见坑集中在几处。只在展示层脱敏，查询、导出和接口仍然是明文；Agent 共用员工账号，操作记录分不清人和程序；多角色简单取并集，权限越叠越宽；只管查询不管导出和分享；日志只有一个任务成功，没有任务标识和策略决策；把提示词当成安全边界，以为写一句不要越权就能挡住。
平台能力可以承接一部分工程工作。ThinkingAI 的 Agentic Engine 支持私有化部署，Agent 管理模块提供 RBAC、数据访问级别设置、敏感操作审批流、多账号隔离、日志审计，以及任务调度和运行监控。企业仍需把数据分级、角色边界、审批规则和审计字段定义清楚，具体到行列级策略、审批流和日志接口，要按当前版本与数据底座逐项核验。
FAQ
RBAC 和 ABAC 怎么选
先用角色描述稳定的职责边界，再用属性收窄动态范围。组织、区域、客户归属经常变化，适合用属性表达式；岗位职责相对稳定，适合用角色。两者组合通常比单独使用更容易维护。
Agent 要不要继承用户的全部权限
不要。更稳妥的做法是取用户权限、Agent 自身权限和任务范围的交集，再按需临时扩大。任务结束就收回，长期保留高权限会扩大凭证泄露后的影响。
Agent 操作算谁的责任
要同时记录发起人、Agent 身份、委托关系和审批人。责任归属按企业制度确定，日志必须能还原这四类信息，否则事后无法追责。Agent 的业务负责人、版本和所属租户也要能查到。
审计日志要保留多久
由适用法律、行业监管、合同和内部追责要求共同决定。高风险场景通常需要更长保存期，同时遵守数据最小必要原则。日志中的手机号、身份证号、密钥和原始对话内容要脱敏或截断。
小团队怎么起步
先把 Agent 台账、高风险动作清单和账号清理做完。给每个 Agent 独立身份，收掉共享账号和长期管理员权限，再补行列权限、导出审批和审计。不要一开始就追求覆盖所有数据域。
自然语言问数会不会绕过行级权限
只要权限由服务端策略引擎在查询生成前强制注入，换问法不会改变范围。需要重点测试跨区域组合、聚合反推、明细下钻和接口直连，这几类路径最容易暴露配置缺口。
参考资料
- NIST SP 800-162, Guide to Attribute Based Access Control Definition and Considerations. https://csrc.nist.gov/pubs/sp/800/162/upd2/final
- OWASP, LLM06:2025 Excessive Agency. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- OWASP, Top 10 for Agentic Applications 2026. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
