AI Agent Network Egress 完整治理：为什么 Sandbox 不能只隔离文件和 Shell

摘要： AI Agent 的 Sandbox 若只隔离文件系统和 Shell，仍可能通过浏览器、HTTP 工具、MCP Server、软件包管理器或云元数据服务，把敏感数据带出边界，甚至调用真实生产系统。完整的 Network Egress 治理不是简单“封网”，而是把目的地、协议、身份、数据、动作、额度和审计统一成可执行策略。本文给出一套从默认拒绝、受控 DNS、L7 出口代理，到工具网关、最小权限身份、人工审批与回滚的落地方案，并附 Kubernetes 与 Docker 示例。

核心结论

• 文件隔离与 Shell 隔离只保护本地主机；只要 Agent 还能发起网络请求，它就可能读取云元数据、调用 SaaS、触发生产 API 或外传上下文。
• 安全基线应是“默认拒绝所有出站”，只允许任务明确需要的 DNS、模型端点、工具网关和业务 API；允许项必须同时约束身份、方法、数据量与有效期。
• Kubernetes NetworkPolicy 和云防火墙主要治理 L3/L4，无法理解 URL 路径、HTTP 方法、请求正文和业务动作，因此必须叠加 L7 Egress Proxy 与 Tool/MCP Gateway。
• DNS、重定向、IPv6、WebSocket、DoH、云元数据地址和动态域名都是常见绕过面；只做域名白名单远远不够。
• 真正可运营的方案必须包含可归因审计、成本与速率预算、失败重试边界、敏感动作审批、紧急熔断和可验证回滚。

为什么“不能写文件、不能执行 Shell”仍然不安全

很多团队把 Sandbox 理解成容器、只读文件系统、禁用 exec，然后认为 Agent 已被关进笼子。这个模型遗漏了一个事实：现代 Agent 的主要能力并不只来自本地命令，而来自网络。

一个没有 Shell 的 Agent，仍可能拥有浏览器、fetch、数据库连接器、MCP 工具、邮件工具、工单系统、对象存储 SDK 或模型 API。提示注入只需诱导它把当前上下文编码进查询参数、表单、图片 URL 或 DNS 请求，就可能完成外传。若工具背后绑定的是长期令牌，Agent 还可能创建账号、改 IAM、发邮件、删除云资源或向生产环境写数据。

因此，Sandbox 的边界必须从“进程能碰什么”扩展为“身份可以经由哪些网络路径，对哪个系统执行什么动作，并携带多少数据”。这也是 AI Agent 安全 与 MCP 权限治理 应放在同一控制面的原因。

风险通道	只隔离文件/Shell是否能阻止	典型后果	需要的控制
HTTP/HTTPS 工具	否	数据外传、生产写入	显式代理、域名与方法策略、DLP
DNS/DoH	否	小块数据隐蔽外传	固定解析器、阻断外部 DNS/DoH、查询审计
云元数据服务	否	获得临时云凭证	阻断链路本地地址、工作负载身份、IMDSv2
MCP/浏览器会话	否	借已登录身份操作 SaaS	工具网关、动作级权限、人工确认
包管理器与安装脚本	部分	下载并执行恶意依赖	内部镜像、锁文件、签名与禁网构建
WebSocket/流式连接	否	长连接外传、绕过逐请求审计	代理协议限制、字节/时长预算

完整治理模型：六个维度同时收紧

只维护一份“允许访问的域名列表”会产生虚假的安全感。完整策略至少要回答六个问题：谁发起、为何发起、去哪里、用什么协议、携带什么数据、允许产生什么副作用。

1. 主体与身份：每个 Agent、任务和运行实例使用独立短期身份，不共享长期 API Key。
2. 目的地：允许确切服务、端口和环境；生产、测试、第三方 SaaS 分开建策略。
3. 协议与动作：约束 HTTP 方法、URL 路径、MCP Tool 名称和数据库操作类型。
4. 数据边界：限制请求正文、附件类型、单次与累计字节数，对密钥、个人信息和源代码做检测。
5. 时间与额度：授权带 TTL、调用次数、并发、带宽和费用上限。
6. 证据与处置：记录决策依据、审批人、请求摘要、响应类别；支持熔断、撤销身份和重放调查。

这六个维度需要分层执行。网络层负责“无路可走”，代理层负责“不能随便说话”，工具层负责“不能随便做事”，身份层负责“即使到达也无权越界”。任何单层失效，都不应直接变成生产事故。

推荐架构：默认拒绝，唯一出口

最稳妥的拓扑是让 Agent 工作负载处于无默认互联网出口的私有网段：DNS 只能访问受控解析器；HTTP/HTTPS 只能连接 Egress Proxy；所有 MCP、浏览器自动化和企业 API 通过 Tool Gateway；网关再根据任务声明、短期身份和审批票据决定是否放行。

