文章总结: 本文以PA方案为样本,剖析智能体安全从内容合规向行为链路控制的落地路径,指出需构建涵盖身份治理、统一控制面与端点治理的核心能力维度。建议企业分阶段建立技术强制点并配套管理制度,同时呼吁国内厂商从大模型护栏向智能体控制面演进,以应对MCP与A2A交互风险。 综合评分: 90 文章分类: AI安全,安全建设,解决方案,威胁情报,安全运营
基于PA的智能体安全落地方案看智能体安全如何落地
dimu dimu
AI简化安全
2026年7月22日 21:36 广东
在小说阅读器读本章
去阅读
随着 AI 智能体从「对话应答」走向「自主执行」,安全建设的重心正在发生结构性转移。仅在大模型输入输出两端部署内容过滤,已不足以覆盖智能体调用工具、连接 MCP 服务、跨系统执行动作所引入的新型风险。
Palo Alto Networks 的 Prisma AIRS(下文简称 PA 方案)是目前业界体系化程度较高的智能体安全参考实现之一:以 发现(Discover)— 评估(Assess)— 防护(Protect) 为主线,在防护层通过 AI Gateway(统一纳管 LLM、MCP、A2A 流量)、运行时安全检测、智能体身份治理与端点侧管控 四类能力,将安全边界从「内容」延伸至「行为」。
本文首先梳理全球威胁态势的变化,说明智能体安全为何必须走向体系化落地;随后解析 PA 方案的架构逻辑,从中抽象出通用的技术能力维度;再简要评述国内云厂商的平台型实践;最后从技术路径与管理体系两个维度,给出企业侧的落地建议,并探讨国内专业安全厂商由「大模型安全护栏」向「智能体控制面」演进的可行路径。文中产品能力均以厂商公开材料为依据,分析性判断供读者参考。
一、威胁态势:风险重心从「模型输出」转向「智能体行为」
在过去两年,企业对大模型安全的关注点主要集中于输出合规与数据泄露。进入 2026 年,威胁情报与学术研究共同指向一个新的风险层面:智能体能够调用工具、连接 MCP 服务、变更系统状态、代替用户执行操作——攻击面由单点的输入输出,扩展为完整的行为链路。
以下三组公开可查证的信号,可以说明这一转变:
- • 智能体攻击面已获实证验证。 多伦多大学等研究团队在仿真企业网络中验证了由开源大模型驱动的自适应蠕虫,公开材料记载其七日渗透率约 73.8%;安全厂商 Sysdig 披露了利用开发环境漏洞完成横向移动与数据外泄的实际入侵事件,恶意载荷疑似由 LLM 代理实时生成;VS Code 生态亦出现与 MCP 安装链路相关的远程代码执行漏洞。上述事件共同表明:开发者工作站、MCP 插件与推理基础设施均已成为现实攻击面,单纯的模型内容安全无法覆盖。
- • 间接提示注入与影子 AI 呈常态化趋势。 不可信网页或文档中的隐藏指令可以操纵智能体偏离既定任务、外泄会话数据;多项行业调研显示,相当比例的员工在使用未经审批的第三方 AI 工具。若防护仅覆盖用户的显式输入,则无法拦截经由工具返回值、检索内容等间接通道注入的恶意指令。
- • 监管要求从原则性表述进入可执行清单。 国内智能体分类分级管理、工具调用权限与供应链安全等要求正在推进;海外金融监管机构亦已将「可审计、可问责的 AI 运行时」纳入合规预期。治理要求正在从「方向性倡导」转变为「可核查的落地项」。
概括而言:国际头部厂商已将智能体安全构建为 控制面、运行时、身份、端点 四位一体的体系,而国内专业安全厂商的产品重心多数仍停留在大模型内容护栏层面。下文以 PA 方案为样本,分析体系化落地的具体形态。
二、PA 智能体安全方案的架构解析
Prisma AIRS 3.0 Agent Security 并非单点产品,而是围绕 Discover — Assess — Protect 构建的闭环体系。
2.1 发现:建立 AI 资产的全景可见性
持续盘点企业环境中的全部 AI 资产,包括部署于云端与 SaaS 平台的企业智能体、运行于终端的编码类与浏览器类智能体,以及它们所连接的 MCP 服务器、插件与工具,并对资产间的交互关系进行可视化呈现。其目标在于消除「影子智能体」与「影子 MCP」形成的治理盲区。
2.2 评估:在部署前收敛风险暴露面
- • 制品扫描:在智能体进入生产环境之前,分析其代码与配置中可能构成多步攻击链的薄弱环节,并提供可定位到具体代码位置的修复建议。
- • 智能体红队:依据目标智能体的用途、工具集与既有护栏进行画像,生成针对性的模拟攻击(如工具滥用、目标操纵);评估结论映射至 OWASP、NIST AI RMF、MITRE ATLAS 等框架,并转化为运行时策略建议。
- • 模型安全:对模型文件及其供应链进行扫描,回答「该模型制品能否进入生产流水线」——这一能力与对话内容防护相互独立、互为补充。
2.3 防护:对智能体行为实施实时控制
(一)AI Gateway:统一策略强制点
AI Gateway 位于智能体与其所访问的外部资源之间,在动作执行之前完成认证、授权与策略强制,覆盖 LLM 调用、MCP 工具调用与 A2A(Agent-to-Agent)交互 三类流量。业务团队可以继续使用既有的编码助手与企业智能体,安全强制能力则下沉至基础设施层,由平台团队统一运营。
(二)AI Runtime Security:内容与威胁检测引擎
Gateway 的内联检查能力由 AI Runtime Security 提供,涵盖提示注入检测、敏感数据防泄露(DLP)、恶意 URL 识别与不当内容过滤等。需要澄清的一个常见误解是:Runtime 并非「以另一个大模型充当裁判」,而是由安全策略驱动的专用检测能力组合(包括基于正则与机器学习的 DLP、URL 信誉等)。它的职责是检查进出模型与工具的交互内容,其自身并不承担业务推理。
(三)智能体身份治理
核心原则是 智能体身份独立于用户身份:为每个智能体分配短生命周期、任务级、可即时吊销的机器身份;当智能体代表用户执行操作时,再叠加用户委托关系。Gateway 作为策略执行点(PEP),在每次交互中校验「请求方是哪个智能体、是否有权调用目标工具」。缺乏身份模型的 MCP 与 A2A 接入,实质上等同于「持有凭据即可执行任意操作」。
(四)Agentic Endpoint:终端侧治理
Cursor、Claude Code 等智能体直接运行于开发者终端,其本地工具调用与本地 MCP 交互 不会经过企业级 AI Gateway。终端侧能力为此类活动提供可见性、策略强制与执行隔离,与传统 EDR 形成互补——前者关注智能体行为治理,后者关注传统恶意载荷检测,二者的检测对象与技术路线并不相同。
(五)工具调用前检测:强制力取决于部署路径
| 部署路径 | 强制力 | | — | — | | 远程 LLM / MCP / A2A 流量经由 Gateway | 强制:未经策略放行的调用无法送达目标 | | 编码助手通过宿主 Hooks 调用 Runtime API | 强制:工具执行前由宿主机制拦截检查 | | 仅将安全检测封装为 MCP 工具(依赖模型主动调用) | 非强制:无法保证每次工具调用均经过检测 |
三个关键结论:其一,AI Gateway 是面向 AI 操作全生命周期的控制面,而非传统 API 网关的功能延伸;其二,Runtime 是安全检测引擎,而非业务大模型;其三,只有经过强制点的调用才具备「行为前检测」的确定性,终端侧旁路流量必须由端点能力或 Hooks 机制单独覆盖。
三、智能体安全的通用能力维度(6+1)
从 PA 方案中可以抽象出一组与具体厂商无关的能力维度。企业可以通过自建、云平台能力或专业安全产品组合实现,但任一维度的缺失都将形成防护缺口。
| 能力维度 | 需要回答的问题 | | — | — | | 1. 资产发现与态势 | 企业内存在哪些智能体、模型、MCP、技能与知识库?由谁使用? | | 2. 上线前评估 | 制品、配置、工具、MCP 是否经过安全评估与红队验证?是否设有准入门槛? | | 3. 智能体身份与授权 | 每个智能体的身份是否可验证?代表谁执行?权限是否具备时限与吊销机制? | | 4. 统一运行时控制面 | 模型调用、MCP 工具调用与 A2A 交互是否汇聚于同一策略强制点? | | 5. 内容与行为运行时防护 | 提示注入、数据泄露、恶意工具定义、危险参数能否按策略实施放行、告警或阻断? | | 6. 端点与旁路治理 | 编码助手、本地 MCP 与进程内工具调用由哪一层能力覆盖? | | +1 运营闭环 | 审计、告警、溯源与策略回写是否形成持续运营机制? |
对照国内现状:第 5 维中的 对话内容护栏 相对成熟,而第 3、4、6 维普遍薄弱。需要指出的是,内容护栏无论如何增强,都无法应对「身份不明的智能体直连业务工具」与「不经网关的本地行为」这两类风险——它们分别属于身份治理与端点治理的范畴。
四、国内云厂商的平台型实践(概述)
国内部分云厂商采取「平台型」路径建设智能体安全能力:与自有智能体开发及运行平台深度集成,以测评、加固、准入为核心,并逐步补充运行时检测与 MCP 防护能力。
综合公开白皮书与最佳实践材料,其典型能力形态包括:
- • 全生命周期管理平台:通过智能体平台 API 同步资产,对配置、工具、MCP 与技能包实施静态扫描,开展面向业务场景的红队测评,并提供系统提示词加固建议。
- • 意图过滤与对话代理:将需要管控的对话流量导入代理层,基于业务意图实施前置过滤。
- • MCP 安全网关:部署于 MCP Client 与 MCP Hub 之间,对请求与响应实施过滤和审计——相较于单纯的对话护栏,这是向行为层防护迈出的实质性一步。
- • 运行时检测(部分厂商称为 AIDR):需注意该缩写与海外厂商的「AI Detection and Response」并非同一概念,国内材料中多指 Agent Intrusion Detection & Response,通常基于 OTel 等可观测性日志进行有状态的行为分析与告警。从公开材料看,此类能力多处于监测与验证阶段,尚不宜等同于内联阻断型网关。
平台型路径的优势在于与云上智能体开发生态的原生集成,准入与测评流程完整;其边界在于多云与混合架构、桌面端编码智能体、统一智能体身份以及跨云 A2A 治理等场景,通常仍需企业自建治理体系或引入独立的安全控制面。
五、企业侧落地路径:技术控制点与管理体系并重
智能体安全的落地效果取决于两个维度的同步建设:缺乏管理体系,安全网关只是一台设备;缺乏技术强制点,管理制度只是一份文档。
5.1 技术落地:分阶段建立控制点
建议企业按以下四个阶段推进,避免在建设初期即宣称覆盖全部智能体场景:
| 阶段 | 控制点建设内容 | 对应 PA 方案的参考组件 | | — | — | — | | 第一阶段 | 明确现有对话护栏的流量覆盖边界,完成策略与审计字段的标准化 | Runtime 检测与安全 Profile | | 第二阶段 | 建设 MCP 代理强制点(部署于 Client 与 Server 之间),实现工具清单、入参与出参的检测与审计 | Gateway 的 MCP 纳管能力 | | 第三阶段 | 建立 智能体身份体系与工具级授权,在此基础上扩展至 A2A 治理 | 身份治理与 Gateway 策略执行 | | 第四阶段 | 通过编码助手 Hooks 与端点能力覆盖本地旁路流量 | Agentic Endpoint |
配套的技术自查清单:生产环境智能体访问外部模型与远程 MCP 是否强制经过统一控制点;工具调用前的身份鉴权与内容检查是否可独立配置;终端编码助手是否纳入资产台账与策略管控;告警事件能否完整还原「用户—智能体—工具」的调用链路。
5.2 管理落地:六项管理能力
技术产品无法替代治理机制。建议企业围绕以下六个方面建立可操作的管理体系:
| 管理维度 | 落地要点 | | — | — | | 组织与职责 | 明确智能体安全的责任主体(安全、平台、业务三方分工);以 RACI 界定上线审批、密钥保管与事故响应的具体责任人 | | 分类分级与准入 | 按风险等级划分智能体(只读问答、可调用工具、可写入生产系统);建立上线准入清单,涵盖系统提示词、工具与 MCP、知识库等级、模型来源与供应链扫描结论 | | 名录与变更治理 | 建立智能体、MCP 与技能的企业级资产台账;规范变更与下线流程;建立影子 AI 的发现、限流与处置机制 | | 身份与权限制度 | 以制度形式确立智能体身份独立于用户身份;禁止长期有效的高权限令牌;明确凭据吊销与轮换的服务级别要求 | | 运营指标与审计 | 定义最小审计字段(操作主体、智能体标识、目标工具、策略命中结果);设立覆盖率、阻断与告警量、未登记智能体数量等运营指标 | | 应急与持续改进 | 制定智能体专项应急预案(误操作、数据外泄、MCP 供应链投毒);建立周期性红队评估机制;将评估结论回写至运行时策略,形成闭环 |
从监管对齐的角度看,分类分级、工具调用权限、供应链安全与日志留痕等要求,最终落点正是「准入机制、身份制度与审计能力」这三项,而非内容安全词库的持续扩充。管理维度决定「由谁定义智能体的行为边界」,技术维度决定「该边界能否被有效强制」——二者缺一不可。
六、对国内专业安全厂商的演进建议
基于行业观察:国内专业安全厂商的主力产品仍集中于 大模型内容护栏与对话/API 安全网关,在 智能体身份、行为层运行时防护、MCP 与 A2A 统一控制面、端点侧智能体治理 等方向上,成熟的产品化方案相对匮乏。云厂商已在平台测评与 MCP 网关方向取得进展,而专业安全厂商的客户群体恰恰更需要 跨云、混合架构下可审计的独立强制点——这正是差异化竞争的空间所在。
6.1 大模型安全网关为何尚未演进至 MCP 与 A2A 纳管
从技术角度看,这一演进不存在原理性障碍。 安全网关的本质是协议感知的内联强制点:既然能够解析模型 API 流量,同样可以解析 MCP(JSON-RPC over stdio/SSE/HTTP)与 A2A 协议消息;检测引擎与路由、身份能力亦可解耦分层。PA 的产品路径已经验证了「控制面与检测引擎分工」这一架构的可行性。
真正的制约在于产品化层面,主要体现为六点:
- 1. 需求结构:存量订单仍以内容合规、提示注入防护与 DLP 为主,MCP 与 A2A 治理的付费需求刚刚形成。
- 2. 控制点假设:传统网关假设流量形态为「应用与模型之间的 HTTP 交互」,而智能体的大量动作发生于进程内工具、本地 MCP 与浏览器扩展中——仅扩展协议解析能力仍无法覆盖终端旁路。
- 3. 身份模型缺位:MCP 与 A2A 治理要求回答「哪个智能体、代表谁、是否有权调用该工具」,纯内容检测无法承载此类判断。
- 4. 工程投入:MCP 传输方式多样、工具描述存在投毒风险、A2A 标准仍在演进,构建生产级统一网关的工作量相当于研发一款新产品,而非既有规则库的升级。
- 5. 检测对象的迁移:从文本内容扩展至工具参数、执行副作用与多步会话状态,检测模型与策略体系需要重新设计。
- 6. 产品组织:身份治理、红队评估与端点能力往往分属不同产品线,在 SKU 与叙事重组之前,难以形成一体化方案。
6.2 演进路径建议
- • 产品定位升级:由「大模型安全网关」演进为 「AI/智能体控制面(Gateway)+ 运行时检测 + 端点治理」 的组合叙事,将内容护栏重新定位为运行时检测的能力模块之一。
- • 建设节奏:与前述企业侧四阶段路径保持一致——优先建设 MCP 强制点与审计能力,继而补齐智能体身份与 A2A 治理,最后覆盖端点旁路。
- • 支撑客户的管理体系:产品应提供资产台账接口、准入工作流、工具级授权与可导出的审计证据,帮助客户落实前述六项管理能力,而非仅仅扩充检测规则。
- • 保持能力边界的透明:明确声明产品「可管控的流量范围」,将终端旁路场景作为独立议题呈现,避免过度承诺。
结语
PA 方案给出的核心启示在于:智能体安全落地的关键,是将安全网关升级为覆盖 模型调用、MCP 工具调用与 A2A 交互 的行为控制面,以运行时引擎承担内容与威胁检测,以身份体系明确行为归属,以端点能力覆盖端侧需求,并以发现与评估机制把守准入关口。
对企业而言,应同步建设 技术层面的 6+1 能力维度 与 管理层面的六项治理能力;对国内专业安全厂商而言,问题从来不是「技术上能否解析 MCP 协议」,而是 产品假设、身份模型、旁路覆盖与产品组织尚未按照智能体时代的要求重构。主动完成这一升级,远比在既有护栏之上持续叠加检测规则,更能回应客户面临的真实风险。
本文配图均为概念示意,非厂商官方架构图或产品界面。产品能力表述以各厂商公开材料为准。
参考:
参考文献
[1] Palo Alto Networks. Prisma AIRS 3.0 Agent Security(Solution Brief).
https://www.paloaltonetworks.com/prisma/prisma-airs
[2] Palo Alto Networks. Prisma AIRS AI Runtime Security(Datasheet).
https://www.paloaltonetworks.com/prisma/prisma-airs
[3] Palo Alto Networks. What Is an AI Gateway?(Cyberpedia).
https://www.paloaltonetworks.com/cyberpedia/what-is-an-ai-gateway
[4] Palo Alto Networks. Prisma AIRS AI Red Teaming(产品公开材料).
https://www.paloaltonetworks.com/prisma/prisma-airs
[5] Palo Alto Networks. Prisma AIRS AI Gateway
历史相关文章:
迈向 Agentic SOC:CrowdStrike AI 驱动的安全运营建设思路与落地路径
OWASP2026《智能体 AI 安全与治理现状报告》导读与启示
全球智能体安全版图:主要国际厂商的方案、理念与部署路径
当 AI 安全的战场从「模型」搬到「智能体运行时」:一份 CISO 技术版态势观察
Agentic AI时代的安全重构:从大模型风险到自治智能体安全体系
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:AI简化安全 dimu dimu《基于PA的智能体安全落地方案看智能体安全如何落地》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。










评论