阿里云博客演示把 AI（人工智能） Agent 沙箱出口收敛到单一 AI 网关，并发现 DNS 仍可外泄
阿里云博客给出的一套配置把 AI（人工智能） Agent（人工智能智能体）沙箱的网络出口收缩为只剩 AI Gateway（AI 网关）：沙箱子网不配公网路由，安全组仅放行到网关的 443 端口，真实模型密钥只存网关。
作者用同一段测试代码在默认与锁定两种沙箱模板中运行，锁定模板中的外发请求、直连模型 API（应用程序编程接口） 和假密钥外传均超时失败，经网关调用模型正常完成；
但沙箱仍可借 VPC DNS 把数据带出，需删除 DNS 放行规则。
作者在新加坡（ap-southeast-1）同一 VPC 内自建环境演示，非第三方测评。 锁定模板中，访问 example.com、直连 dashscope-intl.aliyuncs.com、向外部 webhook 发送假密钥均以 curl 退出码 28 超时；
同一代码在默认 PUBLIC 模板中分别返回 HTTP 200、HTTP 400 和 POST 200。 经网关调用 qwen-flash 在锁定模板返回 HTTP 200。 两个沙箱环境变量只含网关地址、网关消费者密钥和名为 CANARY_SECRET 的假值，Model Studio API（应用程序编程接口） key 未放入沙箱。
网关侧：无消费者密钥调用返回 HTTP 401，DAN 式越狱提示被拦截并标记 promptAttack 等级 high，配额 500 tokens/天在第 5 次调用返回 HTTP 429。
DNS 测试中，删除安全组的 53 端口规则前，经 VPC DNS 解析 canary-not-a-real-key-001.example.com 由外部权威域名服务器应答； 删除后名称解析失败。 作者说明未复现注入本身，而是假设注入已成功后直接执行相应代码。
价值不在某个产品功能，而在暴露一个常见盲区：AI（人工智能） Agent 的工具调用 Hook（钩子）只能看到工具调用，看不到沙箱内代码发出的普通网络流量。 把密钥下沉到网关、用路由表而非安全组断网，使“即使注入成功，可窃取的也只是仅能在网关使用的消费者密钥”成为可验证的配置后果。
但作者自测同时显示，DNS 查询是独立于 HTTP 的隐蔽通道，VPC DNS 会代沙箱向外解析。 对评测与部署 Agent 的团队，安全清单需同时覆盖网络层与名称解析层。 结论来自单一作者环境演示，未经独立复现。
后续观察信号
- 阿里云是否公布该配置的模板或文档，供他人复现锁定沙箱
- DNS 封锁后改按 IP 调用网关的方案在大规模部署中的运维代价