跳到主要内容

第 2.13.1 节：把身份认证和操作授权拆成可审计流程

身份认证和操作授权只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够设计身份认证和操作授权的角色权限、审批条件、审计记录和越权处理。

本章要解决什么问题​

前面章节已经把企业客服知识库与工单 Agent（智能体） 工作台的核心能力串起来了：用户提问进入会话，系统用 RAG（检索增强生成） 查资料，用 Tool Calling（工具调用） 查订单和建工单，用 MCP（模型上下文协议） 统一工具接入，用 LangGraph（智能体状态图框架） 管理多步骤流程，并通过 Trace ID（追踪编号）、成本日志和错误记录实现可观测性。

做到这里，系统已经不只是聊天了。它开始接触客户隐私、订单状态、售后政策、工单处理、优惠券、退款审批、短信通知、邮件发送和人工客服协作。

这也意味着一个新问题出现了：Agent 越能办事，越可能把模型错误变成真实业务事故。

安全、权限、Guardrail（护栏） 与人工审批要解决的不是“让模型少说错话”这么简单，而是回答 6 个工程问题：

  • 用户能不能看这份资料？
  • Agent 能不能调用这个工具？
  • 模型输出能不能直接返回给用户？
  • 写入、发送、退款、删除、发布这类动作能不能自动执行？
  • 如果发生 Prompt（提示词） Injection（提示注入）、越权访问或工具误调用，系统如何把损失限制住？
  • 出事以后能不能用日志复盘清楚：谁在什么时候触发了什么动作，系统为什么允许或拒绝？

本章的目标，是让读者从“我知道安全很重要”提升到“我能给 Agent 项目设计一套可面试、可交付、可验收的安全控制面”。

学习目标​

读完本章后，你应该能够：

  • 说清 Agent 项目的主要风险类型：数据风险、动作风险、隐私风险、合规风险、成本风险和提示注入风险。
  • 区分 Authentication（认证）、Authorization（授权）、Permission（权限）、Guardrail（护栏）和 Approval（审批）。
  • 为客服工作台设计资料权限、工具权限、字段脱敏、审批流和审计日志。
  • 解释为什么安全不能只靠 Prompt 约束。
  • 为只读工具、低风险写入、中风险写入和高风险动作设计不同的执行策略。
  • 写出安全事件、安全决策和审批请求的字段契约。
  • 面试时把安全能力讲成“企业 Agent 落地能力”，而不是只背安全名词。

贯穿业务场景​

本章继续使用“企业客服知识库与工单 Agent 工作台”。

假设客户是一家电商或 SaaS（软件即服务）企业，客服 Agent 要处理这些问题：

  • 用户问售后政策，系统需要检索知识库。
  • 用户问订单发货状态，系统需要调用订单查询工具。
  • 用户要求改收货地址，系统需要校验身份并创建人工工单。
  • 用户要求退款，系统需要判断金额、订单状态、责任归属和审批策略。
  • 客服主管查看对话复盘，系统需要展示日志和引用来源。
  • 运营人员要求批量发送补偿短信，系统需要进入高风险审批。

这些任务看起来都在客服范围内，但风险等级完全不同。

任务表面动作真实风险
查询售后政策检索资料可能检索到过期资料或无权限资料。
查询订单状态读取业务系统涉及个人信息和订单归属校验。
创建工单写入系统可能重复建单或写错责任部门。
发优惠券外部副作用涉及成本、滥用和审批。
触发退款金钱动作必须人工审批和审计。
发送短信或邮件外部联系可能造成骚扰、泄密或品牌风险。

安全章节不是单独的“安全插件”。它横跨资料、检索、工具、状态、前端、部署、日志和商业交付。

新手为什么会卡住​

很多新手做 Agent 项目时，会把安全理解得太窄。

常见误解为什么危险正确理解
在 Prompt 里写“不要泄露隐私”就够了模型可能被用户输入、检索资料或工具结果影响Prompt 只能表达意图，不能替代权限、校验、审批和审计。
内部系统没人攻击，不用管权限真实事故常来自误操作、越权配置和内部资料混乱企业项目默认要按角色、部门、租户和业务对象控制访问。
工具只要能调通就行工具会改变真实业务状态工具必须按风险分级，写入和外部副作用需要幂等、确认、审批和日志。
安全会拖慢开发不做安全会让项目无法上线安全边界越早设计，后续重构越少。
Guardrail（护栏）就是内容审核只检查输出太晚了护栏要覆盖输入、检索、工具、输出、审批和运行时监控。
拒答会影响体验不拒答会造成越权和误导好的系统会解释原因、给替代路径，并在必要时转人工。

面试时，候选人如果只说“我会加敏感词过滤”，会显得很浅。企业更关心的是：你能不能把 Agent 的能力限制在被授权、可追踪、可回滚、可审批的范围内。

继续学习​