AWF：一行命令，给AI Agent套上域名白名单的“紧箍咒”

让AI Agent干活，又怕它乱跑——这是所有把AI接入生产环境的团队都会遇到的困境。

GitHub开源的AWF（Agentic Workflow Firewall） ，用一行命令解决了这个问题：给AI Agent的网络访问套上一个只认白名单的“紧箍咒”。

一、一行命令，搞定全网隔离

AWF的用法极其直接。想在只有 github.com 可访问的环境下执行 curl 命令？一行搞定：

sudo awf --allow-domains github.com -- curl https://api.github.com

想测试某个域名被屏蔽的效果？同样一行：

sudo awf --allow-domains github.com -- curl -f --max-time 10 https://example.com

-- 是分隔符，前面是防火墙配置，后面是你要执行的命令。没有复杂的配置文件，没有冗长的网络策略定义——想放行哪些域名，直接列出来就行。

如果需要放行多个域名，用逗号分隔：

sudo awf --allow-domains github.com,api.openai.com,api.anthropic.com -- <command>

域名一多，也可以写成文件：

sudo awf --allow-domains-file ./allowlist.txt -- <command>

文件里每行一个域名，支持 # 注释。

二、通配符与协议级控制

AWF的域名匹配规则相当灵活：

• github.com —— 自动匹配所有子域名（api.github.com、raw.github.com 等）
• *.github.com —— 显式匹配任意子域名
• api-*.example.com —— 前缀通配符
• https://secure.com —— 仅允许 HTTPS
• http://legacy.com —— 仅允许 HTTP
• localhost —— 自动配置本地测试

这意味着你可以精细到控制“哪个协议访问哪个域名”——而不是一刀切地全开或全关。

AWF还支持黑名单覆盖白名单。如果某个域名在白名单里但你想单独封掉：

sudo awf --allow-domains github.com --block-domains bad.example.com -- curl ...

block-domains 优先级高于 --allow-domains，可以在不拆散白名单的前提下做精细排除。

三、它到底是怎么工作的？

表面上看是一行命令，背后是三层隔离：

1. Squid代理：所有出站 HTTP/HTTPS 流量经过 Squid，按域名白名单过滤
2. Agent容器：在 Docker 沙箱里执行命令，所有 HTTP/HTTPS 路由走 Squid
3. API代理边车（可选）：专门保管 LLM API 密钥，密钥永远不会进入 Agent 进程

三层架构各自独立又互相配合。更狠的是，AWF在宿主机层面用 iptables DOCKER-USER 链强制对所有容器生效——就算容器里的进程想绕过代理直连，也会在内核层被直接丢掉。

四、为什么AI Agent需要这个？

AI Agent会主动发起网络请求：调用LLM API、拉取依赖包、访问文档、抓取网页。一旦Agent获得执行权限，它的网络行为就等同于你的网络行为。

更隐蔽的风险在于：AI会自主决定访问哪些域名。一个被要求“帮我安装这个包”的Agent，可能会自己去访问任意的第三方源。一个被要求“调研竞争对手”的Agent，可能会去爬你根本不想让它碰的网站。

AWF把AI Agent的网络行为限制在一个可控的“白名单笼子”里——只能访问你明确批准的域名，其他统统拒绝。

GitHub Agentic Workflows的官方文档将网络权限划分为三个等级：

GitHub Copilot、Claude、Codex、Gemini 四大引擎均已通过 AWF 支持网络权限控制。

资源地址

AWF的设计哲学只有一条：AI Agent能访问什么，由你决定，不由它决定。一行命令，把主动权从AI手里拿回来。