文章总结： 本文提出AI应用安全治理框架，强调需重新划定数据、权限、工具调用和运行责任边界。核心包括建立六类对象清单、七段信任链、四层风险控制及用例分级。建议通过统一工具代理、跨层防护提示注入、保留六段运行证据，并在90天内建立治理最小闭环。关键是将不确定输出限制在可接受的业务边界内，由代码和策略决定权限。 综合评分： 90 文章分类： AI安全,安全治理,数据安全,应用安全,安全运营

AI 应用安全治理：模型、数据、插件和智能体风险

原创

咸鱼翻身日记 咸鱼翻身日记

企业安全指南

2026年8月24日 20:59 浙江

在小说阅读器读本章

去阅读

不是给大模型加一层过滤，而是重新划定数据、权限、工具调用和运行责任边界

上一篇《身份治理成熟度评估：从人工台账到策略自动化》把身份治理从单项控制提升为可评估、可验证、可持续改进的能力。用成熟度阶梯、关键红线和证据评估收束了身份治理专题；这一篇进入 AI 应用安全，继续沿用对象清单、责任边界、分级控制和运行证据的方法治理新的模型与智能体风险。

进入 AI 应用之后，同一套治理思想仍然成立，但对象和边界都变了。传统应用通常由代码明确决定流程；AI 应用却把用户输入、系统指令、检索资料、模型输出和工具返回放进同一条上下文链。模型还能生成参数、选择工具、连续执行任务。只要其中一段被污染，错误就可能从一句文本扩散成数据泄露、越权调用或真实业务动作。

这一篇围绕 AI 用例分级、模型与供应链、企业数据与 RAG、提示词与上下文、插件工具调用、智能体自主动作、上线评测、运行监控和责任边界，帮助企业建立可执行的 AI 应用安全治理框架。重点不是阻止所有 AI 使用，而是明确哪些场景可以用、哪些数据可以进、模型能看到什么、工具可以做什么、关键动作由谁批准，以及失败后能否还原完整证据。

一、AI 应用安全不是传统应用安全换一个名字

| 变化 | 传统应用 | AI 应用新增的问题 | | — | — | — | | 执行逻辑 | 代码和规则预先确定 | 模型根据自然语言和上下文生成结果或动作计划 | | 输入边界 | 字段、协议和接口相对明确 | 用户、网页、文档、邮件、图片和工具结果都可能携带指令 | | 数据使用 | 数据进入固定处理流程 | 提示词、检索片段、记忆和输出可能跨会话、跨租户流动 | | 外部能力 | API 调用由代码显式编排 | 模型可能选择插件、拼接参数并决定调用顺序 | | 结果验证 | 返回值通常有稳定结构 | 输出可能不准确、不完整，也可能包含可执行内容 | | 责任判断 | 故障点通常落在服务和代码 | 模型提供商、应用方、数据 Owner、工具 Owner 和用户共同参与 |

AI 安全不能只在模型前后各加一个敏感词过滤器。NIST AI RMF 使用 Govern、Map、Measure、Manage 组织风险管理，强调治理贯穿整个生命周期；OWASP 的生成式 AI 风险则提醒企业关注提示注入、敏感信息泄露、供应链、输出处理和过度代理等应用层问题。两者结合后，治理重点应落到具体用例、资产、信任边界、评测证据和运行决策。

二、先建六类对象清单，再谈控制

| 治理对象 | 必须记录什么 | 责任人 | | — | — | — | | AI 用例 | 业务目标、使用人群、输入输出、影响对象、禁止用途 | 业务 Owner | | 模型与服务 | 模型版本、提供商、部署方式、数据条款、能力与限制 | AI 平台 Owner | | 数据与知识库 | 数据等级、来源、授权范围、更新频率、保留与删除 | 数据 Owner | | 指令与上下文 | 系统提示词、模板、会话记忆、检索策略和版本 | 应用 Owner | | 插件与工具 | API、权限、参数、网络出口、写操作和回滚能力 | 工具 Owner | | 智能体任务 | 可自主完成的步骤、最大权限、预算、停止条件和审批点 | 业务与风险 Owner |