Kubernetes 可先建立 namespace 级默认拒绝。注意：NetworkPolicy 是否真正生效取决于集群网络插件；它只处理 IP/端口级规则，不能把 POST /payments 与 GET /docs 区分开。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-default-deny-egress
  namespace: agent-runners
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-allow-dns-and-egress-proxy
  namespace: agent-runners
spec:
  podSelector:
    matchLabels:
      role: agent
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels: {kubernetes.io/metadata.name: kube-system}
          podSelector:
            matchLabels: {k8s-app: kube-dns}
      ports:
        - {protocol: UDP, port: 53}
        - {protocol: TCP, port: 53}
    - to:
        - podSelector:
            matchLabels: {app: egress-proxy}
      ports:
        - {protocol: TCP, port: 8443}

不要把互联网服务不断变化的 IP 直接堆进 NetworkPolicy；让固定代理成为网络层唯一允许的目标，再由代理实施域名、SNI、证书、路径、方法和数据量策略。若 CNI 支持 FQDN 策略，也仍需防范 DNS 重绑定、CNAME 链、解析缓存差异与连接复用。

Docker/Compose 场景可把 Agent 放入 internal: true 的内部网络，只让双网卡代理同时加入内部网和受控出口网。生产环境还应在宿主机 DOCKER-USER 链或云防火墙加一道拒绝规则，防止容器配置被误改后直连外网。

services:
  agent:
    image: registry.example/agent@sha256:REPLACE_WITH_DIGEST
    networks: [agent_internal]
    environment:
      HTTPS_PROXY: http://egress-proxy:8080
      NO_PROXY: egress-proxy
    read_only: true
  egress-proxy:
    image: registry.example/egress-proxy@sha256:REPLACE_WITH_DIGEST
    networks: [agent_internal, controlled_egress]
networks:
  agent_internal:
    internal: true
  controlled_egress: {}

DNS、SSRF 与云元数据：最容易漏掉的三条路

第一，Agent 只能向组织控制的 DNS 解析器发请求。应拒绝直连外部 53/853 端口，限制已知 DoH 端点，并把 DNS 查询与任务 ID 关联。异常长标签、高熵子域、短周期大量 NXDOMAIN 都应告警。DNS 日志可能包含敏感域名，也需要最小访问权限和保留期限。

第二，出口代理必须在每次重定向后重新执行策略，不接受“首个 URL 合法即可”。解析得到的每个 A/AAAA 地址都要检查，拒绝环回、私网、链路本地、组播和保留地址；同时固定允许的端口与协议，避免 https://allowed.example 被重绑定到内部地址。

第三，显式阻断 169.254.169.254 等云元数据地址及对应 IPv6 路径。AWS 环境要求 IMDSv2 可降低 SSRF 风险，但不应把它当作唯一防线；GKE 优先采用 Workload Identity Federation，让 Pod 获得最小、可撤销的身份，而不是继承节点权限。所有云身份都应按任务签发短期凭证，禁止把静态密钥写入镜像、Prompt 或环境转储。

Tool Gateway：把“能联网”变成“只能完成声明过的动作”

对 Agent 而言，最危险的往往不是原始 TCP，而是语义丰富的工具。一个名为 send_email、deploy_prod 或 query_customer 的 MCP Tool，背后可能拥有远高于 Agent 容器的权限。

Tool Gateway 应接收结构化调用而不是任意 URL，并执行以下检查：工具是否在任务清单内；参数是否匹配 JSON Schema；目标租户与环境是否一致；是否含敏感字段；动作是否幂等；是否需要人工审批；当日成本与调用预算是否足够。生产写操作应使用一次性 capability token，绑定工具、资源、动作、额度、审批记录和短 TTL。

浏览器也应视为工具，而不是普通网页访问。隔离浏览器配置文件，禁止复用员工日常登录 Cookie；下载、上传、剪贴板、文件选择器、弹窗、WebRTC 和 WebSocket 分别设策略。对于必须登录的流程，使用专用服务账号和受控会话，并在提交、发送、购买、发布、授权等不可逆动作前暂停等待确认。

十步落地流程

