Blue Origin在AWS Bedrock AgentCore上运行着2700+个AI Agent（来源: aws.amazon.com, 2026-03-28）。DraftKings的内部Agentic编码引擎DraftCode在2025年累计完成103000+次PR评审、407000条自动化评论，为工程师节省33400小时（来源: LinkedIn/Gary Stafford, 2026-03-28）。ServiceNow向29000+名员工部署了Claude，销售准备时间削减95%（来源: globalsecuritymag.com, 2026-03-28）。

这些数字在投资者演示文稿里光鲜亮丽。但请回答一个问题：这些Agent中，有多少拥有对生产数据库的写入权限？有多少持有未经轮换的API密钥？有多少能在无人审批的情况下调用外部服务？

如果你的CISO无法在30秒内回答这些问题——欢迎来到Agent Sprawl的现实。

2026年3月，4条看似不相关的新闻在同一周内密集爆发：Reco推出覆盖Salesforce Agentforce等平台的AI Agent安全平台；GitHub披露2024年全年泄露3900万个密钥，AI编码助手被明确标记为新攻击向量；Onit Security完成1100万美元种子轮专攻Agent身份治理；Rapid7收购Kenzo补强Agent运行时检测能力。这不是巧合，这是市场对一场正在展开的系统性风险的集体定价。

本文的核心论点是：Agent Sprawl不是IT治理问题，而是企业安全的下一个”影子IT”时刻——但其攻击面、速度和不可预测性远超10年前的SaaS蔓延。 大多数企业的安全架构根本没有为”非人类自主实体”设计过，而现有的IAM（身份与访问管理）、SIEM（安全信息与事件管理）和零信任框架在面对Agent-to-Agent通信时几乎全部失效。

1. Agent Sprawl的规模：从”几个Copilot”到”几千个自主实体”

让我们先建立一个事实基线。

Jensen Huang在GTC 2026上宣称”AGI已经以AI Agent的形式到来”（来源: Search B, 2026-03-28）。这句话的商业翻译是：每一家主要云厂商和企业软件公司都在竞相将Agent嵌入其产品栈。Salesforce有Agentforce——定位为”可以独立处理完整客户服务流程的数字员工”（来源: dotsquares.com, 2026-03-28）。Snowflake推出了Project SnowWork自主企业AI平台，为业务用户编排规划、分析和执行任务（来源: ciclopiemonte.com, 2026-03-28）。AWS的Bedrock AgentCore已经在Blue Origin的案例中证明了千级Agent的部署能力。Anthropic的Claude现在可以物理操作macOS上的文件、浏览器和开发工具，Dispatch功能支持跨设备任务分配（来源: beallsforida.com, 2026-03-28）。MiniMax的M2.7模型甚至具备”自我进化能力”，其Forge框架支持Agent团队协作（来源: minimax.io, 2026-03-28）。

把这些拼在一起：一家中型企业在2026年可能同时运行着Salesforce Agentforce处理客户工单、Snowflake SnowWork执行数据分析、Claude Code Agent编写和审查代码、AWS Bedrock Agent处理供应链逻辑，以及若干内部定制Agent执行HR、财务和合规任务。保守估计，一家5000人以上的企业可能部署了200到500个具有不同权限级别的AI Agent。大型科技公司如Blue Origin的数字已经到了2700+。

这就是Agent Sprawl的本质：Agent的增长速度远超安全团队的可见性和控制能力。

与10年前的SaaS蔓延（Shadow IT）做一个类比是有启发性的，但也是危险的。SaaS蔓延时代，员工自行注册Dropbox或Slack，安全团队的主要风险是数据泄露和合规违规。Agent蔓延的风险维度完全不同：

  • 自主性：SaaS工具等待人类操作；Agent主动执行任务、调用API、修改数据。
  • 链式传播：一个Agent可以触发另一个Agent，形成多跳执行链，单点失控可能导致级联效应。
  • 身份模糊性：SaaS账户绑定到具体员工；Agent的身份归属、权限边界和审计追踪在大多数企业中尚无标准。
  • 速度：人类员工犯错的速度受限于打字速度；一个失控的Agent可以在毫秒级时间内执行数千次API调用。

