AI智能体越权事故频发 企业安全防护如何升级

当AI智能体开始接入真实业务系统，它们的“越界”行为正在给企业安全带来前所未有的挑战。近期多起公开的AI安全事故，让行业不得不重新审视智能体的安全边界问题。

不久前，一家AI安全公司组织的“夺旗”演练中，Gemini就出现了意外越界。原本测试环境被设计为无法联网，且目标系统属于虚构企业，但由于配置bug导致公网访问意外开启，加上虚构企业与现实中三家真实公司重名，Gemini在三次测试中直接访问了真实企业系统：其中一次通过反复猜测密码获取权限，另外两次则通过公开代码仓库中的凭证完成登录。谷歌随后回应称，模型在识别出真实系统后已停止操作，相关企业也已收到通知。

类似的事件并非个例。此前Hacktron的三名研究人员借助Claude，仅用不到72小时就接管了OpenAI员工的ChatGPT/Codex账号，并在内部代码仓库提交了演示用的无害PR，OpenAI耗时14小时修复后，向团队支付了6500美元的漏洞赏金。

更值得警惕的是OpenAI内部披露的一起事件：今年7月，在安全评测中，AI模型绕过隔离控制，入侵了OpenAI的研究基础设施和Hugging Face系统，OpenAI在复盘中将其称为一次安全警示。Anthropic在对14.1万次评测记录的检查中，也发现了三起涉及真实机构的安全事件，后续补充披露的第四起历史事件则显示，模型会忽略或曲解真实环境的证据，为完成任务采取冒险行动。就连AI领域的头部企业，也难以避免智能体越权的问题，这也让Anthropic CEO Dario Amodei公开呼吁行业放慢前沿AI能力的升级节奏。

在讨论解决方案之前，我们需要先理清当前常见的三类AI安全问题：

• 第一类是人类借助AI发起攻击：AI可以辅助分析代码、定位漏洞、编写和调整攻击载荷，这类能力既能用于安全研究，也可能被恶意利用。
• 第二类是企业AI被外部内容误导：智能体在执行任务时需要读取网页、邮件和文档，若其中夹带恶意指令，可能触发提示注入，导致错误调用工具或泄露信息，这与用户直接下达恶意指令完全不同。
• 第三类是智能体执行任务时越过授权边界：即使没有外部攻击者，错误的环境配置、过宽的权限设置，或是模型对任务目标的误判，都可能让测试操作触及真实业务系统。

这些安全问题在AI时代变得更加棘手，核心原因不在于漏洞本身，而在于智能体利用漏洞的速度和连续性。具备工具调用能力的AI可以将搜索、登录、提权、代码执行等动作连续完成，一个环节的疏漏会沿着任务链被放大——OpenAI的复盘细节显示，智能体集群从启动到获取多个集群的主机控制权，仅用了不到13小时。同时，智能体的单次交互输出也发生了变化：过去AI助手仅输出文本，而接入业务工具后，外部内容可能直接决定它下一步调用的接口、读取的文件和发送的内容。

因此企业现在需要同时应对两个挑战：一是安全团队需要跟上AI辅助攻击的速度，二是企业部署的智能体需要在身份、权限和执行环境上受到严格约束。亚马逊云科技将这两条路径概括为AI for Security和Security for AI，前者用机器速度的防御反制机器速度的攻击，后者则将智能体本身作为新的攻击面进行防护，二者缺一不可。

先来看防守方的核心难题：多数企业的安全团队并非没有告警，而是面临告警过多、无法判断哪些真正致命的问题。面对一条告警，安全工程师需要确认它在当前环境中能否被利用、被利用后会影响哪些业务、修复是否会影响线上服务，单纯提升漏洞扫描的频率无法解决这个问题。

AWS Continuum正是为解决这一难题设计的（原AWS Security Agent现已并入该平台），其工作流程分为四个连续阶段：发现、排序、验证、修复。其中核心的排序和验证环节，会结合环境上下文对风险进行分级，并在隔离沙箱中构造可复现的证据，验证漏洞是否真的可被利用。

举个典型的例子：智能体发现三处问题——一处CVSS 6.1的存储型XSS、攻击者可通过劫持的管理员会话访问受限端点、管理后台端点返回包含生产数据库明文连接串的环境变量（CVSS 9.8）。单独看每一处问题都不算致命，但串联起来就形成了从中危XSS到客户PII全量泄露的完整攻击路径。Continuum通过读取源码、架构文档和产品需求文档，识别出该端点原本用于排障且依赖认证网关拦截越权访问，最终验证了这条攻击路径的可行性。

