当 AI 生成的代码直接进入生产环境，风险不只来自模型回答错误，也来自那些没有明确所有者、没有经过审查，却已经在运行的调用路径。Dan Finneran 的分享讨论了一个很有价值的方向：利用 eBPF 在 Kubernetes 节点的内核层观察和控制 AI API 流量，让团队能够在不修改应用源码、不重启容器的情况下，为 AI Agent 增加护栏。
这类能力尤其适合存量服务、第三方镜像，以及已经部署但尚未建立完善治理机制的 Agent。
把控制点从业务代码下沉到内核
传统的 AI 治理通常依赖 SDK 包装层、API Gateway、服务网格或应用内中间件。它们有效，但有一个共同前提：调用方愿意并且能够接入治理组件。
eBPF 提供了另一条路径。它可以在 Linux 内核的网络与安全相关钩子上运行受验证的程序，并把策略、事件和统计数据交给用户态控制器处理。在 Kubernetes 中，这意味着控制器可以随着节点部署，而不是要求每个工作负载重新集成一套 AI SDK。
分享中提到的控制方向包括：
- 识别并过滤不符合规则的 Prompt；
- 将请求导向替代模型或指定 API 端点；
- 对调用施加 Token 配额或速率限制；
- 约束 AI Agent 进程可执行的系统调用；
- 审计实际发生的模型调用，而不是只相信应用配置。
这里的核心价值不是“eBPF 自动让 AI 安全”，而是它能成为一层独立于应用发布节奏的执行面。安全团队可以先看到真实流量，再逐步从观察模式进入阻断模式。
AI API 流量与普通 HTTP 流量的不同
对 AI 调用做治理时，不能只看目标 IP 和端口。一个到模型供应商的 HTTPS 连接，可能携带普通文本补全、工具调用、带敏感数据的上下文，甚至是高成本的批量推理任务。
因此，策略通常需要回答更细的问题：
- 这个 Pod 是否允许访问外部模型 API？
- 它能访问哪些模型提供方和区域端点？
- 请求是否超出预期频率、并发数或预算？
- Agent 是否试图启动 Shell、读取密钥目录或建立额外网络连接？
- 某类工作负载是否应该被切换到内部模型或低成本模型？
不过，Prompt 过滤存在一个关键边界：绝大多数模型 API 使用 TLS。网络层 eBPF 程序通常看到的是加密后的 socket 字节流，而不是 HTTP JSON 中的 messages 字段。要实现真正的文本级 Prompt 审查或改写，通常仍需要在 TLS 终止点、受控代理、应用运行时，或能够获得解密上下文的位置配合处理。
换句话说，eBPF 很适合无侵入地执行连接级、进程级和行为级策略；对明文语义的深度治理，则需要明确 TLS 与数据解密边界。
先用 eBPF 观测，再决定该拦什么
在生产环境直接阻断流量很容易误伤。更稳妥的迁移路径是：先建立调用清单，再按工作负载逐步收紧策略。
下面的命令使用 bpftrace 观察主机上发起 IPv4 TCP 连接的进程。它适合在测试节点或受控排障窗口中快速确认哪些二进制文件正在建立外连。
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_connect
/args->addrlen == 16/
{
printf("pid=%d comm=%s fd=%d\n", pid, comm, args->fd);
}
'
运行前需要节点具备 bpftrace、BTF/内核 tracepoint 支持以及相应权限。该脚本不会解析目标地址，也不会修改流量；它的作用是建立最基础的“谁在联网”视图。
在 Kubernetes 中，可以进一步把观测数据关联到容器、Pod、Namespace 和 ServiceAccount。治理策略不应只写成“阻止某个 IP”，而应落到可追责的工作负载身份，例如“report-agent 只能调用获批准的模型端点”。
可以这样实践：用 Cilium eBPF 策略收紧模型出口
下面的示例假设集群已安装并启用 Cilium，且 DNS/FQDN 策略可用。它不是 Prompt 内容过滤器，但可以立即限制指定应用只能访问允许的模型 API 域名，同时保留 DNS 解析能力。
将 app 标签、命名空间和域名替换为你的实际值后应用：
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: report-agent-ai-egress
namespace: ai-workloads
spec:
endpointSelector:
matchLabels:
app: report-agent
egress:
- toEndpoints:
- matchLabels:
k8s:io.kubernetes.pod.namespace: kube-system
k8s:k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
- port: "53"
protocol: TCP
- toFQDNs:
- matchName: api.openai.com
- matchName: models.internal.example.com
toPorts:
- ports:
- port: "443"
protocol: TCP
kubectl apply -f report-agent-ai-egress.yaml
kubectl -n ai-workloads get ciliumnetworkpolicy report-agent-ai-egress
这类策略的优点是无需改动 report-agent 的代码，也不需要为了加载策略而重启该 Pod。代价是它只能控制网络可达性，不能判断某条 HTTPS 请求里的 Prompt 是否包含敏感字段。
对于需要模型切换、预算控制或 Prompt 规则的场景，可以把架构拆成两层：eBPF 负责识别工作负载身份、连接行为和违规系统调用；受控的 AI Gateway 或本地代理负责在可见明文的边界处理请求体、模型路由和 Token 计量。两层共享同一个策略来源，避免网络规则与业务规则各自漂移。
给 Agent 加系统调用边界
网络出口只是 Agent 的一部分攻击面。一个具备工具调用能力的 Agent 还可能执行子进程、读取挂载目录、访问云元数据服务，或尝试建立未授权的 socket 连接。
eBPF LSM 等内核安全钩子可以用于在系统调用或对象访问层实施额外限制，但落地前需要确认内核配置、LSM 启用状态、容器运行时和权限模型。对高风险动作，建议先记录再阻断，并为平台组件建立明确的豁免名单。
一个实用的分层顺序是：
- 盘点 Agent Pod 的外部端点、进程和调用频率。
- 先启用仅观测的 eBPF 事件采集与告警。
- 用网络策略限制未批准的模型端点和云元数据访问。
- 把 Token、模型路由和 Prompt 语义规则放在能够处理明文的 Gateway 或代理中。
- 对
exec、敏感文件访问和异常网络连接逐步启用系统级阻断。
采用时要避免的两个误区
不要把 eBPF 当成绕过 TLS 的工具。它能提供强大的内核级可见性和执行能力，但加密流量的内容治理仍必须在合法、明确的解密边界完成。
也不要把“无需改代码”理解为“无需设计”。模型端点白名单、预算归属、服务身份、审计保留周期和误拦截回滚机制，都需要在部署前定义清楚。eBPF 最适合补齐那些无法快速改造的应用盲区；当它与 API Gateway、身份体系和 Kubernetes 策略共同工作时，AI Agent 才能在不牺牲交付速度的前提下获得可执行的生产治理。