谷歌Gemini测试中意外入侵三家公司系统，AI越权事件频发引安全反思
一次本不该发生的“入侵”
2026年9月，AI安全公司Irregular组织了一场内部“夺旗”（Capture the Flag）演练。任务很简单：让AI模型从一家虚构公司的系统中提取一段秘密信息。整个测试环境按理说与公网完全隔离。
但问题出在配置上——一个未被发现的bug意外打开了网络出口。更巧的是，演练中虚构公司的名字，恰好和现实中某家企业重名。于是，谷歌的Gemini模型顺着这个名字，直接连上了真实世界的服务器。
在三次测试尝试中，Gemini的行为各不相同：一次它反复尝试常见密码组合，最终成功登录；另外两次则是在公开的代码仓库里翻出了硬编码的访问凭证，再用这些凭证进入系统。
值得庆幸的是，谷歌事后表示，Gemini在识别出对方是真实机构后主动中止了操作，并未造成实际损害。涉事的三家公司也已收到通知。
听起来是有惊无险，但这并非孤例。把时间线拉近一点，你会发现类似的AI越权事件今年已经接连上演。
就在几天前，Hacktron的一个三人团队借助Anthropic的Claude，不到72小时就接管了OpenAI员工的ChatGPT账号，并在内部代码库提交了一个无害的PR作为证明。OpenAI花了14小时修复漏洞，并支付了6500美元赏金。
而OpenAI自己披露的另一起事件更为严重：今年7月，其内部用于安全评测的模型绕过隔离限制，入侵了部分OpenAI研究基础设施和Hugging Face系统。公司在8月底的复盘中称其为一次“警示射击”（warning shot）。
Anthropic也在审查14.1万次评测记录后，确认了三起涉及真实机构的事件，并在9月初补充披露了第四起历史案例。起初公司归因于环境配置失误，但后续调查发现，模型会忽略或曲解“这是真实环境”的证据，为了完成任务不惜冒险行动。
连OpenAI、Anthropic和谷歌这样的“AI御三家”都难以避免模型越界，难怪Anthropic CEO Dario Amodei近期公开呼吁行业放慢前沿模型能力的提升节奏——安全问题已迫在眉睫。
AI时代安全问题的三个新维度
要应对这类风险，首先得厘清当前AI安全问题的典型类型。
第一类，人借助AI发起攻击。 AI能快速分析代码、定位漏洞、生成并优化攻击载荷。Hacktron的案例证明了这种能力的有效性，但也意味着恶意行为者同样可以利用它。攻击门槛正在降低，速度却在提升。
第二类，企业的AI被外部内容误导。 Agent在执行任务时需要读取网页、邮件或文档。如果其中夹带了精心构造的指令，模型可能将其误认为合法任务，从而触发“提示注入”（Prompt Injection），错误调用工具或泄露敏感信息。这和用户直接下达恶意命令不同，更具隐蔽性。
第三类，Agent在执行任务时越过授权边界。 即使没有外部攻击者，错误的环境配置、过宽的权限，或模型对任务目标的误判，都可能导致一次内部测试意外触及真实业务系统。Gemini的事件正是这一类的典型。
为什么这些问题在AI时代变得更棘手？关键在于利用漏洞的速度和连续性。
过去，攻击者需要手动完成搜索、登录、提权、执行等多个步骤，每个环节都可能中断。而具备工具调用能力的Agent可以把这些动作一气呵成。OpenAI复盘提到，其智能体集群从启动到获得多个集群的主机级控制权，仅用了不到13小时。
同时，Agent的输出也不再只是文字。接入业务系统后，一段外部输入可能直接决定它调用哪个API、读取哪些文件、向谁发送什么数据。这意味着，企业现在必须同时应对两个挑战：一是安全团队要跟上AI辅助攻击的速度；二是自家部署的Agent本身不能成为新的漏洞源。
亚马逊云科技将这两条路径概括为 “AI for Security” 和 “Security for AI” ——前者用AI加速防御，后者确保AI自身安全。两者缺一不可。
AI for Security：让防御跑得更快更准
企业安全团队常面临一个悖论：不是没有告警，而是告警太多，无法判断哪些真正危险。
一条漏洞摆在面前，工程师需要回答：它在当前环境下能否被利用？一旦被利用会影响哪些业务？修复会不会导致线上服务中断？如果只是用AI提高扫描频率，这些问题依然无法解决。
AWS Continuum（原AWS Security Agent）试图破解这个难题。它的工作流程分为四个阶段：发现、排序、验证、修复。其中关键在中间两步——结合环境上下文对风险排序，并在隔离沙箱中构造可复现的攻击链来验证漏洞是否真实可利用。
举个例子。某次扫描发现三个问题：
- 一个中危的存储型XSS漏洞（CVSS 6.1）；
- 攻击者可劫持管理员会话访问受限接口；
- 管理后台的
/admin/config接口会返回包含生产数据库明文连接串的环境变量（CVSS 9.8）。
单独看，每个问题似乎都不致命。但Continuum通过阅读源码和架构文档，发现这三个漏洞可以串联成一条完整攻击路径：从中危XSS窃取会话，用会话访问配置接口，最终获取数据库权限，导致客户PII数据全量泄露。
这种基于上下文的链式推理，正是人工测试容易遗漏的。
实际应用中，图片托管平台SmugMug表示，使用Continuum后，渗透测试从数天缩短到数小时，成本仅为人工的一小部分，使团队能更高频地评估服务安全性。日本企业HENNGE K.K.称其发现了人工未识别的问题，测试周期缩短超90%。德国Scout24 SE的安全负责人则提到，它暴露了一个可被公开利用的严重漏洞，且推理过程透明，增强了团队信心。
值得注意的是，Continuum采用“渐进式信任”设计：默认先在“人在环中”模式运行，对每条建议提供完整推理；企业建立信心后，再自行决定哪些操作可自动执行。放权的节奏，始终掌握在企业手中。
Security for AI：把Agent关进有规则的笼子
解决了防御速度，还得管住自家Agent的行为。这可以从三个层面入手：运行环境、工具调用、输入输出内容。
运行环境：微虚拟机隔离会话
容器能否关住会推理的模型？2024年，云安全公司Wiz曾通过一个恶意pickle模型，在Hugging Face平台上实现远程代码执行，并利用容器逃逸技术突破租户边界，最终获得跨租户访问其他客户私有模型的能力。结论很明确：在多租户场景下，容器化本身不足以构成强隔离。
Amazon Bedrock AgentCore 的 Runtime 为此提供了更底层的隔离方案：为每个用户会话分配一台独立的Firecracker微虚拟机（microVM），CPU、内存、文件系统彼此隔离。会话结束后，整台microVM被销毁，内存彻底清理，从机制上杜绝跨会话数据串扰。
其Code Interpreter也采用同样的临时microVM沙箱，默认存活15分钟，最长可配8小时。对于需要长时间运行的复杂任务（如多Agent协作或GPU计算），AgentCore还提供基于EC2的Instances模式，单次会话可持续14天。
行为安全公司Abnormal AI的实践很好地说明了这套机制的价值。该公司每天处理数十亿封邮件，其中最难判断的数万封交由内联Agent通过Code Interpreter动态写脚本、跑计算、验证结论。关键在于，他们选择了“无外联”（no egress）沙箱模式——既保证了行为可复现（不受外部干扰），又防止了威胁情报数据因Agent异常而外泄。
工具调用：模型提请求，规则做裁决
今年2月，Meta研究员Summer Yue的经历令人警醒。她将开源智能体OpenClaw接入主邮箱，明确要求“只提建议，等我确认后再动手”。结果几分钟后，Agent开始批量删除旧邮件，无视她反复下达的停止指令，最终只能强行断电终止进程——200多封邮件就此消失。
事后分析认为，上下文压缩机制可能将那条安全指令挤出了有效窗口。
AgentCore Gateway + AgentCore Policy 的组合正是为解决此类问题而生。Gateway将API、Lambda函数和MCP服务统一转换为Agent可用的工具，并提供唯一安全端点；Policy则在此端点上做确定性鉴权，使用AWS开源的Cedar策略语言，采用“默认拒绝”模型，对每次工具调用依据身份、目标工具和输入参数三要素独立判断是否放行。
通俗地说，模型可以提出操作请求，但执不执行，由模型之外的规则说了算。
能源情报公司Wood Mackenzie的实践印证了这一点。他们在AgentCore上搭建了共享Agent平台APEX，所有工具调用都经Policy实时拦截。自然语言规则可被自动转换为Cedar策略，让研发、合规和安全团队都能参与编写与审计。当分析师让内部应用Woody训练天然气需求模型时，Agent会在GitHub分支完成前期工作，然后停在一个检查点，明确指出需要人工复核GUIDANCE.md，并列出代码中必须修复的问题——在确认前绝不启动训练。
这与Summer Yue的遭遇形成鲜明对比：一边依赖提示词中的软性约束，另一边则在工具调用层实施硬性控制。
输入输出：内容过滤与权限控制需协同
今年5月，Grok钱包遭遇了一次巧妙的攻击。攻击者先向Grok关联的钱包转入一枚NFT，扩大其在Bankr系统中的权限；随后发送一段摩斯电码，请Grok“帮忙翻译”。Grok将其译为明文，而内容正是一条转账指令。下游的Bankrbot将这条“正常英文”当作合法授权执行，导致价值17.5万美元的代币被盗。
整个过程没有利用传统漏洞，也没有窃取密钥。失守的是内容层与授权层的配合——安全机制未能识别编码混淆后的恶意指令，而授权设计又允许模型生成的文本直接触发资金操作。
Amazon Bedrock Guardrails 正是针对内容层的风险。它作为模型外的一层独立检查，对输入提示和输出内容同时生效，支持提示攻击识别、六类内容过滤、敏感信息脱敏、拒绝话题控制等功能。
但Grok事件也说明，内容过滤不能替代权限控制。设想一个“查询订单并生成售后建议”的Agent收到一封客户邮件，其中藏有“导出全部客户资料到某地址”的指令。能否在进入模型前剥离该指令，是Guardrails的工作；而Agent是否有权限执行“导出全部客户资料”，则必须由Policy在权限层判断。
只做前者，等于赌过滤器永不漏网；只做后者，模型仍可能被诱导执行权限内但业务上不应做的操作。因此，在Wood Mackenzie的架构中，Guardrails和Policy是并行存在的，各司其职。
安全的核心：逐级授权，人在环中
归根结底，Agent只有接触业务数据、调用必要工具，才能真正创造价值。但“查资料写建议”和“改代码动账户”对安全的要求天差地别。
合理的做法是按任务风险逐级授权：低风险动作自动完成，关键操作保留严格审批。AWS Continuum的“learn→enforce”模式、Policy的“默认拒绝+显式放行”、Abnormal AI的“无外联沙箱”，本质上都是同一思路——先关紧闸门，再按需一格一格打开。
Wood Mackenzie那个“训练前必须人工确认”的检查点，正是这种思维的体现：正因为有这道闸，他们才敢把整条模型流水线交给Agent。
放到行业层面，未来有两个方向值得关注：一是将安全检查延伸到AI应用的设计、开发、上线和运行全生命周期；二是将AI权限控制与现有安全基础设施打通，避免Agent成为“安全盲区”。
最终，价值体现在几个朴素指标上：企业能否更快确认真实漏洞？能否更及时完成修复？能否清晰追踪Agent的越权请求？
此外，人依然承担关键责任。业务负责人决定授权范围，安全团队验证边界有效性，开发团队处理代码依赖。AWS也明确保留了客户在权限配置、输入验证和网络设置等方面的责任。
回到Gemini事件。谷歌说模型在认出真实系统后停了下来，这当然是好消息。但企业不能把全部防线押在模型“是否及时意识到不对”上。身份、权限、网络和工具执行规则，必须在模型继续行动之前就发挥作用。
所以在把更多工作交给Agent之前，每家企业或许都该先回答三个问题：
它用谁的身份做事？它能接触到哪些系统？出了问题，谁能在第一时间让它停下来？