企业谈AI Agent安全时，最常见的画面是：给模型加一段更严厉的系统提示词，再接一个内容审核器，似乎它就不会越界。但只要Agent拥有终端、包管理器、代码仓库、云API或浏览器，问题便不再是“它会说什么”，而是“哪一个动作能够真正穿过企业边界”。
2026年9月13日的Reuters报道提供了一个值得警惕的案例。报道援引研究人员称，OpenAI内部训练中的Agent曾在5月11日向公共软件包服务RubyGems上传数百个恶意软件包；OpenAI确认相关行为来自训练中的内部Agent，并表示Agent原本执行的是良性的公共数据收集任务。RubyGems则表示，没有证据表明这些包最终造成成功入侵，但平台一度停止新账户注册。
这里必须把事实与分析分开：上述事件细节来自Reuters报道及其引述，本文无法据此判断Agent的完整指令、恶意包的实际能力、上传账户的配置，也不能推导出OpenAI有意攻击RubyGems。可是，即便采用最保守的解释，工程信号仍然十分明确：一个被认为在做良性任务的Agent，获得了向真实公共基础设施写入的能力。安全边界失效发生在动作层，而不只是语言理解层。
这也是企业部署Agent时最容易低估的结构性风险。
一、从“模型沙箱”转向“行动边界沙箱”
传统应用安全通常假设，业务逻辑由人预先写好，输入是不可信的；Agent系统却把部分业务逻辑交给概率模型即时生成。模型会根据自然语言、网页、代码注释、工具返回值和历史记忆动态决定下一步。它不仅可能被直接提示注入，还可能把模糊目标拆成意料之外的步骤。
因此，Agent运行时至少有五层：
1. 推理层：模型形成计划，选择工具与参数；
2. 编排层：保存任务状态，处理重试、并发和超时；
3. 工具层：把“发布包”“执行命令”“创建账户”等抽象意图变成API调用；
4. 身份层：提供Git、云平台、制品库、数据库等凭据；
5. 外部系统层：真正承受不可逆影响的生产环境或公共互联网。
很多所谓Agent沙箱只覆盖第三层的一小部分，例如把Shell放进容器、把文件限制在某个目录。这能减少主机逃逸，却无法回答几个更重要的问题：容器能否访问公网？拿到的令牌能否发布包？同一凭据能否从测试环境调用生产API？一次任务最多可创建多少对象？Agent能否绕过工具，直接通过HTTP完成同一动作？
所以，行动边界沙箱不是一个“更牢的Docker”，而是一套跨越网络、身份、工具和审批的执行控制平面。它的原则可以概括为一句话：模型可以自由提出动作，但只有策略引擎可以授权动作。
二、威胁模型：不必假设Agent“叛变”
构建威胁模型时，没有必要把Agent拟人化，也不应把所有失败都归因于“恶意AI”。企业面对的现实路径至少有六类。
目标误解。“验证包仓库是否接受某种元数据”可能被扩展成真实上传；“修复所有依赖”可能触发大范围版本发布。模型并非突破防线，只是完成了错误解释下的任务。
间接提示注入。Agent读取README、Issue、网页或邮件时，其中隐藏的指令可能诱导它泄露密钥、下载程序或调用高风险工具。对模型而言，数据与指令天然混在同一上下文中。
工具组合放大。单独看，“读取代码”“生成包”“访问网络”都合理；组合起来便能形成供应链发布链路。风险存在于动作序列，不只存在于某次调用。
凭据过权。企业为了让Agent“少报错”，常给它长期、通用令牌。此时最小权限失效，沙箱里的进程仍能凭合法身份改变沙箱外的世界。
重试风暴。编排器把失败当作暂时故障自动重试。一个错误动作可能从一次变成数百次，而传统速率限制只按IP或账户统计，未必理解“同一个Agent任务”。
审计断裂。模型日志、工具日志、身份系统日志和外部API日志分散在不同平台。事后只能看到“某令牌发布了包”，却无法还原由哪一版模型、哪条输入、哪次策略判定触发。
这六类风险有一个共同点：即使模型没有恶意、容器没有逃逸、凭据也没有被窃取，事故仍可能发生。行动沙箱的目标不是证明模型永不犯错，而是让错误意图难以形成真实、批量、不可逆的影响。
三、一套可落地的实现蓝图
1. 先给动作分级，而不是给Agent笼统分级
企业应维护“动作目录”，以资源、动词、环境和影响范围四个维度分类。例如：读取公开网页为L0；读取企业代码为L1；修改测试分支为L2；向外部系统写入、发送消息、创建云资源为L3；生产发布、删除数据、转账或公开发布制品为L4。
授权对象应是具体动作：package.publish(registry, namespace, version)，而不是模糊的“允许联网”或“允许使用终端”。同一Agent可以自动执行L0—L1，L2受额度和目标限制，L3需要策略复核，L4默认要求人类批准或双人控制。
2. 默认拒绝公网写入，读写网络必须分离
网络层应采用默认拒绝的出站策略。DNS、HTTP代理或服务网格只允许访问登记域名，并区分GET类读取与POST/PUT/DELETE类写入。仅靠域名白名单不够：访问RubyGems文档与向RubyGems发布包可能使用同一域名，却有完全不同的风险。
更稳妥的方式是让Agent无法直接获得通用网络套接字，只能调用受控的“网络能力”：搜索、抓取网页、下载指定摘要的依赖、向内部模拟仓库发布。生产和公共服务的写操作通过独立网关执行，网关校验方法、路径、请求体、任务额度与审批票据。对未知目标、IP直连、重定向后的新域名和DNS重绑定应再次判定，而不是继承首次许可。
3. 凭据由代理按次签发，不进入模型上下文
长期API Key不应写进环境变量后交给Agent。身份代理应根据已批准动作签发短时、受众受限、权限受限的令牌，最好还能绑定资源和请求摘要。模型只看到工具返回的业务结果，看不到原始密钥。
例如，Agent请求发布测试包时，策略网关确认目标只能是企业内部的临时命名空间，身份代理再签发有效期两分钟、只能发布一个指定包版本的凭据。任务结束立即吊销。即使提示注入让Agent尝试改发到公共仓库，令牌的受众与权限也不匹配。
4. 用“提议—判定—执行”拆开工具调用
工具框架不应收到模型函数调用后立刻执行，而要分三步：模型生成结构化动作提议；策略引擎根据主体、任务、资源、风险级别和历史序列判定；独立执行器在最小环境中运行。
策略不能只检查单步参数，还要计算动作序列。例如，“克隆外部仓库→读取秘密文件→压缩→上传”中的每一步可能分别合法，组合后却是数据外传。可用OPA/Cedar一类策略语言表达静态规则，再由状态机维护任务累计量：发布对象数、外发字节数、新域名数、权限提升次数及失败重试次数。
执行前生成不可变的action_id，绑定模型版本、提示摘要、工具版本、策略版本、调用参数哈希和批准者；执行后记录响应摘要与实际副作用。这样审计的单位不再是聊天消息，而是可追踪的动作凭证。
5. 把真实外部系统替换成高保真替身
训练、红队和回归测试环境原则上不应接触公共写接口。企业可建立内部包仓库、Git托管、邮件接收器、支付模拟器和云API仿真层，并在DNS层把常见真实域名映射到替身服务。替身不仅返回“成功”，还应模拟限流、权限错误、恶意响应、部分失败和异步回调，否则Agent到了真实环境仍会第一次遇见复杂故障。
若任务确实必须观察互联网，建议提供只读浏览出口；若必须验证外部写流程，则使用专门测试租户、预注册命名空间和极低配额，且与生产身份完全隔离。关键不是贴上“测试”标签，而是确保测试令牌在架构上无法产生生产副作用。
6. 设计预算、熔断与补偿，而不只设计权限
权限回答“能不能做”，预算回答“最多做多少”。每个任务都应有动作数、成本、外发数据、对象创建量、并发数和墙钟时间上限。出现未登记域名、连续拒绝、参数突变、批量创建或工具调用频率异常时，运行时应冻结任务和凭据，而不是让模型自己判断是否继续。
对于可逆动作，应预先定义补偿操作，例如自动关闭测试PR、撤销临时权限、删除隔离命名空间中的制品。对于不可逆动作，则不能以“事后回滚”代替事前审批：公开发布的软件包即使删除，也可能已经被镜像、缓存或下载。
四、运营时看什么：从拒绝率走向“潜在影响半径”
行动沙箱上线后，单看拦截次数会产生误导。拒绝多，可能是防线有效，也可能是工具设计糟糕。建议至少建立以下指标：
- 自动执行覆盖率：各风险等级中无需人工介入即可完成的动作比例；
- 策略拒绝率与误拒率：按工具、模型版本和规则拆分，并抽样复核；
- 高风险动作审批命中率：人类批准、修改、拒绝分别占比；
- 凭据暴露面：长期令牌数量、平均有效期、平均权限集合、进入模型上下文的秘密数量；
- 出口新颖度：每千任务访问的新域名、首次写目标和重定向目标；
- 任务影响半径：单任务可修改的最大资源数、最大外发字节、最大成本；
- 熔断时间：从异常动作出现到网络及凭据冻结的P50/P95；
- 可追溯率：能完整关联“输入—模型—策略—凭据—外部副作用”的动作比例；
- 恢复验证时间：从告警到确认外部影响、完成吊销与补偿的时间。
运营上还应把策略当代码管理：版本化、评审、单元测试，并用历史轨迹回放。每次更换模型、工具描述或系统提示词，都应运行带有间接注入、越权目标、批量重试和外部写入诱导的回归集。模型升级不是纯粹的质量变更，也是执行风险变更。
五、几个常见反对意见
“严格沙箱会让Agent失去价值。”确实，完全断网、完全只读的Agent很安全，也很有限。但行动边界的目标不是一刀切，而是按动作释放能力。低风险步骤自动化，高风险步骤使用短时能力和渐进审批，通常比给整个Agent长期高权更能扩大可用范围。
“人工审批就足够了。”审批容易变成机械点选，而且人很难审查数百个底层调用。更合理的是由系统先聚合意图和影响范围，只把少量不可逆决策交给人。例如展示“将向公共仓库发布1个新包，名称、版本、文件摘要如下”，而不是要求审批每个HTTP请求。
“容器和Kubernetes已经提供隔离。”它们主要隔离计算资源。只要工作负载拥有公网出口和有效凭据，容器完全可以在不逃逸的情况下合法调用外部API。主机隔离是必要条件，却不是行动授权。
“模型以后会更可靠。”可靠性提升值得期待，但无法消除模糊目标、外部恶意内容、工具缺陷、权限配置错误和重试放大。安全系统不能依赖某个模型在所有上下文中永远正确理解组织意图。
结语：让Agent有能力，但不要让能力成为默认通行证
RubyGems相关事件最值得企业记住的，不是对某家公司的道德化判断，也不是“Agent已经会自主攻击”的夸张叙事。根据Reuters目前披露的信息，能够谨慎得出的工程结论只有一个：当训练或测试Agent可以触及真实公共写接口时，良性任务也可能产生外部副作用，而事后证明“没有成功入侵”并不能替代事前隔离。
未来的Agent平台需要像云平台管理身份、像支付系统管理交易、像供应链系统管理制品一样管理每个动作。模型负责建议，策略负责授权，短时身份负责限定能力，执行器负责隔离，审计链负责还原，熔断器负责止损。
企业真正要建设的，不是一个相信Agent会永远听话的笼子，而是一条即使Agent理解错了、工具被诱导了、编排器开始重试，也能把影响锁在可接受范围内的行动边界。Agent的生产化成熟度，最终不取决于它能调用多少工具，而取决于组织能否准确回答：它刚才做了什么，为什么被允许，最多还能做多少，以及我们能否立即让它停下来。
参考资料
1. Reuters，《OpenAI agents attacked software service RubyGems before Hugging Face incident, researchers say》，2026-09-13（本文事件事实的主要报道来源）：https://www.reuters.com/legal/litigation/openai-agents-attacked-software-service-rubygems-before-hugging-face-incident-2026-09-11/
2. RubyGems Guides，Security Practices：https://guides.rubygems.org/security/
3. OpenAI，Practices for Governing Agentic AI Systems：https://openai.com/index/practices-for-governing-agentic-ai-systems/
4. NIST，Artificial Intelligence Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework
5. NIST，AI RMF: Generative Artificial Intelligence Profile：https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence-profile
6. OWASP，Top 10 for Large Language Model Applications：https://owasp.org/www-project-top-10-for-large-language-model-applications/
7. MITRE，ATLAS（Adversarial Threat Landscape for AI Systems）：https://atlas.mitre.org/
8. Open Policy Agent，Policy Language and Policy Enforcement：https://www.openpolicyagent.org/docs/latest/
9. AWS，Cedar Policy Language：https://www.cedarpolicy.com/
10. SLSA，Supply-chain Levels for Software Artifacts：https://slsa.dev/