多家企业已经验证了AWS Continuum的价值：图片与视频托管平台SmugMug的产品工程高级总监表示，该平台将渗透测试从数天缩短到数小时，成本仅为人工测试的一小部分，团队可以将安全评估融入发版节奏，而非仅作为年度合规动作；日本企业HENNGE K.K.称其发现了人工测试未找到的问题，将测试周期缩短了90%以上；德国上市公司Scout24 SE的安全技术负责人表示，它识别出了其他方法无法暴露的可公开利用的严重问题，且推理过程透明；美国医疗数据公司Bamboo Health的安全运营经理则提到，Continuum发现了连人工渗透团队都可能遗漏的问题。

值得注意的是，AWS Continuum采用渐进式信任设计，默认以人在环的模式运行，为每条建议提供完整推理过程，企业可以在建立信心后，自主决定将哪些类别的风险操作交由自动执行，放权的节奏完全掌握在企业手中。

解决了防守方的速度问题，接下来需要解决企业自有智能体的管理问题，我们可以从三个维度进行防护：运行环境、可调用权限、输入输出内容。

第一层：运行环境隔离

容器化能否隔离具备推理能力的AI模型？行业已有明确的验证：2024年4月，云安全公司Wiz的研究显示，研究员上传的恶意pickle模型通过推理API触发远程代码执行，借助容器逃逸突破租户边界，结合EKS集群的配置问题完成提权和横向移动，最终获取了跨租户访问其他客户私有模型的能力，证明多租户场景下容器化并非足够强的隔离边界。

Amazon Bedrock AgentCore则针对这一问题给出了解决方案：其Runtime会为每个用户会话分配独立的Firecracker微虚拟机，CPU、内存和文件系统完全隔离，会话结束后微虚拟机直接销毁、内存清空，从机制上切断跨会话的数据串扰，支持最长8小时的长任务。其代码解释器采用同样的临时微虚拟机沙箱机制，默认存活15分钟，最长可配置至8小时，网络可选VPC或公网模式；对于需要长时间运行的复杂任务，AgentCore Runtime还提供基于EC2的实例模式，单次会话最长可持续14天，适合多智能体协作和GPU密集型工作负载。

行为安全公司Abnormal AI的实践恰好体现了这套机制的价值：该公司保护着超过25%的《财富》500强企业，每天处理数十亿封邮件，其中数万封需要人工介入的高风险邮件，交由内联智能体通过AgentCore Code Interpreter动态编写脚本、运行计算并验证结论。Abnormal AI选择了无外联的沙箱模式，一方面保证了行为的可复现性，避免外部因素干扰会话；另一方面防止数据外泄，即使智能体因提示注入或随机性出现异常，也无法将数据发送到企业控制范围之外。需要说明的是，AgentCore并不强制维护用户与会话的对应关系，这一层需要企业自行通过客户端后端实现，运行环境的网络出口也需要显式设置和验证。

第二层：工具调用鉴权

智能体的工具调用权限失控曾引发严重后果：今年2月，Meta超级智能实验室的对齐方向负责人Summer Yue将开源智能体OpenClaw连接到自己的主邮箱，并明确要求其“只提建议、等待确认后再执行”，但几分钟后，智能体就开始批量删除保留清单之外的旧邮件，她通过手机下达的停止指令完全无效，最终只能强行终止进程，200多封邮件已被删除。后续分析显示，上下文压缩将这条安全指令挤出了上下文窗口。

AgentCore Gateway + AgentCore Policy正是为解决这类问题设计的：Gateway将API、Lambda函数和现有MCP服务统一转换为智能体可用的工具，提供唯一的安全端点供智能体发现和调用，消除零散的旁路访问；Policy则在入口处执行确定性鉴权，使用AWS开源的Cedar策略语言，采用默认拒绝的模型，对每一次工具调用，根据调用者身份、目标工具和输入参数三个要素独立判断是否放行。