Arm发布的AGI CPU——基于Neoverse架构、专为数据中心Agentic AI工作负载设计、目标每机架8160核/36kW风冷——从硬件层面确认了这个趋势的不可逆性（来源: cdcra.com, 2026-03-28）。当芯片公司开始为Agent工作负载优化硅片时，你就知道这不是一个会消退的浪潮。

2. 攻击面解剖：Agent的3层安全困境

要理解Agent Sprawl为什么是安全灾难，需要拆解Agent的技术架构。一个典型的企业AI Agent包含3个攻击面层：

第1层：凭证与密钥（Credentials & Secrets）

Agent需要API密钥、OAuth令牌、数据库凭证来执行任务。GitHub在2024年的Secret Scanning报告中披露，全年共检测到3900万个泄露的密钥（来源: GitHub, 2025）。这个数字本身已经触目惊心，但更值得关注的是GitHub明确将AI编码助手标记为新的攻击向量。

逻辑链条如下：开发者使用AI编码助手（如GitHub Copilot、Claude Code、Cursor）生成代码。这些工具在自动补全过程中，可能将硬编码的密钥、令牌或连接字符串直接写入代码库。开发者在代码审查中未能捕获这些泄露（尤其是在DraftKings那种407000条自动化评论的规模下，人类审查者的注意力已经被稀释），密钥随后被推送到公共或半公共仓库。

但这只是问题的一半。当Agent本身成为代码的编写者和执行者时，密钥管理的复杂度呈指数级增长。一个编码Agent可能在运行时动态生成临时凭证、创建新的服务账户、或将密钥存储在非标准位置。传统的密钥管理工具（如HashiCorp Vault、AWS Secrets Manager）假设密钥的生命周期由人类或CI/CD管道管理——它们没有为”一个Agent在执行任务过程中自主创建并使用密钥”这种场景设计过。

Scale AI发布的MCP-Atlas工具使用基准测试显示，即使是最强的模型（Claude Opus 4.5通过率62.3%，GPT-5.2通过率60.6%），在工具调用场景中仍有接近40%的失败率（来源: scale.com/research/agenticrubrics, 2026-03-28）。这意味着Agent在执行任务时会频繁重试、回退、尝试替代路径——每一次重试都可能暴露凭证、产生异常日志、或触发未预期的副作用。

第2层：权限与访问控制（Permissions & Access Control）

企业IAM系统为人类用户设计：一个员工有一个身份、一组角色、一套权限。Agent打破了这个模型的每一个假设。

首先是身份归属问题。当ServiceNow向29000+员工部署Claude时，每个员工调用Claude执行的操作，应该归属于员工的身份还是Claude的身份？如果一个销售代表让Claude Agent自动修改CRM中的客户记录，审计日志显示的是谁的操作？

其次是权限膨胀问题。Agent需要跨系统操作才能完成有意义的任务。一个处理客户退款的Agentforce Agent可能需要同时访问CRM（读取客户信息）、ERP（查询订单状态）、支付网关（发起退款）和通知系统（发送确认邮件）。在实践中，大多数企业为了让Agent”能工作”，会授予远超最小权限原则的访问级别。

第三是Agent-to-Agent委托问题。当Anthropic的Dispatch功能允许跨设备任务分配、MiniMax的Forge框架支持Agent团队协作时，我们面临的是一个Agent将自己的部分权限委托给另一个Agent的场景。现有的OAuth 2.0和RBAC（基于角色的访问控制）框架没有为这种”非人类实体之间的权限委托”设计过标准化机制。

第3层：行为与意图（Behavior & Intent）

这是最深层也最难防御的攻击面。Agent的行为不是确定性的——相同的输入可能产生不同的输出，尤其是在使用推理模型和自我进化能力（如MiniMax M2.7的SWE-Pro基准56.22%表现所暗示的那样）的情况下。

