Agent Egress Boundary

Agent Egress Boundary 是一个仍在形成中的说法，不是已经标准化的产品类别。本词条用它概括一种基础设施模式：把 AI Agent（智能体）的外部网络访问强制收束到唯一受控路径，在该路径上执行默认拒绝、目的地白名单等策略，并留下能与原始用户交互关联的审计证据。

它解决的不是“Agent 是否理解了正确意图”，而是两个更确定的问题：

1. Agent 实际能连接哪里，是否存在绕过策略的第二条路径；
2. 某次外部请求由哪次用户交互触发，最终被允许还是拒绝。

因此它和 Agent Guardrails（Agent 护栏）互补：应用层护栏影响模型更可能做什么，出站边界限制工作负载事实上能做什么。

CNCF 示例：控制面与审计面分离

Marko Sluga 在 CNCF 文章《Network boundary for AI agents using NGINX and OpenTelemetry》中给出一个最小实现：

• NGINX 是流量控制面：入站时作为反向代理终止 TLS 并转发给 OpenClaw；出站时，同一实例作为正向代理，检查 Agent 工具发起的请求。
• iptables 提供不可绕过性：丢弃不经过代理的其他出站流量。边界因而是部署架构的属性，而不是要求 Agent 或应用代码自觉使用代理。
• OpenTelemetry 是审计面：NGINX 为请求生成 span，OpenTelemetry Collector 保存审计日志，或把数据发送到 Jaeger、Grafana、SIEM 等系统。

原文配图给出的完整请求链路如下：

sequenceDiagram
    actor U as 用户
    participant N as NGINX
    participant A as OpenClaw
    participant L as Ollama
    participant O as OpenTelemetry
    participant W as 外部网站

    U->>N: 1. 发起对话
    N->>O: 2. 生成入站 OTEL 记录
    N->>A: 3. 转发请求
    A->>L: 4. 调用本地 LLM
    A->>N: 5. web_fetch 经正向代理出站
    N->>N: 6. 允许或拒绝目的主机
    N->>O: 7. 生成出站 OTEL 记录
    alt 允许
        N->>W: 8. 发送 Web 请求
    else 拒绝
        N-->>A: 返回拒绝结果
    end

这里最关键的不变量是：

Agent 工作负载只能访问代理；只有代理可以访问外部网络。

如果 Agent 还能直连互联网，即使代理上的规则写得正确，整个方案也只是可选策略，不是安全边界。Kubernetes 中可以用网络策略、CNI 能力或节点防火墙建立同类约束；文章的验证环境使用的是 iptables。

图片中的验证结果

验证环境是一个单节点 Kubernetes 集群，openclaw 命名空间内的 nginx、ollama、openclaw、otel-collector 四个 Pod 均为 1/1 Running。GPU 截图显示测试机使用 NVIDIA GeForce RTX 3060：推理时显存约 2823 MiB / 6144 MiB，GPU 利用率 82%，ollama-server 占用约 2814 MiB。这些数值只描述该次实验环境；方案本身不依赖这块 GPU。

出站 span 截图则给出了策略执行的直接证据：

与之对应的 NGINX map $host $proxy_allowed 配置采用默认拒绝：

map $host $proxy_allowed {
    default                 0;
    nginx.org               1;
    www.nginx.org           1;
    duckduckgo.com          1;
    html.duckduckgo.com     1;
    api.duckduckgo.com      1;
    links.duckduckgo.com    1;
}

这组证据把“声明允许什么”和“实际发生了什么”连在一起：白名单配置是策略，200/403 span 是执行结果。

审计链应记录什么

NGINX 的 ngx_otel_module 支持 W3C trace context 传播和 OTLP/gRPC 导出，并自动记录 HTTP 方法、目标、路由、状态码、主机、端口、对端地址等属性。模块还暴露 $otel_trace_id、$otel_span_id 和 $otel_parent_id，可用来关联入站交互与出站副作用。

一条有用的 Agent 审计链至少要回答：

• 主体：哪个 Agent、工作负载或会话发起请求；
• 来源：由哪次用户交互或上游任务触发；
• 动作：方法、目标主机、端口，必要时包括路径与工具名；
• 裁决：允许或拒绝，以及命中的策略；
• 结果：响应状态、耗时、失败原因；
• 关联：入站 span、模型/工具 span 与出站 span 能否串成同一条 trace。

只有网络流量日志而没有会话关联，只能回答“某个 Pod 访问了哪里”；只有 Agent trace 而没有网络层裁决，又无法证明工作负载没有绕过工具接口。

这不是完整的安全方案

目的地域名白名单只能约束“去哪里”，不能自动约束“在那里做什么”。Agent Sandbox（Agent 沙箱）中的泄露案例说明：一个被允许的 API 域名可能同时提供读取、上传、转发等多种能力。生产边界往往还要检查身份、凭证来源、方法、路径、header、速率和数据流向。

这套 CNCF 示例还有几项需要在生产设计中补足：

• 代理自身是新边界：需要加固、监控和高可用，故障时应明确选择 fail closed 还是受控降级。
• 加密流量的可见性有限：HTTPS CONNECT 代理通常能按目标主机裁决，但若要按路径、方法或内容控制，需要 TLS 检查、应用层网关，或让工具通过结构化代理调用。
• DNS 和旁路流量也要纳入威胁模型：只封普通 HTTP/HTTPS 不代表没有其他外发通道。
• OpenTelemetry 是证据格式，不是不可篡改账本：Collector、存储、访问控制、保留周期和敏感字段处理同样属于审计系统的一部分。
• 网络控制不判断决策正确性：它不能替代身份管理、运行时隔离、工具权限、人工审批和高层治理。

因此，Agent Egress Boundary 应被视为纵深防御中的一层：底层网络保证请求不能绕过，中间代理执行策略并留下证据，上层 guardrail 和治理系统判断意图与业务风险。

可替换实现

NGINX 只是示例中的策略执行点。只要保持“唯一出口 + 默认拒绝 + 可关联审计”这三个性质，也可以使用其他正向代理、服务网格 egress gateway、网络策略或专用 Agent gateway。实现选择是次要的，真正需要验证的是边界不变量是否成立。

相关词条

• Agent Sandbox（Agent 沙箱） — 出站控制所依附的执行与网络隔离环境
• Agent Guardrails（Agent 护栏） — 影响意图与动作许可的上层控制
• Harness Engineering（驾驭工程） — 把执行、工具、可观测性与治理组合成运行系统
• Model Context Protocol（模型上下文协议） — 工具调用层仍需与网络出口和凭证边界共同治理