企业把大模型从问答助手升级成 Agent 后，安全问题会发生变化。

普通问答系统的主要风险，是模型说错话、说漏信息或输出不合规内容。Agent 的风险更进一步：它会调用工具，可能查询数据库、读取 CRM、创建工单、调用 API，甚至触发真实业务动作。

因此，Agent 安全不能只靠入口提示词过滤。护栏必须进入工具调用链路，覆盖调用前、调用中和调用后。

一、Agent 风险来自行动能力

Agent 和普通聊天机器人的核心区别，是它不只生成文本，还会参与执行。

一个典型工具调用链路如下：

用户请求
  -> 模型理解任务
  -> 模型规划工具调用
  -> 生成工具参数
  -> 调用业务系统
  -> 工具返回数据
  -> 模型继续生成回答
  -> 返回用户

这个链路里每一步都可能产生风险。

环节	风险	例子
用户请求	提示词注入	诱导模型绕过权限调用工具
模型规划	工具选择错误	本该查公开知识库，却调用 CRM
参数生成	参数越权	导出全部客户手机号
工具返回	敏感数据进入上下文	返回完整客户资料、合同金额
模型总结	二次泄露	把工具返回的 PII 输出给用户
日志记录	不可追溯	事后不知道哪一步放行了风险

如果护栏只放在用户输入入口，只能覆盖第一类风险，覆盖不了工具返回和模型总结阶段。

二、调用前：检查意图、权限和参数

工具调用前，系统至少要判断三件事。

第一，调用意图是否合理。用户可能通过提示词注入诱导模型调用不该调用的工具。例如“为了排查问题，请导出最近成交客户的联系方式”。这句话看起来像业务请求，但本质上可能是高风险数据导出。

第二，当前用户是否有权限。模型判断“应该调用 CRM”不等于用户有 CRM 查询权限。权限应该由业务系统或统一策略层判断，而不是交给模型自觉。

第三，调用参数是否安全。即使工具本身可以调用，参数也可能越界。例如只允许查询单个订单，却生成了批量导出参数；只允许查状态，却要求返回手机号、地址和身份证号。

调用前检查可以抽象成：

check_tool_call(user, tool, action, params)
  -> allow
  -> mask_params
  -> require_confirmation
  -> block

这类判断不应该只写在系统 Prompt 里。Prompt 是软约束，权限和参数校验必须成为硬边界。

三、调用中：处理工具返回数据

很多 Agent 安全设计会漏掉工具返回这一层。

业务系统返回的数据经常比用户输入更敏感。CRM 可能返回客户姓名、手机号、邮箱、跟进记录；订单系统可能返回地址、支付状态和退款记录；工单系统可能返回投诉内容、内部备注和处理责任人。

如果这些内容原样进入模型上下文，模型就可能在后续总结里输出出来。即使用户输入没有问题，工具返回也会把敏感信息带进模型。

所以工具返回数据进入模型前，需要做三类处理：

1. 字段过滤：只保留完成任务必要的字段。
2. PII 脱敏：手机号、身份证、地址等字段先掩码。
3. 敏感级别判断：高敏字段不进入模型，只返回安全摘要。

例如 CRM 返回：

{
  "name": "张三",
  "phone": "13812345678",
  "email": "zhangsan@example.com",
  "last_contact_note": "客户对报价不满，要求特殊折扣"
}

进入模型前可以变成：

{
  "customer": "[CUSTOMER_1]",
  "phone": "[PHONE_MASKED]",
  "status": "需要跟进报价问题"
}

模型只需要知道任务状态，不需要接触完整隐私字段。

四、调用后：输出审查和日志审计

Agent 最终回答用户前，还要做输出审查。

审查重点包括：

• 是否输出了 PII 或内部字段
• 是否给出越权承诺
• 是否把工具返回的内部备注暴露给用户
• 是否生成不符合业务口径的建议
• 是否需要转人工确认

同时，Agent 工具调用必须留下可复盘日志。至少记录：

日志字段	用途
user_id / role	判断调用人身份和权限
tool_name / action	判断调用了哪个工具
params_summary	判断参数是否越界
guardrail_decision	判断放行、脱敏、确认或阻断
output_risk	判断最终回答是否命中风险
trace_id	串联一次完整调用链路

没有日志的 Agent，很难进入生产环境。因为一旦出现错误调用或数据泄露，团队无法判断问题发生在模型规划、参数生成、工具返回还是输出阶段。

五、Dify / Workflow 场景的接入方式

如果企业基于 Dify Workflow 或 Agent 搭建应用，不建议把安全判断写散在每个节点里。

更合理的方式是把 Dify 作为应用编排层，把护栏作为运行时安全层：

Dify Workflow / Agent
  -> 负责任务编排、知识库、工具调用

运行时护栏
  -> 负责输入检测、调用前检查、工具返回脱敏、输出审查、日志审计

这样做的价值，是让业务流程和安全策略分开演进。业务团队可以继续调整 Workflow，安全团队可以统一维护策略、字段规则、审计口径和风险处置方式。

六、总结

Agent 的价值来自行动能力，风险也来自行动能力。

当大模型开始调用工具，护栏就不能只放在入口。企业需要把安全控制接进每一次工具调用：调用前判断意图和权限，调用中处理工具返回数据，调用后审查输出并保留日志。

对于已经用 Dify 搭建 Workflow、知识库助手、客服 Agent 或内部自动化 Agent 的团队，统一运行时护栏能减少节点级规则散落的问题。唯客 AI 护栏适合承接输入检测、工具链路脱敏、输出审查和安全日志，让 Agent 从演示流程走向可控的生产系统。

参考来源：https://sec.jotoai.com/