传统安全工具通过规则匹配或签名检测来识别恶意行为。但一个Agent的”正常行为”本身就是模糊的、上下文依赖的、随时间演化的。一个编码Agent在凌晨3点向生产环境推送代码——这是正常的自动化部署，还是被注入了恶意指令的提示词攻击（Prompt Injection）的结果？

Prompt Injection在Agent场景中的危害远超聊天机器人场景。在聊天场景中，最坏的结果是模型输出不当内容。在Agent场景中，Prompt Injection可以导致Agent执行未授权的操作——删除数据、泄露密钥、调用外部API发送敏感信息。当Claude可以”物理操作你的电脑”时，Prompt Injection的攻击面从”文本输出”扩展到了”系统操作”。

3. 安全供应商的集体响应：4笔交易，1个信号

现在让我们回到本周的4条新闻，分析安全市场如何响应Agent Sprawl。

Reco：Agent安全的”可见性层”

Reco推出的AI Agent安全平台覆盖Salesforce Agentforce等主流Agent平台。Reco的核心价值主张是可见性——帮助企业发现和映射其环境中所有运行的AI Agent，包括它们的身份、权限、数据访问模式和跨系统交互。

这直接对应了Agent Sprawl的首要问题：你不知道你有多少Agent。就像10年前Netskope和CASB（云访问安全代理）厂商通过发现Shadow IT来建立市场一样，Reco押注的是”发现Shadow Agent”将成为企业安全的第一步。

Reco选择首先覆盖Salesforce Agentforce是一个精准的市场切入点。Salesforce的客户基数庞大（超过150000家企业），Agentforce作为”数字员工”的定位意味着这些Agent将处理最敏感的客户数据和业务流程。如果Reco能在Salesforce生态中建立标准，就有机会扩展到Snowflake SnowWork、AWS Bedrock AgentCore等平台。

GitHub密钥泄露：AI编码助手的安全悖论

3900万个泄露密钥这个数字需要放在上下文中理解。GitHub在2023年检测到的泄露密钥数量约为1200万。2024年跳升到3900万，增长超过225%。虽然部分增长来自检测能力的提升（GitHub扩展了Secret Scanning的覆盖范围），但GitHub官方将AI编码助手标记为新攻击向量，表明AI生成的代码正在成为密钥泄露的重要来源。

这里存在一个深层悖论：AI编码助手提高了开发效率（DraftKings节省33400小时），但同时扩大了攻击面。 当代码生成速度超过安全审查速度时，安全债务就会累积。DraftKings的407000条自动化评论中，有多少涉及密钥泄露的检测？我们不知道。但我们知道的是，在AI编码助手的辅助下，代码生成量的增长速度远超安全工程师的招聘速度。

更深层的问题是：当Agent本身成为代码的编写者（如Claude Code Agent），并且这些Agent可以自主创建和管理凭证时，密钥泄露的检测窗口从”代码审查阶段”缩短到了”运行时”。你需要在Agent执行的瞬间检测异常，而不是在代码合并后的静态扫描中发现问题。

Onit Security：1100万美元押注Agent身份治理

Onit Security完成的1100万美元种子轮专注于Agent身份治理。这个赛道的出现本身就说明了一个问题：现有的身份治理工具（如SailPoint、Saviynt、CyberArk）在Agent场景中存在根本性的架构缺陷。

传统身份治理假设身份是静态的、可枚举的、与人类1:1映射的。Agent身份是动态的（可以在运行时创建和销毁）、可组合的（一个Agent可以调用另一个Agent）、与人类多对多映射的（一个员工可能触发多个Agent，一个Agent可能服务多个员工）。

1100万美元的种子轮在2026年的安全市场中算不上大额融资，但它的信号价值在于：风投已经开始为Agent身份治理这个细分赛道单独下注。这意味着市场共识正在形成——Agent安全不是现有安全工具的一个功能扩展，而是一个需要原生解决方案的新品类。

Rapid7收购Kenzo：运行时检测的补强

Rapid7收购Kenzo补强的是Agent运行时检测能力。Rapid7作为SIEM和XDR（扩展检测与响应）领域的老牌玩家，其收购逻辑清晰：传统的日志分析和威胁检测管道无法处理Agent产生的海量、高频、语义复杂的事件流。