没有这六类清单，安全团队只能看到模型名称，却不知道它连接了哪些数据和系统。真正的风险往往不在模型本身，而在“某个用例把某类数据交给某个模型，再允许它调用某个工具”这一组合关系。

三、画出七段信任链，风险才不会漏在连接处

| 链路 | 关键问题 | 最低控制 | | — | — | — | | 用户与入口 | 谁在使用，是否允许匿名或外部访问 | 身份认证、租户隔离、用例授权和速率限制 | | 输入与文件 | 输入是否含敏感数据或隐藏指令 | 数据识别、文件解析隔离、大小类型限制和恶意内容检查 | | 编排与提示词 | 系统指令是否可被覆盖或泄露 | 指令与数据分离、模板版本、上下文预算和策略校验 | | 模型服务 | 请求发往哪里，是否留存或用于训练 | 模型白名单、区域与条款确认、密钥隔离和调用审计 | | 检索与记忆 | 检索是否越权，记忆是否跨用户污染 | 文档级 ACL、租户过滤、来源标记、过期删除和写入审核 | | 插件与工具 | 模型能否执行高风险动作 | 工具代理、最小权限、参数校验、网络出口和人工批准 | | 输出与下游 | 输出是否直接进入代码、邮件或业务系统 | 结构校验、内容检查、引用提示、沙箱和下游编码 |

每一段都要记录输入、策略、决策、调用和结果。只保留聊天记录不够，因为一次智能体任务可能包含多轮模型推理、数次检索和多个工具调用。

四、四层风险不能用一条规则统一解决

| 风险层 | 典型问题 | 主要控制 | | — | — | — | | 模型层 | 模型来源不明、版本漂移、能力误判、模型窃取、输出不稳定 | 供应商评估、模型清单、版本锁定、基准评测、访问与速率控制 | | 数据层 | 敏感输入、训练或日志留存、RAG 越权、知识污染、向量泄露 | 分类分级、最小数据、脱敏、文档 ACL、来源可信和保留策略 | | 工具层 | 插件过权、参数未校验、输出直接执行、网络出口过宽 | 工具代理、独立身份、参数白名单、读写分离、沙箱和回滚 | | 智能体层 | 目标模糊、过度代理、连续错误、记忆污染、绕过人工批准 | 任务边界、步骤与预算上限、关键动作审批、停止条件和全链审计 |

提示注入横跨四层：恶意内容先进入数据或上下文，影响模型判断，再诱导工具调用，最终由智能体把错误变成动作。因此防护也必须跨层，不能期待模型自己识别所有恶意指令。

五、先按业务影响把用例分成四级

| 级别 | 场景 | 默认边界 | 上线要求 | | — | — | — | — | | A1 辅助生成 | 文案草稿、总结、翻译、公开知识问答 | 不接敏感数据，不自动执行外部动作 | 模型白名单、内容提示、基础日志 | | A2 企业知识 | 内部知识问答、制度检索、研发助手 | 允许受控内部数据，只读检索 | 身份授权、文档 ACL、来源引用、越权评测 | | A3 业务决策 | 客服建议、风控辅助、合同分析、运维诊断 | 输出影响客户、资金、合规或生产判断 | 领域评测、人工复核、版本管理、结果留证 | | A4 智能体执行 | 发邮件、改配置、下订单、建工单、操作生产系统 | 可调用工具并改变真实状态 | 独立身份、最小权限、动作矩阵、审批、回滚和持续监控 |

分级依据不是用了哪个模型，而是错误会影响谁、能接触什么数据、能调用什么工具、是否会改变真实世界状态。同一模型用于公开文案和生产变更，安全要求完全不同。

六、提示注入要按“不可信数据影响控制流”处理

