AI 进入生产系统之后：安全运营要补的三块短板

大模型刚进入企业时，安全讨论主要集中在内容层面：会不会说错话、会不会泄露商业秘密、输出是否合规。随着智能体开始调用企业系统、执行任务，问题变得更具体：它能不能被诱导去做不该做的事？它手里的权限是不是太大了？它做过的事能不能被追溯？

国务院《关于深入实施“人工智能+”行动的意见》把安全能力列为八大基础支撑之一，提出要完善人工智能安全治理。这不是一句原则性要求。当 AI 从“问答工具”变成“生产系统的参与者”，安全运营的对象、边界和方法都要跟着变。

一、风险从“模型输出”转向“模型动作”

传统的 AI 内容风险，主要关注模型说了什么。智能体时代，更值得关注的是模型做了什么。

一个智能体通常由模型、提示词、工具、知识库和身份组成。它可以读取邮件、查询数据库、调用工单系统、执行脚本，也可以和其他智能体协作。每增加一个工具，就增加一条潜在的越权路径；每增加一个数据源，就增加一个泄露面。

这也是为什么“给智能体一个账号”是不够的。它需要独立的身份、最小权限、明确的任务边界和完整的操作审计。否则，一次提示注入就可能变成一次真实的数据导出或配置变更。

直接提示注入是用户在对话里输入恶意指令；间接提示注入则把恶意内容藏在模型会读取的文档、网页、邮件或知识库里。模型在处理这些内容时，可能把其中的指令当成任务的一部分。

典型场景是 RAG：知识库里的一个恶意文档，可能诱导模型忽略原有规则，输出敏感信息或调用不该调用的工具。对安全团队来说，这意味着数据来源本身也是攻击面，不能默认“内部文档就是可信的”。

智能体依赖大量工具、插件、API 和 MCP 服务。任何一个环节存在漏洞，都可能被用来执行命令、读取凭证或横向移动。工具的描述、权限、版本和来源，都需要像对待软件供应链一样管理。

企业至少应该建立一份 AI 工具清单：谁在用什么模型、什么插件、什么工具，分别有哪些权限，最近一次安全评估是什么时候。没有清单，就没有边界。

智能体往往需要“替人办事”，但它的权限不应该等于人的权限。更合理的做法是：

防火墙、WAF、EDR、堡垒机仍然是基础，但它们主要解决“谁从外面进来”的问题。智能体带来的风险，很多发生在“已经在里面”之后：

因此，安全运营需要增加一层“AI 行为治理”：不是只看网络流量和终端进程，而是看智能体的身份、意图、工具调用和数据流向。

先把企业里的模型、智能体、知识库、工具和 API 盘清楚。每一项都要有负责人、用途、数据范围、权限和生命周期。没有台账，事件发生时连影响范围都说不清。

记录智能体的完整行为链：用户是谁、任务是什么、模型看到了哪些上下文、调用了哪些工具、访问了哪些数据、结果是什么。审计日志要防篡改，并能够按事件、用户、数据对象和智能体身份检索。

对智能体可访问的数据做分类分级，敏感数据要有额外的访问控制和脱敏策略。对输出做检测，对批量导出、跨域传输和异常查询做告警。重点不是“禁止 AI 使用数据”，而是“让 AI 在明确的边界内使用数据”。

AI 安全治理最容易犯的错误，是等业务上线后再补。更有效的做法是把安全要求嵌入 AI 应用的建设流程：

同时，企业需要把 AI 供应链纳入供应商管理。模型、插件、工具和云服务的来源、版本、漏洞响应和安全责任，都要在合同和技术评估中明确。AI 安全不是安全部门一个团队的事，而是业务、研发、运维、法务和采购的共同责任。