使用Azure容器应用程序沙盒安全运行不受信任的AI智能体代码

微软 宣布 "Azure Container Apps Sandboxes发布公开预览版。这个新的ARM资源类型Microsoft.App/SandboxGroups能够在硬件隔离环境中运行智能体生成的非信任代码。每个沙箱可在不到一秒的时间内从OCI磁盘镜像启动，支持瞬时扩展到数千个实例，而且在空闲时不计费，这种计费模型契合智能体（agentic）工作负载常见的短时突发任务。 风险并不是只存在在理论上。当LLM生成代码并由智能体在宿主进程内执行时，执行面就成为了攻击面。看似安全的Python规划器（比如，抓取远程URL、读取环境变量或使用 exec()）实际上可能仅凭标准库就能窃取API密钥或加载任意负载。如果智能体生成的代码与宿主环境之间没有严格的边界，任何足够强大的模型都可能因一次提示词注入而导致严重的后果。构建多租户平台、CI/CD自动化或基于LLM的代码解释器的团队通常需要自定义的隔离方案，常见做法包括配置有限seccomp profile的容器运行时或使用带有Kata Containers的专用Kubernetes集群，但这些方案需要持续的运维投入。 每个沙箱都在独立的microVM中运行，与宿主、平台以及同一基础设施上的其它沙箱相互隔离。开发者可以使用任何兼容OCI的容器镜像。沙箱从预热池（pre-warmed）中处理资源配置，确保多租户隔离并管理从启动到拆除的整个生命周期。资源模型将沙箱分组为Sandbox Group，这些Group会作为一组沙箱的管理和配置边界，类似于Container Apps Environments，但它是针对短时工作负载而设计的。每个Sandbox Group包含对组内所有沙箱生效的共享设置，包括网络出口策略、托管标识分配、生命周期规则和资源等级。 该隔离模型伴随着关键的生产级运维能力。基于快照的挂起与恢复可在会话期间保留完整内存和磁盘状态，这意味着智能体可以暂停多步骤的调查或已安装依赖的软件开发环境，将其缩到零副本后稍后进行恢复，而无需重新初始化。 网络出口默认是拒绝的，出站流量仅允许到显式配置允许的主机，由沙箱内部的代理层在网络边界强制执行。沙箱同时支持系统分配与用户分配的Entra托管标识，这使得沙箱可在不将凭据写入镜像或通过环境变量传递秘密信息的情况下对Azure服务进行身份验证。 微软发布了一个 智能体治理工具集（Agent Governance Toolkit） "。该工具集通过agt-sandbox Python包与ACA Sandboxes协作，它新增了两层强制机制，也就是AST扫描和工具白名单。 这些策略会在代码片段运行前生效，而出口白名单在沙箱内的网络边界执行。两者独立运作，被拒绝的调用永远到不了执行环境，同时，如果尝试向未在白名单中的主机发起出站请求，代理层就会直接失败，而与进程内的策略无关。 公告中明确列出了使用该隔离基础设施的产品，包括 GitHub Copilot的Cloud Sandboxes "、 Foundry Hosted Agents "以及 Azure Container Apps Express "。这对架构设计很重要，微软并非提供一个新的基于信任的抽象层，而是开放了其自身用于开发者产品的同一个隔离层。 ACA Sandboxes的发布使其加入了一个竞争激烈的市场。2026年4月， Cloudflare " 推出了其Sandboxes产品，提供带有按需CPU计费和基于快照进行会话恢复的持久化隔离Linux环境，目标用户为已使用Cloudflare Workers的团队。 E2B "是基于Firecracker microVM的专用沙箱平台，已经在许多财富500强公司中获得采用，声称冷启动时间低于200ms，并为需要数据驻留的团队提供“自带云”（BYOC，Bring Your Own Cloud）方案。 Fly.io "于2026年1月推出了 Sprites "，该产品默认提供持久化模型，基于Firecracker microVM并配备100GB NVMe存储，它对短暂（ephemeral）运行的方式提出了质疑，认为重建状态会浪费延迟。 ACA Sandboxes的差异点在于其原生的Azure集成，而不仅仅是沙箱性能。使用Azure的团队可以通过现有工具访问Entra标识服务、ARM原生资源管理和出口控制，受益于支撑GitHub Copilot的相同基础设施，它无需自行管理编排层。对于不在Azure上的团队，或需要GPU密集型的工作负载、愿意采用BYOC方案或偏好开源隔离工具的团队，专用提供商仍能提供更高的灵活性。 查看英文原文： Run Untrusted AI Agent Code Safely with Azure Container Apps Sandboxes "