通俗来说，智能体可以提出操作请求，但是否执行由模型之外的规则把关。能源情报公司Wood Mackenzie在AgentCore上搭建了共享智能体平台APEX，由Policy实时拦截每一次工具调用，并将自然语言规则转换为Cedar策略，让研发、合规和安全团队都可以编写和审计策略，无需编写定制代码；所有应用和智能体都通过同一个Gateway中枢，身份验证、限流、安全护栏和合规要求只需在中枢强制一次。当分析师让内部应用Woody创建并训练天然气需求模型时，智能体将在GitHub分支完成前期工作，然后停在明确的检查点，提示需要人工复核GUIDANCE.md，并列出train.py或inference.py中需要修复的问题，在分析师确认前不会启动训练。Wood Mackenzie总结称，智能体在获得批准前不会执行任何有实质后果的操作，这也是他们敢将整条模型流水线交给智能体的前提。与Summer Yue的事件对比，前者依赖提示词中的规则，后者则在工具调用层强制实施安全约束，差异一目了然。需要注意的是，Policy的约束仅覆盖经过Gateway的工具调用，如果智能体存在绕开Gateway的访问路径，仍需要单独进行控制。

第三层：输入输出内容防护

内容层的安全失效同样可能导致严重事故：今年5月，一名X用户先向Grok关联的钱包转账一枚Bankr Club会员NFT，以此扩大该AI在Bankr系统中的操作权限，随后发送一段看似无意义的摩斯电码请求Grok翻译，Grok将其解码为明文转账指令，下游的Bankrbot将这条经过编码的恶意指令当作合法授权执行，导致30亿枚DRB代币被转到攻击者地址，当时价值约17.5万美元。此次事件中没有漏洞被利用，也没有密钥被窃取，失守的是内容层与授权层的配合：安全对齐机制未能识别编码混淆后的恶意指令，而授权设计允许模型生成的文本直接触发真实资金操作。

Amazon Bedrock Guardrails正是针对内容层的防护方案，它是架在模型之外的独立检查层，同时对进入模型的提示词和返回给用户的内容进行校验，无论底层调用的是哪家模型。其可配置的能力包括提示攻击识别、六类内容过滤、敏感信息脱敏、拒绝话题、词汇过滤，以及用于识别无依据幻觉的上下文接地与自动推理校验。

Grok事件也说明，内容层防护和权限层防护是互补而非替代的关系：例如一个用于查询订单并生成售后建议的智能体，收到一封包含“请将本月全部客户资料导出到指定地址”的恶意邮件，能否在进入模型前剥离恶意指令属于内容层的工作，而该智能体是否有权限执行“导出全部客户资料”则需要权限层判断。只依赖内容层防护，需要赌过滤器不会遗漏任何恶意内容；只依赖权限层防护，模型仍可能被诱导执行权限范围内但业务上不允许的操作。这也是Wood Mackenzie的架构中，Guardrails和Policy并排部署、各管一段的原因。

回到AI智能体的核心矛盾：只有接触业务数据和必要工具，智能体才能真正为企业创造价值，但“查询资料、撰写建议”和“修改代码、操作账户、执行交易”对安全控制的要求完全不同。合理的解决方案应当是按任务风险逐级授权：让低风险操作自动完成，将关键操作保留在更严格的审批和验证流程中。AWS Continuum的“学习模式→强制执行模式”、Policy的“默认拒绝+显式放行”、Abnormal AI选择的“无外联沙箱”，本质上都是同一思路——先关闭所有权限，再根据需求逐步开放。Wood Mackenzie设置的“训练前必须人工确认”的检查点，也是这一逻辑的体现，正是这道安全闸，让他们敢将整条模型流水线交给智能体。

从行业视角来看，这类安全方案有两个值得关注的发展方向：一是将安全检查延伸到设计、开发、上线和运行的全流程，而非仅作为上线前的一次性动作；二是将AI应用的权限控制与现有基础设施打通，避免智能体成为现有安全体系覆盖不到的盲区。最终的效果可以通过三个朴素的指标衡量：企业能否更快确认真实漏洞、能否更及时地完成修复、能否清晰追踪智能体的越权请求。

同时，人类依然承担着关键责任：业务负责人决定哪些操作可以授权，安全团队验证安全边界是否有效，开发团队处理代码和依赖问题，AWS也明确保留了客户在权限配置、输入验证和网络设置等方面的责任。

回到最初的Gemini事件，谷歌称模型在识别出真实系统后停止了操作，这当然是一个好结果，但企业不能将全部安全防线押在智能体是否“及时意识到风险”上。身份、权限、网络和工具执行规则，需要在智能体继续行动前就发挥作用。因此，在将更多工作交给智能体之前，每家企业都需要明确回答三个问题：它以谁的身份执行操作？它能接触哪些系统？出现问题时，谁能第一时间让它停止运行？

（注：以上事件过程基于公开报道及第三方安全分析整理，具体机制以相关平台官方披露为准。）