（来源：金科之家网）
近期多起 AI 智能体安全事件，给行业敲了警钟。测试场景下的 AI 智能体突破沙箱边界、访问业务数据；智能体因权限配置过宽，在异常输入下自主发起越权调用、读取客户信息。这些事故已经不再是模型 “说错话”，而是具备执行能力的 AI 系统，直接触达真实业务资产、凭证与数据。
与此同时，另一边的攻防格局也在变化：攻击者同样在用 AI 批量生成载荷、自动化漏洞探测、批量绕过传统安全规则。告警量持续膨胀，安全分析师被海量告警淹没，人工研判、溯源、处置的速度，越来越跟不上自动化攻击的节奏。
关于 AI 安全有两个方向：AI for Security 解决的是“安全团队如何更高效运用 AI 做好安全防护”；Security for AI 解决的是“ AI 系统会不会自己出安全问题”。前者是运营升级，后者是新型风险控制。
一、AI 安全的两个方向
1. AI for Security 是安全运营的升级
AI for Security 不是把大模型接进 SOC 就算完成，而是要把 AI 嵌入告警分诊、线索关联、威胁研判、事件调查、响应编排和报告生成等环节。
AI 可以先从多源告警聚合做起，把来自防火墙、EDR、NDR、WAF、邮件网关、云平台和终端的数据统一接入，再补齐资产、用户、数据敏感度和业务影响等上下文，给出初步判断和处置建议。
但 AI 不应被当成 “自动解决一切” 的黑盒。高风险动作仍需人工确认，尤其是封禁账号、隔离主机、回滚配置、调用外部接口等操作。更稳妥的方式是分级自治：低风险动作自动执行，中风险动作二次确认，高风险动作走审批。
2. Security for AI 是 AI 系统的边界控制
AI 应用上线后，最大的变化不是多了一个聊天窗口，而是多了一个能读数据、调工具、发邮件、改数据库、访问第三方 API 的执行体。
以 OWASP LLM Top 10 最新版为例，提示注入、敏感信息泄露和过度代理权等风险值得重点关注。其中过度代理权尤其需要警惕：即智能体被授予超出业务必要范围的工具与数据权限，在提示注入、逻辑偏差触发下自主调用能力，造成非预期操作。
安全策略也不是越严越好。严苛的输入输出拦截、全量人工审批也会抬高业务使用成本，催生未登记的影子模型、私搭智能体，形成治理盲区。
二、AI for Security 的落地要点
1. 从告警降噪开始，而不是从大模型开始
企业不必一开始就建设复杂的 AI 安全平台。第一步可以只做告警聚合和降噪，把防火墙、EDR、NDR、WAF、邮件网关、云平台和终端等数据统一接入。
AI 的价值首先体现在：合并相似告警，关联同一攻击链，自动降级低价值告警，突出需要人工关注的线索。这一步不要求模型 “自动判断威胁”，只要能让分析师少翻几个系统、少看一半无效告警，就已经有收益。
比较务实的路径是：先接入 3 到 5 类高噪告警源并建立基线；再做聚合、去重和上下文补齐；然后让 AI 生成研判摘要，由人工确认；最后只对低风险动作开放自动执行，中高风险动作进入二次确认或审批。
2. 用 AI 辅助调查，但保留人工决策
AI 可以帮助查询资产信息、用户行为、历史告警、漏洞状态和外部情报，也能生成初步调查摘要。但调查结论不应直接变成处置动作。涉及生产系统、客户数据、核心代码库、财务系统和外部通知时，必须由人确认。
更稳妥的做法是设置分级自治边界：低风险动作自动执行，中风险动作二次确认，高风险动作必须审批。这样既能提效，又不会把安全运营变成不可控的自动执行链。
3. 把 AI 接入现有流程
AI 安全能力如果不能接入工单系统、CMDB、漏洞管理平台、身份管理系统和现有 SOC 流程，就很难持续产生价值。
选型时不要只看 “能不能对话”，要看能否调用现有工具、能否写入审计日志、能否被策略引擎约束、能否被审计回溯。不能进入现有流程的 AI 安全工具，很容易变成新的信息孤岛。
三、Security for AI 的落地要点
1. 先做 AI 资产盘点
企业必须先回答三个问题：有哪些模型在跑；有哪些智能体在调用工具；它们访问了哪些数据、API、数据库和第三方服务。
很多 AI 风险不是因为模型本身被攻破，而是因为企业不知道某个智能体已拥有过高权限，也不知道它正在访问敏感数据。
资产盘点至少应形成三张清单。第一张是模型清单，记录模型来源、版本、部署方式、数据接入和责任人。第二张是智能体清单，记录智能体身份、工具白名单、数据范围、可调用 API 和审批链。第三张是数据与工具清单，记录 RAG 向量库、MCP 服务器、插件、API 密钥、服务账号和日志留存情况。
还要补充非人类身份清单，包括服务账号、API Key、OAuth 凭证和临时凭证。智能体风险往往不是 “模型会不会说错话”，而是 “这个服务账号为什么能读这张表”。
2. 在输入输出边界加网关
所有可访问敏感数据、具备工具调用能力的大模型调用，都应经过统一 AI 网关或策略层。网关的作用不是简单过滤敏感词，而是做四件事：校验输入是否合规；限制输出能触达哪些系统；控制工具调用范围；记录完整证据链。
对于 RAG 应用，还要特别注意检索内容中的隐藏指令。网页、邮件、文档、知识库片段都可能携带间接提示注入。网关不能只看出站内容，也要看检索进来的内容。
同时，AI 网关不能成为单点故障。企业需要为网关设定性能预算、旁路或降级策略，以及审计失败处理机制。否则一旦网关影响业务体验，业务团队就可能绕过它，治理也会失效。
3. 管住智能体权限
智能体权限治理是 Security for AI 的核心。每个智能体都应有明确身份、最小权限、临时凭证、工具白名单和操作上限。
对高风险操作必须设置人工审批，例如删除数据、修改权限、调用生产 API、外发邮件、访问客户信息、写入向量库等。同时要限制执行时长、调用次数、并发数和成本预算，避免智能体因错误逻辑或恶意输入造成无界消耗。
落地时可按 “主体 — 工具 — 数据 — 动作 — 审批 — 限额 — 审计” 逐项确认。例如，读取客户信息可以允许，但必须记录日志；发送外部邮件需要人工确认；修改生产数据库应禁止或双人审批；写入向量库要经过白名单和内容审核；单次执行要限制调用次数、并发数、token 成本和执行时长。
4. 保护数据、模型和供应链
训练数据、微调数据、向量库、提示词模板、模型权重、开源组件、第三方插件和 MCP 服务器都可能成为攻击入口。
企业需要建立 AI 物料清单，记录数据来源、模型版本、依赖组件和权限关系。对外部权重和插件不能默认信任。对包含个人信息、客户数据、财务数据和核心代码的场景，应优先采用数据分级、脱敏、访问控制和审计留存。
5. 建立持续评估机制
AI 系统迭代快，一次性上线评估不够。建议把评估分成三个阶段：上线前准入评估、变更回归测试、运行态监测与持续红队。
评估范围应覆盖提示注入、越权调用、数据泄露、工具滥用、记忆污染和供应链风险。红队用例至少包括直接提示注入、间接提示注入、RAG 隐藏指令、工具滥用、越权调用、记忆污染和第三方插件风险。
评估不能只问 “模型会不会说错话”，还要问 “智能体在异常输入下会不会执行危险动作”。
四、总结
AI for Security 和 Security for AI 不是二选一，而是需要同步推进：用 AI 提升安全运营效率，同时用安全方法约束 AI 系统本身。
AI for Security 面对的是告警、日志、工单、资产、漏洞和事件；Security for AI 面对的是模型、智能体、工具调用、向量库、插件、API 密钥和服务账号。
从目标看，前者追求降噪、提速和减负，后者追求边界、权限和审计。从负责人看，前者通常由安全运营团队主导，AI 团队提供模型和工程能力；后者需要安全、AI 平台、应用研发、数据治理和合规团队共同负责。
免责声明：自媒体内容仅用于记录和分享，请勿用于商业用途。所有内容来自于网络，或由人工智能服务生成。如有文字或图片涉及侵权，请联系修改或删除。文章内容不代表本人观点，亦不代表本人所在机构观点，不构成任何投资建议。