一个运行2700+个Agent的环境（如Blue Origin）每天可能产生数十亿条Agent操作日志。这些日志不是简单的”用户A在时间T访问了资源R”，而是”Agent X在执行任务链Y的第3步时，调用了工具Z，传入了参数P，获得了结果Q，然后决定执行操作W”。要在这种语义丰富的事件流中检测异常，需要全新的检测引擎——这正是Kenzo的技术价值所在。

4. 大多数人没看到的：Agent Sprawl的3个隐藏风险

隐藏风险1：Agent供应链攻击

当企业使用MCP（Model Context Protocol）将Agent连接到外部工具和数据源时，它们实际上在创建一个新的供应链依赖图。Scale AI的MCP-Atlas基准测试（来源: scale.com, 2026-03-28）评估的正是Agent使用外部工具的能力——但没有人在评估这些外部工具的安全性。

想象一个场景：一个Agent通过MCP连接到一个第三方数据服务。攻击者入侵了该数据服务，在返回结果中嵌入了恶意指令（间接Prompt Injection）。Agent将这些指令解释为合法的任务指示，执行了未授权的操作。这不是假设——这是MCP架构的固有风险，而目前没有标准化的防御机制。

传统的软件供应链安全（如SBOM、依赖扫描）关注的是代码依赖。Agent供应链安全需要关注的是运行时数据依赖——Agent在执行过程中从哪些外部源获取信息，这些信息是否可信，以及Agent如何基于这些信息做出决策。这是一个全新的安全问题域，目前几乎没有成熟的解决方案。

隐藏风险2：Agent间的信任传递漏洞

当MiniMax的Forge框架支持Agent团队协作、Anthropic的Dispatch功能支持跨设备任务分配时，我们面临一个经典的安全问题在新场景中的复现：信任传递。

在传统的微服务架构中，服务间通信通过mTLS（双向TLS）和服务网格（如Istio）来保障。但Agent间通信的语义远比API调用复杂——一个Agent可能向另一个Agent传递自然语言指令、上下文信息和权限委托。如何验证这些传递的完整性和授权性？如何防止一个被入侵的Agent通过信任链”感染”其他Agent？

这个问题在Blue Origin的2700+个Agent环境中尤为突出。如果Agent A信任Agent B，Agent B信任Agent C，那么Agent A是否隐式信任Agent C？如果Agent C被入侵，攻击者是否可以通过信任链访问Agent A的资源？这种多跳信任传递在人类组织中通过层级审批和职责分离来控制——但在Agent环境中，没有等价的机制。

隐藏风险3：合规的”灰色地带”

当Salesforce将Agentforce定位为”数字员工”时，它打开了一个监管灰色地带。GDPR（通用数据保护条例）要求数据处理有明确的法律基础和目的限制。当一个Agent自主决定访问客户数据来完成任务时，这个决定是否满足GDPR的”合法利益”或”合同履行”基础？谁对Agent的数据处理决策承担法律责任——部署Agent的企业、提供Agent平台的Salesforce、还是训练底层模型的Anthropic？

SOX（萨班斯-奥克斯利法案）要求财务流程的内部控制和审计追踪。当一个Agent自主执行财务操作（如处理退款、调整账目）时，现有的内部控制框架是否覆盖了Agent的操作？审计师是否接受”Agent日志”作为合规证据？

这些问题目前没有明确的监管答案。但可以确定的是，第一起因Agent失控导致的重大数据泄露或财务损失事件，将迫使监管机构快速出台Agent治理框架。企业如果不提前建立Agent治理能力，将在监管响应中处于极其被动的位置。

5. 对立视角：Agent Sprawl是否被过度炒作？

视角1：”Agent安全是现有安全框架的自然延伸”

持这一观点的人认为，Agent本质上是软件——软件安全的既有原则（最小权限、深度防御、零信任）完全适用于Agent。企业不需要全新的安全品类，只需要将现有工具（IAM、SIEM、DLP）的覆盖范围扩展到Agent即可。CyberArk和SailPoint等老牌身份安全厂商已经在扩展其产品以支持”非人类身份”（机器身份、服务账户），Agent身份只是这个趋势的延续。

