4. 权限控制基础
在金融智能体的安全体系中，权限控制是继输入输出护栏之后的第二道核心防线。护栏解决的是“模型能说什么、能做什么”的边界问题，而权限控制解决的是“谁在什么条件下可以触发哪些操作、访问哪些数据”的身份与授权问题。对于金融场景而言，一次越权查询客户资产、一次未授权的转账指令调用，都可能造成直接的资金损失与合规风险。因此，理解身份认证、授权模型、访问控制列表（ACL）与基于角色的访问控制（RBAC）的差异与组合方式，是构建智能体安全底座的基本功。
一、核心原理：认证与授权是两件事
很多初学者会把“登录成功”等同于“拥有权限”，这是最常见的认知偏差。身份认证（Authentication）回答的是“你是谁”，授权（Authorization）回答的是“你能做什么”。认证发生在授权之前，认证失败则授权无从谈起；但认证成功并不意味着拥有全部权限。
在金融智能体架构中，认证对象通常包括三类：终端用户、智能体服务本身、以及智能体调用的下游工具或数据源。用户认证可采用OAuth 2.0、OIDC、mTLS或企业SSO；智能体服务认证常用、JWT或服务网格中的SPIFFE身份；下游工具认证则依赖各系统自身的凭证体系。授权则发生在每一次工具调用、数据读取和动作执行之前，由策略引擎实时判定。
关键原则：认证是“一次性”或“会话级”的，授权是“每次请求级”的。智能体在代表用户执行操作时，必须携带用户身份上下文，而不是仅以服务身份运行，否则所有用户的操作都会退化为同一个超级权限主体。
二、授权模型演进：从ACL到RBAC再到ABAC
访问控制列表（ACL）是最直观的授权模型：每个资源维护一张列表，记录哪些主体可以执行哪些操作。例如某客户数据表允许用户A读取、用户B读写。ACL的优点是粒度细、语义直接；缺点是当主体和资源数量增长时，列表会急剧膨胀，管理成本高，且难以表达“所有风控人员都可以查看风险报告”这类批量规则。
基于角色的访问控制（RBAC）引入了“角色”这一中间层。权限不再直接授予用户，而是授予角色，用户通过被分配角色获得权限。RBAC的核心优势在于解耦：人员变动时只需调整角色分配，权限策略保持稳定。金融智能体常见的角色包括：普通客户、理财顾问、风控专员、合规审计员、系统管理员。每个角色对应一组工具调用权限和数据访问范围。
更进一步的ABAC（基于属性的访问控制）则结合用户属性、资源属性、环境属性和动作属性进行动态判定，例如“仅允许在工作时间、从内网IP、对本人名下账户执行转账”。在智能体场景中，RBAC通常作为基础骨架，ABAC作为动态补充，二者结合形成“静态角色+动态策略”的混合模型。
三、方法流程：智能体权限校验的落地步骤
在金融智能体工程中，权限控制不是单点功能，而是一条贯穿请求生命周期的校验链。典型流程如下：
- 身份注入：用户请求进入网关时，完成认证并生成包含用户ID、角色、部门、会话有效期的JWT。
- 上下文传递：智能体编排层将用户身份上下文注入到每一次工具调用请求中，禁止使用服务账号“顶替”用户身份。
- 策略判定：策略引擎（如OPA、Casbin或自研规则引擎）根据角色、资源、动作和环境属性返回allow/deny。
- 最小权限执行：工具层仅暴露当前请求所需的最小数据字段与操作范围，避免“先取全量再过滤”。
- 审计留痕：每次授权决策记录主体、资源、动作、结果与策略版本，供合规审计与事后追溯。
实践建议：在智能体工具定义中，为每个工具显式声明所需权限标识，例如 tool:query_account_balance、tool:transfer_funds。策略引擎只需匹配权限标识，而不必理解工具内部实现，从而降低耦合。
四、案例与场景：一次越权查询的复盘
某金融智能体上线初期，理财顾问可通过自然语言查询客户持仓。开发团队为图方便，让智能体服务以统一服务账号访问客户数据接口，仅在应用层根据用户输入过滤客户ID。上线后不久，一名顾问通过构造“帮我查一下客户编号10086的持仓”成功越权访问了非本人负责的客户数据。
复盘发现三个问题：其一，认证与授权脱节，服务账号拥有全量数据权限；其二，ACL式过滤发生在应用层而非策略层，可被提示词绕过；其三，缺少工具级权限声明，智能体无法判断“查询持仓”这一动作对当前用户是否合法。
修复方案采用RBAC+ABAC混合模型：为顾问角色分配query_portfolio权限，但ABAC策略限定resource.customer_id in user.assigned_customers且environment.channel == "internal"。同时将客户ID过滤下沉到数据访问层，智能体不再接触未授权数据。修复后，同类越权尝试在策略层即被拒绝并触发告警。
| 模型 | 核心思想 | 适用场景 | 金融智能体中的典型用法 |
|---|---|---|---|
| ACL | 资源直接绑定主体与操作 | 资源少、主体少、关系稳定 | 少量敏感报表的例外授权 |
| RBAC | 用户→角色→权限 | 组织化、规模化权限管理 | 顾问、风控、审计、管理员角色划分 |
| ABAC | 多属性动态策略判定 | 合规严格、上下文敏感 | 工作时间、内网、本人客户、金额阈值 |
五、常见误区与复盘要点
- 误区一：认证即授权。登录成功不代表可以调用所有工具，必须在每次动作前独立判定。
- 误区二：服务账号万能。智能体以服务身份运行会丢失用户上下文，导致权限放大。
- 误区三：只在应用层过滤。应用层过滤可被提示词注入绕过，策略层与数据层必须双重设防。
- 误区四：角色粒度越细越好。角色爆炸会带来管理负担，应优先用ABAC表达动态条件，而非无限拆分角色。
- 误区五：忽略审计。没有授权日志，越权事件无法定位，合规检查也无法通过。
安全底线：任何涉及资金变动、客户隐私数据导出、批量查询的操作，都必须经过独立的授权判定，且默认拒绝（deny by default）。智能体的“智能”不能成为绕过权限控制的理由。
掌握认证与授权的分层关系、ACL与RBAC的适用边界，以及RBAC与ABAC的混合策略设计，是后续实现智能体工具级权限网关、动态策略引擎和审计体系的前提。在金融场景中，权限控制的严谨程度直接决定了智能体能否真正进入生产环境。