「AI Agent 企业落地指南」系列第 3 篇（共 5 篇）——前两篇我们拆解了 Agent 的技术架构和企业选型逻辑。这一篇，聊一个所有人都在回避、但没人能绕过去的问题：安全。

一、开场：当 Agent 开始犯罪

2025 年底，McKinsey 引以为豪的内部 AI 助手 Lilli 被攻破。攻击者通过精心构造的提示注入，绕过了 Lilli 的访问控制层，获取了本应仅限合伙人级别可见的内部战略文档。一家以”帮客户管理风险”为核心业务的咨询巨头，自己的 AI 系统成了最大的风险敞口。

几乎同一时期，Amazon 内部的 AI 编码辅助工具在一次自动化部署中出现严重偏差——系统在缺乏充分人工审核的情况下批量处理了订单逻辑变更，导致约 12 万笔订单丢失或错误处理。损失不仅是金钱，更是客户信任的崩塌。

这两起事故有一个共同特征：出事的不是传统的聊天机器人，而是被赋予了工具调用权限和自主决策能力的 AI Agent。

它们不只是在”说”，它们在”做”。

二、为什么 Agent 比传统 AI 危险一个数量级

过去三年，企业 AI 安全的讨论集中在模型层面——幻觉、偏见、数据泄露。这些问题当然重要，但它们都有一个隐含假设：AI 的输出需要人类中转才能产生实际影响。

Agent 打破了这个假设。

一个生产环境中的 Agent 通常具备以下能力组合：

  • 工具调用（Tool Use）：可以直接操作数据库、调用 API、发送邮件、修改文件系统
  • 自主规划（Autonomous Planning）：可以将复杂任务拆解为多步骤执行链，无需人工逐步审批
  • 持久记忆（Persistent Memory）：可以跨会话记住上下文，积累对系统的”理解”
  • 多 Agent 协作（Multi-Agent Orchestration）：多个 Agent 之间可以互相委托任务，形成分布式执行网络

这意味着什么？一个被提示注入攻击劫持的 Agent，不再只是输出一段有害文本——它可以自主发起一连串真实操作：读取敏感数据库、调用支付 API、向外部服务器发送信息，而且这一切可以在人类注意到之前的几秒钟内完成。

传统 AI 的攻击面是一个点，Agent 的攻击面是一个图。每一个工具连接、每一个 Agent 间的信任关系、每一条执行链路，都是潜在的攻击入口。

这就是为什么整个行业在 2026 年第一季度突然”集体觉醒”——IBM、KPMG、RunSybil、LangGuard，从大厂到初创，所有人都在同时回答同一个问题：Agent 安全该怎么做？

三、IBM 分层安全模型：从网关到密码学信任链

2026 年 3 月 23 日，IBM Research 在 KubeCon EU 发表了一篇关键论文——《Keeping Your Agents in Check: Layered Security for Agentic Platforms in Production》。这篇论文的核心贡献不是某个具体工具，而是提出了一套完整的分层安全架构思想。

IBM 的核心论点非常清晰：Agent 安全不能只靠模型层面的护栏（guardrails），必须在平台的每一层都建立独立的安全机制。

其分层架构包含以下关键层级：

第一层：身份与授权（Identity & Authorization）

每个 Agent 必须拥有可验证的身份。IBM 的方案基于 OAuth 2.0 委托机制，通过 Keycloak 实现 Agent 与工具之间的密码学可验证信任。这意味着当一个 Agent 调用某个工具时，系统可以精确验证：”这个 Agent 是谁？它有权限调用这个工具吗？这次调用是在什么上下文中发起的？”

这一层解决的是最基础的问题：Agent 的行为必须可追溯到一个明确的身份。

第二层：网关层护栏（Gateway-Level Guardrails）

IBM 选择在 Envoy 网关层部署护栏，而不是将安全逻辑嵌入 Agent 内部。这个设计决策极其关键——它意味着即使 Agent 本身被攻破（比如通过提示注入），网关层的规则仍然会拦截异常行为。

护栏同时采用规则引擎和 AI 驱动的异常检测：规则引擎处理已知的危险模式（如禁止调用特定 API），AI 检测器则负责识别未知的异常行为模式。

