Azure Container Apps 沙箱：企业级 AI Agent 代码安全执行方案

Microsoft 发布了 Azure Container Apps 沙箱（正式名称为 Dynamic Sessions），这是一个专为安全运行不信任代码而设计的基础设施级沙箱解决方案。它直接回应了企业 AI 落地中最棘手的安全难题——如何安全地执行 AI Agent 生成的代码。

背景：AI Agent 的安全困境

随着 AI Agent 越来越普及，Agent 生成代码并自主执行已经不再是实验场景：

• Agent 写 Python 脚本分析数据
• Agent 调用 Shell 命令部署服务
• Agent 执行用户提供的自定义插件

这些操作如果直接在宿主机上运行，后果可能是灾难性的——数据泄露、系统破坏、资源滥用。传统的容器隔离对于不信任代码场景来说还不够：容器共享宿主机内核，存在逃逸风险。

什么是 Azure Container Apps 沙箱

Azure Container Apps 沙箱（Dynamic Sessions）提供按需分配的临时沙箱环境，核心设计特点：

两种沙箱模式

沙箱提供两种模式，满足不同场景需求：

1. 代码解释器会话池（Code Interpreter Session Pool）

开箱即用型，无需自定义容器镜像：

• 预配置了常见运行时和工具
• 通过 REST API 直接交互
• 适合快速集成到 AI Agent 工作流
• 典型用途：执行 AI 生成的脚本、教育沙箱、临时代码运行

2. 自定义容器会话池（Custom Container Session Pool）

完全可控型，自带容器镜像：

• 可安装任意依赖、运行时、二进制工具
• 完整的 Hyper-V 隔离
• 支持自定义健康检查探针（Liveness / Startup）
• 适合私有环境、专有解释器、特殊工具链

核心架构：会话池（Session Pool）

沙箱的基础是会话池体系：

1. 预预热：池中始终保持一定数量的”待分配”沙箱实例
2. 分配：应用请求携带 identifier 参数，池自动分配或复用会话
3. 路由：请求路径自动转发到会话内的容器端口
4. 冷却销毁：无活动请求超过冷却期后，自动销毁并回收资源

应用 → 会话池管理端点 → 分配会话（从预预热池） → 转发请求到容器 → 冷却→销毁

交互示例：

import requests

pool_endpoint = "https://<POOL_NAME>.<ENV_ID>.<REGION>.azurecontainerapps.io"
response = requests.post(
    f"{pool_endpoint}/<API_PATH>?identifier=user-123",
    headers={"Authorization": "Bearer <TOKEN>"},
    json={"command": "import pandas; print(pandas.__version__)"}
)
print(response.text)

安全机制详解

Hyper-V 隔离

每个沙箱运行在独立的 Hyper-V 虚拟机中，而非单纯共享内核的容器。这意味着：

• 沙箱之间：互不可见，各自拥有完整的内核和内存空间
• 沙箱与宿主机：虚拟机边界隔离，容器逃逸攻击无效
• L1TF / Spectre 类侧信道攻击：Hyper-V 的硬件虚拟化边界天然防御

网络策略

沙箱组（Sandbox Group）可以配置出站网络策略：

• 完全禁止出站（Air-gapped）
• 白名单模式（仅允许特定域名/IP）
• 受控出站（通过代理）

这对于防止 Agent 被注入后外泄数据至关重要。

托管身份（Managed Identity）

每个沙箱组可以分配 Azure 托管身份，让沙箱内的 Agent 在不持久化任何密钥的情况下访问 Azure 资源（如存储、数据库）：

• 无硬编码凭据
• 身份仅对沙箱组有效
• 冷却销毁后身份无法复用

资源配额

每个沙箱有严格的 CPU/内存上限，防止恶意代码或问题代码消耗集群资源。

典型使用场景

场景一：AI Agent 代码解释器

Agent 生成数据分析代码后，直接发给沙箱执行：

Agent → 生成 Python 脚本 → Dynamic Session → 返回结果

沙箱返回结果给 Agent 进行下一轮推理，全程不碰宿主环境。

场景二：多租户插件执行

SaaS 平台允许用户上传自定义脚本或插件：

用户提交插件 → 平台 → 每个用户一个独立沙箱 → 执行 → 返回结果

即使某个用户提交了恶意代码，也只会影响到他自己的沙箱。

场景三：交互式开发环境

为开发者提供临时的测试环境，用完即销毁：

开发者提交代码 → 沙箱分配 → 运行测试 → 结果反馈 → 自动销毁

行业影响

Azure Container Apps 沙箱的发布，标志着 “Agent 隔离”正式成为云安全基础设施的标配组件。在此之前，企业运行 AI Agent 代码的常见做法包括：

• 本地 Docker 容器：需要自行管理镜像、网络、安全补丁
• VM 虚拟机：启动慢、资源浪费、管理成本高
• 第三方沙箱服务：数据合规性、供应商锁定风险

Azure 将其作为 Container Apps 的原生能力提供，意味着：

1. 降低门槛：AI Agent 开发者无需自己搭建沙箱设施
2. 深度集成：与 Azure AD、托管身份、网络策略等企业基础设施无缝对接
3. 按需付费：按 vCPU 秒计费，沙箱空置自动销毁，没有闲置成本

如何开始

在 Azure Portal 中创建会话池：

1. 进入 Azure Container Apps 服务
2. 选择 Session Pools → Create
3. 选择类型（Code Interpreter 或 Custom Container）
4. 配置预预热实例数、冷却时间、网络策略
5. 获取管理端点 URL，集成到应用中

支持的区域覆盖全球主要地区，包括 East US、West Europe、Southeast Asia 等。

补充说明：除了 Azure，2026 年涌现了大量沙箱方案——Modal 基于 gVisor、E2B 和 Blaxel 基于 Firecracker microVM、Daytona 和 Cloudflare 也各自推出了 sandbox 产品。Azure 的优势在于与企业身份体系（Entra ID）、网络策略、合规认证的原生集成，让沙箱不是孤立的产品，而是企业安全体系的一环。

参考资料：

• Microsoft Learn: Dynamic Sessions in Azure Container Apps
• Microsoft Learn: Custom Container Sessions
• Azure Container Apps 产品页