调查：多数企业无法防御第三代 AI 智能体威胁
VentureBeat 的最新调查发现，大多数企业目前的安全架构难以抵御“第三代”AI 智能体带来的高级威胁。尽管企业投入了大量资源，但仍然普遍存在“有监控无执行、有执行无隔离”的结构性漏洞。
核心发现：安全现状令人担忧
调查显示，企业在 AI 安全领域的感知与现实存在巨大鸿沟：
- 过度自信 vs 高发事故： 82% 的高管认为现有政策能防御未经授权的智能体行为，但事实上，88% 的企业在过去一年中遭遇过 AI 智能体安全事件。
- 预算错配： 97% 的企业安全负责人预计未来 12 个月内将发生重大 AI 智能体事故，但仅有 6% 的安全预算专门用于应对此类风险。
- 可见性缺失： 只有 21% 的企业具备运行时可见性，能够实时监控其智能体的行为。
- 速度差距： 攻击者的突破时间已缩短至 27 秒，而传统的监控面板旨在处理人类速度的工作流，根本无法跟上机器速度的威胁。
三个关键安全阶段
针对 AI 智能体的安全防护可分为三个阶段，而目前大多数企业仍停滞在第一阶段。
- 阶段一：观察仅记录日志和监控仪表板。这是最基础的阶段，无法阻止正在发生的攻击。
- 阶段二：执行集成身份管理（IAM）和跨提供商控制，将观察转化为行动，能阻止部分恶意操作。
- 阶段三：隔离通过沙箱执行，在防护栏失效时限制爆炸半径。这是应对高级威胁的必要手段。
主要威胁与架构缺陷
OWASP 发布的《2026 年代理应用程序十大风险》定义了当前的攻击面，包括目标劫持、工具滥用、权限滥用和供应链漏洞等。许多风险在传统大语言模型（LLM）应用中并无先例。
身份架构危机： 调查显示，仅有 21.9% 的团队将智能体视为具有身份的实体，45.6% 仍在使用共享 API 密钥，25.5% 的已部署智能体甚至可以创建并指派其他智能体。这意味着企业中存在着大量未经安全团队配置的“幽灵”智能体。
防护栏不足： 研究表明，针对 Claude 3 Haiku 和 GPT-4o 的微调攻击可以分别以 72% 和 57% 的成功率绕过模型级别的防护栏。防护栏只能限制智能体“被要求做什么”，而无法限制被攻陷后“能接触什么”。
AI 智能体安全成熟度审计矩阵
以下表格映射了三个阶段的攻击场景、失效点及建议控制措施。
| 阶段 | 攻击场景 | 失效点 | 建议控制措施 |
|---|---|---|---|
| 1: 观察 | 攻击者在转发的邮件中嵌入载荷，智能体读取后 silently 将凭证泄露至外部端点。 | 运行时日志未捕获泄露，SIEM 未看到 API 调用。默认日志下无法区分智能体与人类操作。 | 将智能体 API 调用日志部署至 SIEM；建立每个角色的正常工具调用基线；对首次向未知端点的出站调用发出警报。 |
| 2: 执行 | 受感染的 MCP 服务器毒化工具描述，智能体调用该工具，利用继承的服务账户凭据向生产数据库写入攻击载荷。 | IAM 允许写入，因为智能体使用共享账户；写入操作无审批门禁；毒化工具在日志中与正常工具无法区分。 | 为每个智能体分配特定范围的身份数据；对所有写入操作要求审批工作流；撤销所有共享 API 密钥；每周对所有 MCP 服务器运行扫描。 |
| 3: 隔离 | 智能体 A 生成智能体 B 处理子任务。B 继承 A 的权限，提权至管理员，并重写组织安全策略。 | 智能体之间无沙箱边界；无人工门禁；安全策略修改对拥有管理员凭据的进程是有效操作。 | 对所有智能体执行进行沙箱隔离；对智能体间的委托实施零信任；任何智能体修改安全控制前需人工签署；设置紧急终止开关。 |
主流云平台的安全准备情况
各大云服务商在 AI 智能体安全能力上存在差异，目前没有一家提供商提供完整的第三代（隔离）技术栈。
| 提供商 | 身份原语 (阶段 2) | 执行控制 (阶段 2) | 隔离原语 (阶段 3) | 现状缺口 (截至 2026 年 4 月) |
|---|---|---|---|---|
| Microsoft Azure | Entra ID 作用域，Agent 360 | Copilot Studio DLP 策略，Purview | Azure 机密容器 (预览版) | 无智能体间身份验证；无 MCP 治理层；无法阻止进行中的工具调用。 |
| Anthropic | 托管代理：每代理权限 (Beta) | 工具使用权限，内置防护栏 (GA) | 托管代理沙箱：隔离容器 (Beta) | Beta 定价/SLA 未公开；会话数据锁定在 Anthropic 数据库；GA 时间待定。 |
| Google Cloud | Vertex AI 服务账户，IAM 条件 | VPC 服务控制，Model Armor | 机密虚拟机 (GA)，特定代理沙箱 (预览) | 代理身份作为服务账户而非原生主体；无代理间委托审计；Model Armor 不检查工具调用载荷。 |
| OpenAI | Assistants API，Agents SDK | Agents SDK 防护栏，输入/输出验证 | Agents SDK Python 沙箱 (Beta) | 无跨提供商身份联合；无终止开关 API；无 MCP 工具描述检查。 |
| AWS | Bedrock 调用日志，IAM 策略 | Bedrock Guardrails，Lambda 策略 | Lambda 隔离 (GA)，Bedrock 代理级沙箱 (路线图中) | 无统一代理控制平面；无代理身份标准；防护栏不检查 MCP 工具描述。 |
90 天补救行动计划
为了应对这些威胁，企业应立即采取行动，分三个阶段提升安全能力：
第 1-30 天：清点与基线
- 将每个智能体映射到指定的负责人。
- 记录所有工具调用，撤销共享 API 密钥。
- 在所有智能体 API 流量上部署只读监控。
- 对所有注册的 MCP 服务器运行安全扫描。
第 31-60 天：执行与限制
- 为每个智能体分配特定范围的身份数据。
- 针对写入操作部署工具调用审批工作流。
- 将智能体活动日志集成到现有的 SIEM 系统中。
- 进行“金丝雀令牌”测试：如果令牌离开网络，则说明第一阶段防御失败。
第 61-90 天：隔离与测试
- 对高风险智能体工作负载（涉及健康信息、个人身份信息、金融交易）进行沙箱隔离。
- 执行每会话最小权限原则。
- 要求智能体之间的委托必须经过人工签署。
- 使用红队测试隔离边界。
未来展望
随着《欧盟人工智能法案》第 14 条（人工监督义务）即将生效，以及监管机构（如 HIPAA 和 FINRA）对审计追踪要求的提高，企业不能再仅仅依赖“观察”模式。行业专家指出，AI 智能体和非人类身份将在企业中呈爆炸式增长，仅针对人类构建的身份安全架构将无法生存。企业必须从单纯的监控转向执行与隔离。
关注微信号：智享开源 | 关注微博：IMCN开源资讯网 ，可及时获取信息
评论列表
发表评论
为你推荐
关注微信
还没有任何评论，你来说两句吧！