第三层：运行时操作检查（Operational Checks）

在 Agent 执行过程中持续监控其行为模式。如果一个通常只读取数据的 Agent 突然开始写入操作，或者一个只处理财务数据的 Agent 开始访问人事系统，运行时监控应该立即触发警报。

关键设计原则：密码学可验证信任

IBM 方案中最值得注意的是”密码学可验证信任”这个概念——Agent 与工具之间的每一次交互都通过 OAuth 2.0 令牌机制建立信任链，而不是依赖”我配置了权限所以你应该信任我”这种隐式信任。在多 Agent 系统中，Agent A 委托 Agent B 执行任务时，这条信任链必须是可审计、可撤销的。

IBM 的方案本质上是把 Kubernetes 世界的零信任理念移植到了 Agent 世界：永远不信任，始终验证。

四、KPMG 五要素框架：给 Agent 发身份证

如果说 IBM 的方案是工程师视角，那么 KPMG 的 AI Agent 安全框架则是从企业治理视角出发的。KPMG 的框架包含五个核心要素：

要素一：唯一 Agent ID

每个 Agent 必须拥有全局唯一的标识符，就像企业员工有工号一样。这个 ID 不只是技术标识——它关联着权限范围、操作历史、责任归属。当出现安全事故时，第一个问题永远是”哪个 Agent 做的？”没有唯一 ID，这个问题无法回答。

要素二：系统卡片（System Card）

借鉴机器学习领域的”模型卡片”概念，KPMG 要求每个 Agent 都配备一张系统卡片，记录其：

  • 设计目的和能力边界
  • 使用的基础模型和版本
  • 可访问的工具和数据源
  • 已知的限制和风险
  • 最近一次安全评估结果

系统卡片本质上是 Agent 的”说明书+体检报告”，是治理和审计的基础文档。

要素三：人机协同的 AI 运营中心（AI Operations Center）

KPMG 建议企业建立专门的 AI 运营中心，功能类似传统的安全运营中心（SOC），但专注于 AI Agent 的监控和管理。运营中心的核心功能包括：实时监控 Agent 行为、异常告警响应、Agent 生命周期管理（上线、更新、下线）、以及关键操作的人工审批流程。

“人在回路”不是可选项，是必选项。尤其是在 Agent 处理高风险决策（财务交易、客户数据访问、系统配置变更）时，人工审批必须作为硬性约束存在。

要素四：红队测试（Red Teaming）

KPMG 强调，Agent 在上线前必须经过系统性的红队测试——不是开发团队自己测一下就算了，而是由独立的安全团队模拟真实攻击场景。测试内容包括提示注入攻击、权限提升尝试、跨 Agent 信任链利用、以及工具调用边界突破等。

要素五：终极 Kill Switch

最后一道防线：无论 Agent 的自主性有多高，企业必须保留一键终止所有 Agent 操作的能力。这个 kill switch 必须在技术上独立于 Agent 系统本身——如果 Agent 系统被完全攻破，kill switch 仍然必须可用。

KPMG 的框架回答了一个关键问题：Agent 治理不只是技术问题，更是组织能力问题。你可以有最好的技术护栏，但如果没有明确的权责体系、没有持续的安全评估流程、没有最后的紧急制动能力，Agent 在生产环境中就是一颗定时炸弹。

五、RunSybil：当 AI Agent 开始攻击 AI Agent

在防御侧框架逐渐成型的同时，攻击侧也在发生深刻变革。2026 年初，RunSybil 完成了 4000 万美元的种子轮融资，由 Khosla Ventures 领投，Anthropic 旗下的 Anthology Fund（与 Menlo Ventures 联合设立）、S32、Conviction 以及 Elad Gil 参投。天使投资人阵容更是星光熠熠——Palo Alto Networks CEO Nikesh Arora、Google 首席科学家 Jeff Dean 等均在列。

RunSybil 做的事情在概念上很简单，但在工程上极其硬核：用 AI Agent 对企业的 AI 系统进行持续的、自主的渗透测试。

