第 2.13.2 节：把 RBAC、ABAC 和 RAG 权限统一到访问控制模型
RBAC、ABAC 与 RAG 权限不仅要能运行，还要明确权限边界、审批条件和审计记录。完成本节后，你应该能够设计 RBAC、ABAC 与 RAG 权限的角色权限、审批条件、审计记录和越权处理。
核心概念
Authentication（认证）
人话解释：认证是确认“你是谁”。例如用户登录、客服登录、管理员登录、API Key（接口密钥）识别服务身份。
项目位置：客服工作台里，认证发生在用户进入系统、客服打开后台、Agent（智能体）调用内部工具之前。
工程动作：设计 user_id（用户编号）、role（角色）、tenant_id（租户编号）、session_id（会话编号）、auth_context（认证上下文）。不要让模型自己判断用户身份。
面试说法：我会把身份认证放在应用层和网关层，模型只能接收经过脱敏和授权后的上下文，不能直接决定“这个人是谁”。
Authorization（授权）与 Permission（权限）
人话解释：认证确认你是谁，授权决定你能做什么。权限是授权结果的具体表达。
项目位置：同一个客服工作台里，普通用户只能看自己的订单，客服能看负责范围内的工单，主管能看团队统计，管理员能配置工具和知识库。
工程动作：按资料、工具、字段和动作分别授权。资料权限控制“能不能检索到”；工具权限控制“能不能调用”；字段权限控制“能不能看到手机号、地址、金额”；动作权限控制“能不能创建、修改、发送、退款”。
面试说法：我不会只做页面按钮权限，而是把权限落到检索过滤、工具网关、字段脱敏和审计日志里。
RBAC（基于角色的访问控制）与 ABAC（基于属性的访问控制）
人话解释：RBAC（基于角色的访问控制）按角色授权，ABAC（基于属性的访问控制）按用户、部门、租户、地区、订单归属、资料等级等属性做更细判断。
项目位置：客服工作台可以用 RBAC（基于角色的访问控制）定义用户、客服、主管、管理员；再用 ABAC（基于属性的访问控制）判断某个客服是否能看某个租户、某个订单或某个资料。
工程动作：设计角色表、权限表、资料标签、工具风险等级和策略规则。RAG（检索增强生成）查询时必须带上权限过滤条件。
面试说法：我会用 RBAC（基于角色的访问控制）做基础角色，用 ABAC（基于属性的访问控制）处理多租户、部门和业务对象归属，避免只靠粗粒度角色导致越权。
Guardrail（护栏）
人话解释：Guardrail（护栏） 是系统在输入、处理、工具、输出和审批节点上的安全检查机制。
项目位置：客服工作台里，护栏可以检查用户输入是否恶意、检索结果是否有权限、工具参数是否合规、模型输出是否泄露隐私、高风险动作是否需要人工审批。
工程动作：护栏不是一个单点。要把它拆成 input guardrail（输入护栏）、retrieval guardrail（检索护栏）、tool guardrail（工具护栏）、output guardrail（输出护栏）、approval guardrail（审批护栏）和 runtime guardrail（运行时护栏）。
面试说法：我理解的 Guardrail（护栏）不是一句安全 Prompt（提示词），而是一组自动校验、人工审批、权限控制和审计机制。
Prompt（提示词） Injection（提示注入）
人话解释：Prompt Injection（提示注入）是用户或外部资料中藏有恶意指令，试图让模型忽略系统规则、泄露资料、调用工具或输出不该输出的内容。
项目位置：客服 Agent 可能从用户输入、网页、PDF（便携式文档格式）、工单历史、邮件内容和工具返回结果中读到恶意指令。
工程动作：不要假设模型能永远分清“指令”和“资料”。要降低被攻击后的影响：限制工具权限、隔离资料、禁止高风险自动执行、记录异常、转人工。
面试说法：我不会把 Prompt Injection（提示注入）当成普通关键词过滤问题。我的策略是降低模型被诱导后的权限和影响范围，而不是相信一次过滤能彻底解决。
Human-in-the-loop（人工参与闭环）
人话解释：人工参与闭环是让人类在高风险节点做确认、审批或复核。
项目位置：退款、发券、发送外部通知、批量更新资料、删除工单、改合同条款，都不应该由 Agent 自动完成。
工程动作：设计审批请求、审批状态、审批人、审批理由、过期时间、执行结果和审计记录。审批前后都要重新校验权限和参数，防止审批绕过。
面试说法：我会按风险分级决定是否需要人工审批。审批不是降低智能化，而是让系统能进入企业生产环境。
本章在客服工作台中的位置
本章可以理解为客服 Agent 工作台的安全控制面。
| 工作台层级 | 本章负责什么 | 典型控制点 |
|---|---|---|
| 用户入口层 | 认证、限流、输入安全 | 登录、租户、用户身份、恶意输入、频率限制。 |
| 会话状态层 | 状态边界、敏感字段隔离 | session（会话）状态、订单归属、缺失字段、风险等级。 |
| 知识检索层 | 资料权限、引用安全 | tenant_id（租户编号）、permission_tags（权限标签）、source_id（来源编号）、版本。 |
| 工具调用层 | 工具白名单、权限、幂等 | 查订单、建工单、发短信、退款审批。 |
| 模型输出层 | 脱敏、拒答、转人工 | 不输出完整手机号、地址、内部策略和无依据结论。 |
| 审批审计层 | 高风险动作复核 | 审批记录、安全事件、Trace ID（追踪编号）、复盘。 |
如果把第 1.6 章 Tool Calling（工具调用）理解为“让 Agent 能办事”，本章就是“让 Agent 只在允许范围内办事”。
系统流程图
这张图里最重要的是：安全检查不是只在开头或结尾做一次，而是在输入、检索、工具、审批和输出多个节点重复出现。
读图重点：先读上组：认证、输入护栏和权限上下文决定能检索什么，候选片段还要二次复核；再读下组：工具请求经过网关与审批，回答草稿经过输出护栏，任何不可返回路径都拒绝或转人工并记安全日志。
风险分级
安全设计要先分级。没有分级，系统就会在两个极端之间摇摆：要么什么都不敢自动化，要么什么都交给 Agent。
| 风险等级 | 典型动作 | 自动化策略 | 验收重点 |
|---|---|---|---|
| L0 信息整理 | 总结公开 FAQ（常见问题）、解释公开政策 | 可以自动执行 | 引用来源准确。 |
| L1 只读查询 | 查知识库、查公开产品信息 | 自动执行，但要有权限过滤 | 不越权、不泄露。 |
| L2 敏感只读 | 查订单、查客户资料、查内部工单 | 需要身份和对象归属校验 | 只返回必要字段。 |
| L3 低风险写入 | 创建普通工单、提交反馈 | 用户确认后执行 | 幂等、防重复、可撤回。 |
| L4 外部副作用 | 发短信、发邮件、发优惠券 | 人工审批或强规则审批 | 防滥用、防误发、记录审批。 |
| L5 高风险动作 | 退款、改合同、删除数据、批量发布 | 必须人工审批和复核 | 双人复核、审计、回滚方案。 |
面试时，不要把风险说成“安全等级高低”这种空话。要能说明：风险等级决定工具能不能自动执行、需不需要审批、需要记录哪些日志、失败后怎么兜底。
模块拆分
安全章节可以拆成 9 个模块。
| 模块 | 职责 | 输入 | 输出 |
|---|---|---|---|
| Identity Context（上下文） | 提供用户、租户、角色、部门和会话信息 | 登录态、服务凭证 | auth_context（认证上下文）。 |
| Permission Policy（权限策略） | 判断资料、工具和动作是否允许 | 用户属性、资源属性、动作类型 | allow（允许）、deny（拒绝）、review（需审批）。 |
| Retrieval Filter（检索过滤） | 给 RAG 查询加权限条件 | 查询、租户、资料标签 | 可访问的候选资料。 |
| Tool（工具） Gateway（网关） | 统一校验工具调用 | tool_name（工具名称）、参数、风险等级 | 工具执行或拒绝原因。 |
| Guardrail（护栏） Engine（护栏引擎） | 检查输入、输出、工具和审批 | 请求内容、模型输出、工具结果 | 安全决策。 |
| Approval Center（审批中心） | 管理人工审批 | 高风险动作请求 | 审批结果和执行许可。 |
| Redaction Service（服务层） | 隐藏敏感字段 | 客户资料、订单资料、日志内容 | 脱敏后的可展示内容。 |
| Audit Logger（审计日志器） | 记录安全决策和工具动作 | Trace ID（追踪编号）、决策、执行结果 | 可检索审计记录。 |
| Incident Monitor（安全事件监控） | 发现异常和告警 | 安全日志、失败率、越权尝试 | 告警、封禁、复盘任务。 |
这些模块不一定都要做成独立服务。作品集或中小项目可以先在一个后端项目里实现模块边界，关键是职责要清楚。