你有没有想过一个问题：当你让 AI Agent 帮你写代码、调 API、搜文档的时候，它到底在访问哪些域名？
大部分 Agent 工具对网络访问的控制基本为零。Copilot CLI 要调 api.github.com，Claude Code 要连 api.anthropic.com，Cursor 要访问自己的后端服务。这些请求从你的机器发出去，但你对它们能连接什么、不能连接什么，完全没有任何约束手段。
这件事的严重性被严重低估了。AI Agent 正在从”辅助工具”变成”自主执行者”，它不再只是给你建议，而是直接运行命令、发起网络请求、操作文件系统。给它 root 权限，它就能做任何事。不给 root 权限，它依然可以做很多你不希望它做的事。
AWF（Agentic Workflow Firewall）就是冲着这个缺口来的。它是 GitHub 官方出品的一个 CLI 工具，专门给 AI Agent 的容器加上网络防火墙，只允许访问你指定的域名白名单。说白了这个工具解决的就是一句话的事：让 Agent 能干活，但别让它乱跑。
环境准备
AWF 的安装简单到令人意外。毕竟它的底层是 Docker 容器加 iptables 规则，按常理应该有一堆依赖要折腾。但 GitHub 把复杂度全包进了安装脚本里。
前置条件只有两个：一台装了 Docker 的 Linux 机器（WSL2 也行），以及 sudo 权限。没了。不需要 Node.js 运行环境，不需要手动配 iptables，不需要懂容器网络。安装脚本会自动处理一切：
curl -sSL https://raw.githubusercontent.com/github/gh-aw-firewall/main/install.sh | sudo bash
跑完之后用 sudo awf --version 验证一下。如果输出了版本号，环境就绪了。我见过有人在 WSL2 上装，第一次因为 Docker daemon 没启动卡住了，sudo service docker start 一把就好。官方仓库里的 Issues 区也反映了类似的情况，不算什么大坑。
额外提一嘴，AWF 目前只支持 Linux。macOS 用户得在虚拟机或 Docker Desktop 里跑。Windows 用户走 WSL2 路线。这个平台限制是它架构决定的（依赖 iptables 和 Docker 网络栈），短期内不会改变。
操作流程
AWF 的核心用法一句话就能说清楚，但这句话背后的设计值得仔细拆解。
最基本的命令长这样：
sudo awf --allow-domains github.com -- curl https://api.github.com
-- 是分隔符，左边是防火墙配置，右边是要执行的命令。这个设计很干净，不需要额外配置文件，不需要预先定义规则，所有东西都在一行命令行里。用惯了 Docker 的 -- 分隔符的人应该秒懂。
在实际使用中，你会发现域名的白名单逻辑比表面看起来聪明。--allow-domains github.com 不仅放行 github.com，还自动放行它的子域名：api.github.com、raw.githubusercontent.com 等等。如果你需要更精细的控制，可以用 --block-domains 在允许的域名里再排除特定子域：
sudo awf \
--allow-domains example.com \
--block-domains internal.example.com \
-- curl https://api.example.com
通配符也支持。*.googleapis.com 匹配所有 Google API 子域，api-*.example.com 匹配前缀模式。对于需要访问多个 API 端点的场景，这个粒度刚好够用。
开调试日志也很方便，--log-level debug 就能看到 Squid 代理层面的请求转发日志。如果你需要排查”为什么这个域名访问不了”，先开 debug 看代理日志，大概率是域名匹配规则没覆盖到。
关键设计
AWF 的架构设计是它最值得写的地方。它不是简单的 iptables 脚本包装器，而是一个三容器协同系统。
从 GitHub 仓库的源码和 1577 次提交记录来看，AWF 启动时会拉起三个容器：Squid 正向代理、Agent 执行容器、以及一个可选的 API Proxy sidecar。流量路线是这样的：Agent 容器发出的 HTTP/HTTPS 请求先被 iptables 规则 DNAT 重定向到 Squid 代理，Squid 根据白名单决定放行还是拒绝。API Proxy sidecar 则专门处理 Copilot 的鉴权流量，把真实的 API Key 从 Agent 容器中隔离出去。
这个设计有几个特别聪明的点：
-
iptables 规则打在了 DOCKER-USER 链上而非 INPUT/OUTPUT 链。这意味着规则对宿主机上所有容器生效，不会被 Docker 自己的规则覆盖，也不需要在每个容器里单独配置网络策略。 -
Agent 容器永远拿不到真实的 API Key。GitHub 用了一套 placeholder 机制：Agent 容器里注入的是假 Token，真正的凭据由 API Proxy sidecar 持有，Agent 发起的 API 请求经过 sidecar 时才会被注入真实凭据。 -
Token 在代理启动后 5 秒内从环境变量中清除，连 /proc/1/environ都读不到。配合进程以非 root 用户运行，攻击面被压缩到了最小。 -
Squid 代理配置不通过文件挂载传入，而是用 base64 编码的环境变量注入。这个细节意味着即使在 Docker-in-Docker 场景下，敏感配置也不会以文件形式残留在宿主机上。
这几层防御叠在一起，已经不是”挡一下”的水平了。从设计意图推断，GitHub 内部对 Agent 安全的重视程度应该远超对外公开的程度。
但也不是没有槽点。Chroot 模式始终启用（早期版本是可选的，后来改成了强制），这意味着 Agent 容器对宿主机文件系统的访问被限制在几个白名单目录里。安全性的确提升了，但如果你想让 Agent 访问宿主机的某个非标准路径，就得手动加 --mount 参数。而且绕过 HTTPS_PROXY 直连 TLS 的工具会遇到握手失败，因为 Squid 期待的是 CONNECT 方法。这对于用原生 TCP 连接的工具是个硬伤。
使用场景
AWF 最典型的场景，就是运行你不完全信任的 AI Agent。
GitHub 自己已经把 AWF 深度集成到了 Copilot CLI 的工作流里。在 Copilot 的 agentic workflow 中，所有由 AI 触发的命令都跑在 AWF 沙箱里，网络访问被严格限制在 GitHub API 和 Copilot API 的域名范围内。这套机制在 GitHub 内部已经跑了 29 个以上的自动化工作流，从代码审查到 CI 辅助，每天执行成千上万次。
另一个场景是开发者的本地测试。你在让 Claude Code 或 Cursor 帮你写一个需要调外部 API 的功能时，Agent 会发出 HTTP 请求验证代码逻辑。用 AWF 包一层，确保它只访问你指定的 API 域名，不会意外把代码片段或调试信息发到不该发的地方。
还有一类用法被低估了：验证第三方工具的网络行为。你从 GitHub 上 clone 了一个看起来还行的开源 CLI 工具，不确定它会不会在后台偷偷发数据。用 AWF 运行它：
sudo awf --allow-domains "" -- ./suspicious-tool
白名单设为空，它连一个字节的数据都发不出去。跑完之后检查 Squid 的代理日志，所有被拦截的 DNS 查询和连接尝试一清二楚。比在 /etc/hosts 里手动加规则省事多了。
洞察与反思
AWF 这个项目让我重新想了一个问题：AI Agent 的安全模型到底应该长什么样。
目前主流的做法是”权限最小化”，限制 Agent 能调哪些工具、能读哪些文件、能用哪些 API。这是应用层的控制。但网络层的控制几乎没人做。AWF 补的就是这一层。它不是替代 RBAC 或工具权限系统，而是和它们叠加使用，形成纵深防御。这个思路很对，只是现在意识到的人还不多。
从 GitHub Issues 来看，这个项目还处在早期阶段。99 个 Star、72 个待解决的 Issue，说明用户基数不大但反馈很活跃。比较典型的问题是 gVisor 运行时的偶发崩溃（segfault 或 abort）、Docker-in-Docker 场景下的配置复杂度，以及对 macOS 和 Windows 原生支持的需求。这些都不是致命问题，但确实限制了它的推广速度。
站在 2026 年年中这个时间点，Agent 安全工具的市场几乎还是空白。AWF 踩准了时间窗口，但能不能跑起来，取决于 GitHub 愿不愿意把它从”内部工具的开源版”推到”独立产品”的定位。如果只是作为 Copilot 生态的附属品存在，它很难吸引 GitHub 之外的用户。
从更宏观的视角看，Agent 安全的缺失很大程度上是因为”还没出过大事”。没有一起公开的、由 AI Agent 网络行为导致的安全事故被广泛报道，所以大多数团队还没有把这件事排上优先级。但这不是”不会出事”的证据，只是”还没出事”的时间差。等第一起事故出来再补防线，代价就不是装个 AWF 这么简单了。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/github/gh-aw-firewall |
| Smithery | https://smithery.ai/skills/github/awf-skill |
| 文档 | https://github.com/github/gh-aw-firewall#readme |
总结
AWF 做的事情不复杂：给 AI Agent 套一个网络白名单。但这件事背后的思路值得跟下去，因为它在回答一个更根本的问题，当 AI 开始自主执行操作时，信任边界应该画在哪。
目前 AWF 最适合的场景还是 GitHub Copilot 生态内的重度用户，以及那些需要在本地沙箱化运行 Agent 的开发者。如果你只是偶尔用用 Cursor 写代码，AWF 带来的额外复杂度可能超过它的安全收益。但如果你在搭建一套自动化的 Agent 工作流，或者需要让 Agent 处理敏感数据和 API 调用，它值得放进你的工具箱。
工具本身还在快速迭代中。关注它的 release notes，尤其是 agent timeout、DNS 预解析、CA 根证书支持这几个方向的更新，每一个都在让”沙箱化 Agent”这件事更接近生产可用。