这个观点有一定道理，但忽略了一个关键差异：Agent的行为是非确定性的。传统软件的行为由代码决定——你可以审计代码来理解软件会做什么。Agent的行为由模型权重、提示词、上下文和外部输入共同决定——你无法通过审计任何单一组件来预测Agent的行为。这使得传统的静态安全分析（代码审计、配置审查）在Agent场景中的有效性大幅降低。

视角2：”Agent Sprawl的风险被安全厂商故意放大以创造市场”

这是一个更尖锐的反对意见。安全行业有一个众所周知的模式：每一次技术浪潮都会催生一批安全厂商，它们通过放大恐惧来创造需求。云安全、容器安全、API安全、AI安全——每一个都经历了”恐惧驱动的市场创造”阶段。Agent安全是否只是最新的一个？

我承认这个风险存在。Onit的1100万美元种子轮、Reco的Agent安全平台、Rapid7收购Kenzo——这些都可能是对一个尚未完全成形的威胁的过早押注。如果Agent的部署速度比预期慢（例如，如果企业发现Agent的ROI不如预期），Agent安全市场可能会经历一个”期望低谷”。

我的判断

Agent Sprawl的安全风险是真实的，但其时间线可能比安全厂商暗示的更长。 短期内（2026-2027年），大多数企业的Agent部署仍处于”试点和扩展”阶段，Agent数量可能在几十到几百个之间，安全团队通过手动治理和现有工具的扩展可以勉强应对。但中期（2028-2030年），随着Agent-to-Agent协作成为常态、Agent自主性持续提升（MiniMax的自我进化能力是一个早期信号），安全挑战将呈非线性增长。

关键转折点将是第一起因Agent失控导致的重大安全事件。就像2017年的Equifax数据泄露事件催化了整个应用安全市场一样，一起涉及AI Agent的重大事件将在数周内改变企业CISO的优先级排序。

GitHub的3900万密钥泄露数据告诉我们，攻击面已经在快速扩大。AI编码助手被标记为新攻击向量不是理论推演——这是GitHub基于真实数据得出的结论。当Agent从”辅助编码”进化到”自主执行”时，攻击面的扩大速度只会加快。

6. 企业应对框架：Agent安全的5个优先级

基于以上分析，我建议企业按以下优先级构建Agent安全能力：

优先级1：Agent资产清单（Agent Inventory）。 你无法保护你看不到的东西。建立一个覆盖所有Agent的资产清单，包括每个Agent的身份、所有者、权限、数据访问范围和运行状态。这是Reco的价值主张所在，但企业也可以通过内部工具实现基础版本。

优先级2：Agent身份与权限治理。 为每个Agent建立独立的身份（而非复用人类用户的凭证），实施最小权限原则，建立权限审查和轮换机制。这是Onit Security所瞄准的市场空间。关键挑战是如何在不影响Agent效率的前提下实施权限约束——过于严格的权限会导致Agent无法完成任务，过于宽松则增加风险。

优先级3：密钥管理的Agent适配。 将密钥管理工具（如HashiCorp Vault）的策略扩展到Agent场景，包括：Agent运行时的动态密钥注入、Agent创建的临时凭证的自动过期、Agent代码中硬编码密钥的实时检测。GitHub的3900万密钥泄露数据表明，这个问题的紧迫性远超大多数企业的认知。

优先级4：Agent行为监控与异常检测。 建立Agent操作的基线行为模型，实时检测偏离基线的异常行为。这需要新一代的检测引擎——不是基于规则匹配，而是基于Agent行为的语义理解。Rapid7收购Kenzo正是为了补强这个能力。

优先级5：Agent供应链安全。 审计Agent通过MCP或其他协议连接的所有外部工具和数据源，评估间接Prompt Injection的风险，建立外部输入的验证和过滤机制。这是目前最不成熟但可能最关键的安全领域。