| 常见误区 | 风险 | 正确做法 | | — | — | — | | 只靠一段系统提示词 | 指令可能被直接或间接输入干扰 | 把安全边界放在模型之外，由代码和策略执行 | | 认为内部文档可信 | 被污染的网页、邮件和知识文档可携带隐藏指令 | 所有检索内容按不可信数据处理，保留来源和信任等级 | | 过滤危险词就够了 | 攻击可改写、拆分、编码或藏在多模态内容中 | 组合输入检查、权限隔离、动作确认和结果验证 | | 模型拒绝等于安全 | 多轮诱导和上下文变化可能改变结果 | 用可重复攻击集和自动化回归测试验证 |

核心原则是：自然语言可以提出意图，但不能直接成为高权限控制指令。 模型生成的工具名、参数和目标对象必须经过独立策略校验。

七、数据进入 AI 前要回答六个问题

| 问题 | 管理要求 | | — | — | | 这是什么数据 | 标注公开、内部、敏感、核心及个人信息属性 | | 为什么需要 | 证明该用例确实需要这些字段和文档，而不是整库接入 | | 发往哪里 | 确认模型部署区域、处理方、子处理方和网络路径 | | 是否留存训练 | 明确请求、响应、日志、反馈是否保存或用于模型改进 | | 谁能检索 | 权限随用户和文档变化实时生效，不能只在建库时过滤一次 | | 何时删除 | 规定会话、向量、缓存、日志和离线评测样本的保留期限 |

知识库安全的重点不是“向量是否加密”，而是原文权限能否带到检索结果、文档撤权后索引是否同步删除、召回片段能否追溯来源，以及不同租户的内容是否真正隔离。

八、插件和工具必须经过统一执行代理

| 控制点 | 最低要求 | | — | — | | 工具注册 | 记录 Owner、用途、接口、数据范围、权限、版本和下线条件 | | 身份 | 每个智能体或用例使用可识别身份，不共享长期管理员密钥 | | 参数 | 模型只提交候选参数，由代理做类型、范围、对象和业务规则校验 | | 权限 | 读写分离，按任务签发短期权限，默认禁止通配资源和任意网络出口 | | 审批 | 删除、转账、发布、外发、生产变更等动作必须由确定的人批准 | | 结果 | 工具返回内容同样按不可信输入处理，防止二次提示注入 | | 回滚 | 写操作要有幂等、事务、补偿或人工恢复路径 |

不要把所有工具都交给一个万能智能体。优先建立少量、窄权限、参数明确、结果可验证的工具，每个工具只完成一类动作。

九、用“影响 × 可逆性”决定是否允许自动执行

| 动作类型 | 低影响或可逆 | 高影响或不可逆 | | — | — | — | | 读取 | 可自动执行，但仍需按用户权限过滤和记录来源 | 涉及敏感、跨租户或大批量导出时需要二次授权 | | 建议 | 可生成草稿、方案或候选项 | 涉及法律、医疗、财务、用工和重大生产决策必须人工确认 | | 写入 | 可创建草稿、测试工单或受限环境变更 | 生产配置、客户通知、资金与权限变更必须审批并可回滚 | | 删除或外发 | 默认不自动执行 | 原则上双人复核、明确对象范围并记录完整证据 |

人工确认不能只是点“同意”。确认页面应展示将调用的工具、目标对象、关键参数、数据范围、影响和回滚方式，否则人也无法做出有效判断。

十、上线前评测要覆盖八类真实攻击

| 测试场景 | 要验证什么 | | — | — | | 直接提示注入 | 用户能否覆盖系统目标、策略或隐藏指令 | | 间接提示注入 | 网页、文档、邮件和工具结果能否劫持任务 | | 敏感信息泄露 | 提示词、密钥、其他用户数据和受限文档是否泄露 | | 检索越权与污染 | ACL、租户隔离、文档撤权和恶意知识是否有效控制 | | 工具滥用 | 模型能否改写目标、扩展参数、绕过审批或调用未授权工具 | | 输出处理 | 输出进入浏览器、脚本、SQL、邮件和下游 API 时是否安全 | | 资源与成本滥用 | 超长上下文、循环调用、并发和昂贵工具是否有预算上限 | | 误导与过度依赖 | 错误答案、伪造引用和不确定结果是否会被直接采纳 |

评测结果要绑定模型版本、提示词版本、知识库快照、工具版本和策略版本。任何一项变化，都可能让原来的通过结论失效。