1. 盘点真实流量：在不放宽权限的前提下观察现有 Agent 的 DNS、目标 IP、域名、端口、字节数、MCP 工具和失败重试。
2. 给任务分类：区分离线分析、联网只读、受控写入和生产高风险四档，禁止一个 Runner 混跑所有等级。
3. 建立默认拒绝：在 CNI、云防火墙和容器宿主机三处验证不存在旁路。
4. 固定 DNS 与唯一代理：Agent 只能连接组织解析器和出口代理；同步覆盖 IPv4、IPv6、UDP、TCP、DoH 与 DoT。
5. 阻断特殊地址：拒绝元数据、环回、私网、链路本地和管理平面地址，逐跳复查重定向与解析结果。
6. 按用途建允许项：模型推理、代码仓库、内部 API、包镜像分别建策略，设置所有者、理由和到期日。
7. 最小化身份：将节点身份换成工作负载身份，凭证短期化，读写身份分开，生产权限按任务提升。
8. 接入数据与动作审批：机密、个人信息、大附件、外发消息和生产变更进入 DLP 或人工审批。
9. 做对抗验证：测试 DNS 外传、重定向、IPv6、WebSocket、恶意 MCP 描述、包安装脚本和云元数据访问。
10. 小流量发布并演练回滚：先影子记录，再阻断低风险任务，最后扩大范围；预置撤销身份、停代理和切换只读模式的操作手册。

重试、超时、成本与可用性怎么平衡

严格出口策略会暴露系统过去隐藏的依赖，因此上线初期常见 DNS 超时、证书链失败、代理不支持流式协议和第三方域名漂移。不要用“临时允许所有 HTTPS”救火；应让失败可诊断：区分策略拒绝、解析失败、连接超时、TLS 失败、上游 4xx/5xx，并返回可关联的决策 ID。

所有网络工具设置连接超时、总超时、最大响应体和最大重定向次数。重试只针对明确的瞬时错误，采用指数退避与抖动；非幂等写操作需要 idempotency key，审批票据不得被无限重放。流式模型和 WebSocket 设置最长连接时间、空闲超时与累计字节预算。

成本不只来自代理实例。TLS 检查、日志存储、DLP 扫描、跨区流量和误拦截的人工处理都会增加总成本。可按风险分层：低敏公开文档仅记录目标与字节；内部数据增加内容分类；生产写入启用完整参数摘要、双人审批和短期凭证。日志避免保存完整 Prompt、密钥和响应正文，可存哈希、字段级脱敏摘要与受控取证副本。

审计、告警和事故处置

每次出站决策至少记录：agent_id、task_id、运行镜像摘要、调用工具、原始域名、解析 IP、协议与端口、HTTP 方法、策略版本、允许/拒绝原因、发送与接收字节、身份、审批票据、延迟、重试次数和成本估算。日志应写入 Agent 无法修改的远端系统，并与云审计、MCP 网关和业务 API 日志关联。

告警优先关注行为变化，而非单个拒绝：首次访问的新域名、短时域名爆发、上传量突增、工作时间外的生产写入、连续策略探测、异常 DNS 标签、元数据地址尝试和审批后参数变化。

发生疑似外传时，先暂停任务并撤销短期身份，再在代理层封禁目标，保存不可变审计证据，随后轮换可能暴露的凭证。回滚不等于重新开放互联网；安全降级应是切换到离线或只读工具集。恢复前用同一测试用例复现攻击路径，并证明网络层、代理层和工具层都能独立阻断。

策略本身也要纳入软件供应链管理。允许列表、代理规则和工具 Schema 应进入版本库，经过代码审查、静态检查和自动化测试后发布；生产策略使用签名制品，运行节点只接受受信签名。每次变更要生成差异：新增了哪些目的地、扩大了哪些方法、提高了多少字节或费用预算、哪些任务会受到影响。高风险放行必须自动过期，不能依赖负责人日后手工删除。

测试环境还应准备一个“受控恶意站点”，持续验证 Agent 是否会跟随跨域重定向、把系统提示放进 URL、解析私网地址或尝试访问元数据服务。对 MCP 工具，应注入带有诱导指令的工具描述和返回内容，确认模型无法绕过网关策略。红队结果要形成回归用例；否则模型、代理、CNI 或浏览器升级后，同一条旧漏洞可能悄悄重新出现。

可用性方面，建议为必要服务配置经过审核的备用端点，而不是通用直连旁路。代理故障时，高风险任务应“失败关闭”；只有经过风险评估的公开只读任务才可进入受限降级通道。熔断恢复需要双人复核策略版本、身份范围与待重放队列，防止积压的写请求在恢复瞬间集中执行。

验收清单：怎样证明它真的有效

验收不能只看一条“拒绝连接”的截图。测试团队应从容器内、Sidecar、同节点其他 Pod 和被攻陷的工具服务分别尝试绕行，并覆盖冷启动、扩缩容、节点迁移、代理升级和策略回滚等状态变化。对于每个允许的外部服务，还要验证最小正向用例确实成功，避免安全规则把业务逼向人工复制数据等更危险的影子流程。最终交付物应同时包含机器可执行测试、策略版本、预期日志和负责人签字，让后续审计能够重复同一结论。