其核心产品 Sybil 部署自主 AI Agent，以黑盒模式对目标系统进行持续攻击。与传统的静态代码扫描或基于规则的漏洞检测不同，Sybil 的 Agent 像一个专家级人类攻击者一样思考和行动：它会完整映射目标系统的技术栈（代码、API、云基础设施），发现被遗忘的端点，探测认证边界，最关键的是——跨层级链接漏洞。在一次金融平台的测试中，Sybil 将一个被评为低危的漏洞与其他弱点串联，最终构造出了一条可以未授权访问所有客户账户的攻击路径。

这一点至关重要。传统安全工具只能发现单点漏洞，而 Agent 时代的攻击者——无论是人类还是 AI——会利用多个低危漏洞的组合实现高危攻击。你需要 Agent 级别的攻击能力来检测 Agent 级别的安全风险。

RunSybil 的客户名单本身就是一个信号：Cursor、Notion、Turbopuffer、Thinking Machines Lab，以及多家财富 500 强企业和金融机构。这些公司的共同特征是：它们要么在大规模部署 AI Agent，要么在构建 AI Agent 基础设施。它们比任何人都清楚 Agent 安全的紧迫性。

联合创始人 Ari Herbert-Voss 的背景也值得关注：他是 OpenAI 在 2019 年招募的第一位安全研究人员，在哈佛攻读机器学习博士期间因为向 Sam Altman 和 Jack Clark 展示了对大语言模型的攻击能力而被直接录用。另一位联合创始人 Vlad Ionescu 此前在 Meta 领导攻击性安全红队。这个组合意味着 RunSybil 的 Agent 继承了业界顶尖攻防实践者的机构知识。

Vinod Khosla 在投资声明中指出：这个解决方案直面 AI 规模化与对抗性网络能力交汇处的前沿挑战。安全团队需要的不是离散项目，而是可以永久嵌入工作流的持续攻防平台。

六、LangGuard 与 Stripe Minions：治理层的两种范式

在安全框架和攻防工具之外，还有一个同样重要的维度：运行时治理。

LangGuard AI 定位为”AI 控制平面”——它的目标不是替代安全工具，而是为企业提供一个统一的 Agent 治理视图。核心功能包括：Agent 注册中心（发现和管理企业内所有 Agent）、运行时监控（追踪 Agent 的实际行为与预期行为的偏差）、以及自动化修复（当检测到违规行为时自动触发预设的处置流程）。

LangGuard 解决的是一个被很多企业忽视的问题：影子 Agent（Shadow Agents）。随着 Agent 开发门槛的降低，企业内部各个部门可能自行部署了大量 Agent，但 IT 和安全团队对此一无所知。这就像十年前的影子 IT 问题，但危险程度要高出几个数量级——因为这些 Agent 不只是访问数据，它们在自主执行操作。McKinsey 引用的数据显示，高达 90% 的 AI 项目停留在试点阶段。LangGuard 的思路是：与其让企业因为恐惧而裹足不前，不如提供一个让它们可以”有信心地”推进 Agent 上线的治理基础设施。

Stripe Minions 的蓝图机制（Blueprint）则提供了另一种范式参考。Stripe 在设计其内部 Agent 系统 Minions 时，引入了”蓝图”作为 Agent 安全的编排层。蓝图定义了 Agent 可以执行的操作序列、每一步的权限边界、以及在什么条件下必须暂停等待人工审批。

蓝图的精妙之处在于：它既不是完全放任（让 Agent 自主决策所有事情），也不是完全锁死（每一步都需要人工审批）。它根据操作的风险等级动态调整人工介入的程度——低风险操作自动执行，中风险操作记录审计日志，高风险操作必须人工审批。这种”分级自主”的理念，可能是当前 Agent 安全编排设计中最实用的思路。

七、信号汇总：2026 年 Q1 的 Agent 安全全景

把上述所有信号叠加在一起，一幅清晰的图景浮现：