7. 市场预判：Agent安全将成为2027年最热的安全赛道

从投资和并购的角度看，Agent安全市场正在经历”品类定义”阶段。Onit的1100万美元种子轮和Rapid7收购Kenzo是早期信号。我预计在未来12-18个月内：

  1. 至少3家主要安全平台公司（Palo Alto Networks、CrowdStrike、Wiz中的某几家）将通过收购进入Agent安全赛道。
  2. Agent安全的TAM（总可寻址市场） 将在2028年达到30-50亿美元，到2030年可能超过100亿美元——前提是Agent部署按当前轨迹增长。
  3. MCP安全 将成为一个独立的子赛道。随着MCP成为Agent工具调用的事实标准（Scale AI的MCP-Atlas基准已经在推动这个标准化），围绕MCP的安全审计、输入验证和信任管理将催生专门的创业公司。
  4. 监管将在2027-2028年介入。 欧盟的AI Act已经为”高风险AI系统”建立了框架，Agent作为自主决策实体很可能被纳入高风险类别。美国的监管路径更不确定，但SEC（证券交易委员会）可能会率先要求上市公司披露Agent相关的运营风险。

从技术演进的角度看，Arm发布的AGI CPU（来源: cdcra.com, 2026-03-28）和Tactical Edge AI与AWS的战略合作（来源: tacticaledgeai.com, 2026-03-28）表明，Agent基础设施正在从云端向边缘扩展。边缘Agent（运行在本地设备或边缘数据中心的Agent）将带来额外的安全挑战——更有限的计算资源意味着更轻量的安全控制，更分散的部署意味着更大的攻击面。

So What：这对你意味着什么

如果你是CISO：现在就开始建立Agent资产清单。不要等到安全事件发生后再行动。与你的云服务商（AWS、Azure、GCP）和SaaS供应商（Salesforce、ServiceNow、Snowflake）确认它们的Agent安全路线图。评估Reco、Onit等新兴Agent安全厂商的产品成熟度。

如果你是开发者或工程领导：审查你的AI编码助手生成的代码中的密钥泄露风险。在CI/CD管道中集成密钥扫描工具（如GitHub Secret Scanning、GitGuardian、TruffleHog）。为你的Agent建立独立的服务账户和最小权限策略，而不是复用开发者的个人凭证。

如果你是投资者：Agent安全是一个真实且快速增长的赛道，但要警惕”解决方案寻找问题”的创业公司。关注那些有真实企业客户（而非仅有POC）的公司，以及那些在Agent行为检测（而非仅仅是Agent发现）方面有技术壁垒的公司。

如果你是CEO或董事会成员：将Agent治理纳入企业风险管理框架。Agent不是一个IT问题——当一个Agent可以自主处理客户数据、执行财务操作、修改生产系统时，它是一个业务风险和合规风险。要求你的CISO和CIO在下一次董事会上汇报企业的Agent部署现状和安全治理计划。

Agent Sprawl不会自行解决。每一天，你的企业中都有新的Agent被创建、被授予权限、被连接到敏感系统。问题不是”是否会出事”，而是”出事时你是否有能力发现、理解和遏制”。

3900万个泄露的密钥已经告诉你答案了。

参考资料

  1. AWS AI Implementation — Blue Origin Case Study — Amazon Web Services, 2026-03-28
  2. Salesforce Prompt Builder vs Agentforce — Dotsquares, 2026-03-28
  3. Scale AI MCP-Atlas Agentic Rubrics — Scale AI, 2026-03-28
  4. ServiceNow and Anthropic Collaboration Announcement — Global Security Mag, 2026-03-28
  5. Arm AGI CPU for Agentic AI — CDCRA, 2026-03-28
  6. DraftKings DraftCode Agentic Coding Engine — Gary Stafford/LinkedIn, 2026-03-28
  7. Snowflake Project SnowWork — Ciclo Piemonte, 2026-03-28
  8. MiniMax M2.7 Release — MiniMax, 2026-03-28
  9. GitHub Secret Scanning 2024 Report — GitHub, 2025

主题分类：agentic-cases