上线后每季度重新核对目的地与业务所有者，删除无流量、无负责人或已到期的允许项。模型与工具版本升级前，先在隔离环境重放代表性任务，比较新增域名、请求体大小、调用方法和失败模式；任何超出基线的变化都应触发复核，而不是自动学习为新常态。

• Agent 直连公网 IP、IPv6 地址、外部 DNS、DoH 和任意 WebSocket 均失败。
• 允许域名重定向或 DNS 重绑定到私网/元数据地址时，请求被二次检查并阻断。
• NetworkPolicy 删除或代理环境变量被篡改时，云防火墙/宿主机规则仍阻断旁路。
• Tool Gateway 拒绝未声明工具、越权参数、过期审批票据和超预算调用。
• 生产写操作必须由独立身份执行，审批后若参数改变则审批失效。
• 日志可从一次业务任务追溯到 DNS、代理、工具、身份和最终业务资源变更。
• 紧急熔断能在既定时间内撤销身份并切换只读模式，且演练不会丢失取证证据。

事实依据与来源

截至 2026 年 9 月 22 日，Kubernetes 官方文档明确说明：默认拒绝出站可通过选择所有 Pod 且 egress: [] 的 NetworkPolicy 实现，但实际执行依赖网络插件；NetworkPolicy 的控制对象是 IP/端口级流量。Docker 官方文档说明 internal 网络用于限制外部访问，同时可通过宿主机 DOCKER-USER 链补充出站限制。AWS 官方文档指出实例元数据可返回 IAM Role 的临时凭证，并建议要求 IMDSv2 以增强对 SSRF 的防护。Google Cloud 官方文档则推荐 GKE 使用 Workload Identity Federation 管理工作负载对云 API 的访问。

这些依据共同支持一个工程结论：容器、文件系统和进程隔离只是基础；出口路径、云身份和应用动作必须组合治理。具体 CNI、代理和云平台能力会变化，实施前应在目标环境验证，不应把示例 YAML 直接视为完整生产策略。

FAQ

1. 完全断网是不是最安全？

对不需要外部数据的离线任务，是。对需要模型 API、代码仓库或业务系统的 Agent，完全断网会使任务失效。更现实的方案是默认断网，再按任务通过唯一出口授予最小、短期能力。

2. 只允许 443 端口够不够？

不够。443 上可以承载任意 HTTPS、WebSocket 和隧道流量。必须继续限制目的地、证书、协议、路径、方法、数据量和身份。

3. Kubernetes NetworkPolicy 能按域名放行吗？

原生 NetworkPolicy 以 IP 和端口为核心，不理解 URL 路径与请求正文。部分 CNI 提供 FQDN 扩展，但仍要处理 DNS 重绑定、动态 IP 和重定向，通常应把固定出口代理作为唯一目标。

4. HTTPS 加密后怎样做 DLP？

可让 Agent 显式调用组织代理并在受控信任域内做 TLS 检查，但要评估隐私、证书固定和法规影响。更推荐让高风险操作经过结构化 Tool Gateway，在加密前检查参数，避免对所有流量普遍解密。

5. 使用 IMDSv2 后还要封禁元数据地址吗？

要。IMDSv2 是纵深防御，不代表所有 SSRF、代理转发或同机攻击都消失。网络阻断、最小实例角色、工作负载身份和短期凭证仍然必要。

6. Agent 需要安装依赖怎么办？

在独立构建阶段通过内部包镜像下载，使用锁文件、摘要或签名验证，构建完成后运行阶段禁用包管理器与任意外网。不要允许生产 Runner 临时执行未知安装脚本。

7. 域名白名单经常变化，维护成本会不会太高？

会，因此允许项要有服务所有者、自动发现报告、过期时间和变更审核。优先接入稳定的组织网关或私有连接，而不是把第三方所有 CDN 域名永久放开。

8. 如何判断治理没有拖垮 Agent 成功率？

同时看任务成功率、策略拒绝率、代理延迟、重试放大倍数、人工审批等待时间、每任务出站字节和每任务成本。以风险等级设不同 SLO，不应为追求统一成功率而取消高风险控制。

参考来源

1. Kubernetes Documentation, Network Policies
2. Kubernetes API Reference, NetworkPolicy
3. Docker Documentation, Networking in Compose
4. Docker Documentation, Packet filtering and firewalls
5. AWS Documentation, Use IMDSv2
6. Google Cloud Documentation, Workload Identity Federation for GKE

安装部署教程

环境配置与 Docker 工作流

适合阅读安装部署、本地配置、服务器搭建和自动化流程类文章后继续转化。

环境配置资料包 包含 Windows / Mac / Linux 常见环境配置、依赖安装和报错排查清单。 查看资料包 Docker 工作流包 整理 Docker 部署模板、compose 示例和常用服务编排流程。 查看资料包