层级 关键玩家 核心方案
架构与基础设施 IBM Research 分层安全模型，密码学信任链，网关层护栏
企业治理框架 KPMG Agent ID、系统卡片、AI 运营中心、红队测试、Kill Switch
攻击面检测 RunSybil AI-native 自主渗透测试，跨层漏洞链利用
运行时治理 LangGuard AI Agent 注册中心，行为监控，自动修复
安全编排设计 Stripe Minions 蓝图机制，分级自主，动态人工介入

这五个维度不是互相竞争的关系——它们共同构成了企业 Agent 安全的完整拼图。任何企业如果只关注其中一个维度，都会在另一个维度上留下致命盲区。

八、企业 Agent 安全检查清单

基于以上分析，以下是每个准备将 Agent 推向生产环境的企业都应该回答的问题：

身份与访问控制

  • 每个 Agent 是否拥有唯一标识符？
  • Agent 与工具之间的信任关系是否基于密码学可验证的机制（而非隐式信任）？
  • Agent 的权限是否遵循最小权限原则？
  • Agent 间的委托链是否可审计、可撤销？

运行时安全

  • 是否在网关层（而非 Agent 内部）部署了独立的安全护栏？
  • 是否同时使用规则引擎和 AI 驱动的异常检测？
  • 高风险操作是否强制要求人工审批？
  • 是否具备一键终止所有 Agent 操作的 Kill Switch？

治理与合规

  • 每个 Agent 是否配备系统卡片（目的、能力、限制、风险）？
  • 是否建立了专门的 AI 运营中心或等效的监控机制？
  • 是否掌握企业内所有 Agent 的完整清单（包括各部门自行部署的影子 Agent）？
  • Agent 的所有操作是否留有完整的审计日志？

攻防测试

  • Agent 上线前是否经过独立安全团队的红队测试？
  • 测试是否覆盖了提示注入、权限提升、跨 Agent 信任链利用等场景？
  • 是否建立了持续的（而非一次性的）安全测试机制？

安全编排

  • 是否根据操作风险等级建立了分级自主策略？
  • Agent 的操作边界是否通过蓝图或等效机制明确定义？
  • Agent 偏离预期行为时，是否有自动化的降级或熔断机制？

如果你的团队在上面的清单中有超过五项无法打勾，那么你的 Agent 还没有准备好进入生产环境。这不是保守——这是负责。

九、结语：安全不是减速带，是加速的前提

“安全是创新的阻碍”——这个叙事在 Agent 时代尤其危险。McKinsey Lilli 事件和 Amazon 12 万单丢失告诉我们的不是”不要用 Agent”，而是”没有安全框架的 Agent 比没有 Agent 更危险”。

IBM 的分层模型告诉我们安全必须贯穿每一层基础设施。KPMG 的五要素框架告诉我们治理是组织能力而非技术附件。RunSybil 用 4000 万美元的种子轮告诉我们攻防对抗已经进入 Agent vs Agent 的时代。LangGuard 和 Stripe 的实践告诉我们运行时治理和安全编排是让 Agent”安全地快”的关键。

2026 年 Q1 的信号已经足够明确：安全不是 Agent 上生产的减速带——它是入场券。

没有这张票，你哪儿也去不了。

本文是「AI Agent 企业落地指南」系列的第 3 篇。下一篇，我们将深入探讨 Agent 的成本经济学——当 Agent 开始 7×24 小时消耗 API 调用和计算资源时，企业如何计算 ROI？

参考资料

  1. IBM Research, “Keeping Your Agents in Check: Layered Security for Agentic Platforms in Production,” KubeCon EU 2026. https://research.ibm.com/publications/keeping-your-agents-in-check-layered-security-for-agentic-platforms-in-production

  2. Tech Company News, “RunSybil Raises $40 Million In Funding Led By Khosla Ventures,” 2026. https://www.techcompanynews.com/runsybil-raises-40-million-in-funding-led-by-khosla-ventures/

  3. LangGuard AI, “The AI Control Plane for Runtime Governance.” https://langguard.ai/

  4. KPMG, “AI Agents Security Framework: Five Pillars for Enterprise Governance,” 2025–2026.

  5. Stripe Engineering, “Scaling AI Agents with Minions: Blueprint Architecture for Safe Agentic Operations.”