十一、运行期至少保留六段证据

| 证据 | 内容 | | — | — | | 身份与用例 | 用户、租户、业务用例、会话与授权范围 | | 模型请求 | 模型和版本、模板版本、参数、Token 与调用时间 | | 数据上下文 | 输入等级、检索文档 ID、权限判断和来源 | | 工具动作 | 工具身份、参数、审批人、目标对象与执行结果 | | 安全决策 | 允许、脱敏、降级、阻断或转人工的策略与原因 | | 结果反馈 | 用户确认、错误纠正、事件、成本与规则改进 |

日志本身也可能包含提示词、个人信息和业务秘密，必须控制访问、脱敏、保留期限和导出。为了审计而无限保存全部上下文，同样会制造新的数据风险。

十二、90 天先建立治理最小闭环

| 时间 | 建设重点 | 完成标准 | | — | — | — | | 0—30 天 | 盘点 AI 用例、模型、数据、知识库、工具和 Owner | 高风险用例可见，未经批准的外部模型与敏感数据路径被收口 | | 31—60 天 | 建立用例分级、模型白名单、数据规则和工具动作矩阵 | A2 以上用例有评审，A4 动作有审批、短期权限和回滚 | | 61—90 天 | 上线提示注入、越权、泄露、工具滥用和成本测试 | 关键版本有评测基线，失败项有 Owner、期限和复测证据 | | 持续运营 | 接入网关日志、模型调用、检索、工具、审批和事件 | 能按用例还原链路，指标驱动规则、权限和评测集更新 |

十三、十项验收清单

| 验收项 | 是否通过 | | — | — | | AI 用例、模型、数据、知识库、工具和智能体都有清单与 Owner | □ | | 用例按业务影响、数据敏感度、工具权限和自主程度完成分级 | □ | | 模型提供商、部署区域、留存训练条款和版本变更已确认 | □ | | RAG 检索继承文档权限，租户隔离与撤权同步经过测试 | □ | | 系统指令、不可信数据和工具参数之间存在技术隔离 | □ | | 工具使用独立身份、最小权限、参数白名单和受控网络出口 | □ | | 高影响或不可逆动作有有效人工批准和回滚路径 | □ | | 八类安全评测绑定模型、提示词、知识库、工具和策略版本 | □ | | 日志能还原身份、数据、模型、安全决策、工具动作和结果 | □ | | 事件、误报、成本和用户反馈能够进入规则与评测集改进 | □ |

十四、管理者最后问五个问题

1. 当前最高风险的 AI 用例，能读取哪些数据、调用哪些工具、改变什么真实状态？
2. 如果知识文档或网页里藏有恶意指令，模型之外还有哪一层会阻止危险动作？
3. 模型、提示词、知识库或插件版本变化后，谁决定必须重新评测？
4. 一次智能体误操作发生后，能否还原用户、上下文、策略、审批和工具调用？
5. 哪些风险由模型提供商承担，哪些必须由企业应用方和业务 Owner 承担？

AI 应用安全的核心，不是要求模型永远正确，而是把不确定输出限制在可接受的业务边界内。模型可以生成建议，代码和策略决定权限；智能体可以规划步骤，关键动作由明确责任人批准；系统可以快速迭代，但每次变化都必须带着评测、证据和回退能力进入生产。

十五、下一篇预告

本篇先建立 AI 应用安全的对象、分级和责任边界。下一篇进入实操：AI 应用安全落地实战：网关、权限、评测和运行监控，重点讲如何用统一 AI 网关、RAG 权限、工具代理、自动化评测、运行监控和事件响应把这些控制真正接进研发与生产流程。

参考来源

1. NIST AI Risk Management Framework
2. NIST AI 600-1 Generative AI Profile
3. OWASP Top 10 for LLM Applications 2025
4. MITRE ATLAS
5. Google Secure AI Framework
6. 生成式人工智能服务管理暂行办法

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：企业安全指南 咸鱼翻身日记 咸鱼翻身日记《AI 应用安全治理：模型、数据、插件和智能体风险》