专栏 · Agent 工程手艺 › 第 197 期 · AGENT 工程 · 收录于 2026 年 8 月 23 日
Agent 是不可信软件,防火墙必须放在它外面的网络层——Ryan Dahl(Deno)
RD
Ryan Dahl · AI Engineer
2,322观看
80赞
3.4%点赞率
7评论
62.7万频道订阅
数据截至 8 月 27 日
TL;DR · 三句话
- 一agent 是不可信软件，守卫不能放在 agent 里面——Opus 再对齐也可能被 prompt injection 带偏，安全不能是「一厢情愿指望模型听话」，边界必须在 agent 软件之外，包括安全插件、改 agent 代码都不算数。→ 详细
- 二唯一的必经之路是网络字节：只读凭据会被「访问组合」（能进 EKS 再起 psql）绕过、MCP 工具管不住子进程、HTTP 代理看不懂 Postgres，所以 Deno 做了 Claw Patrol——在 HTTP 之下逐字节解析协议、用 HCL 写规则（一千行、进 git、有单元测试）、代持并注入凭据。→ 详细
- 三规则不只「拒」，还能路由到 LLM judge 或 Slack 里的人审批，并在仪表盘上看清每个 action；Ryan 的长期判断是模型越强问题越小，「但我们永远都需要兜底的安全机制」。→ 详细
01
Deno 为什么敢给 SRE agent 生产库的读写权限
- Ryan Dahl（Deno CEO、Node.js 作者）的切入点不是理论，是自家的值班痛苦：Deno Deploy（托管网站的服务）会宕机，PagerDuty（值班报警系统）半夜把人吵醒。最近他们在用 agent 自动处理这些事故，主角是 OpenClaw（一个开源 agent 框架），也试过别的 agent。→ 详细
- 他们给 agent 的权限是真宽：Postgres、Kubernetes、ClickHouse、AWS、GitHub、Slack，而且是读写。原话：「我们确实给了它们对这些系统的读写权限。」→ 详细
- 这么做的理由是上下文：agent 能在 ClickHouse 里看 trace（一次请求在系统里走过的完整轨迹）、去生产 Postgres 查某用户有哪些项目、翻 Slack 看沟通、看 GitHub 日志——「agent 真的能解决相当多的事故，以前这些都得有人参与处理」。权限越宽，能自主解决的事故越多，这是收益侧。→ 详细
- 风险侧同样具体：agent 可以起一个 psql 子进程执行
delete users table，或者调 kubectl delete namespace prod（删掉整个生产环境）。「它们可能不知怎么就认定，解决事故的办法就是把所有用户都删掉。」→ 详细
02
Opus 再听话也不算安全：对齐不是安全机制
- Deno 用的是 Opus，Ryan 承认它「对齐做得非常好」——你使劲让它删 users 表，它会一次又一次拒绝。但他的判断是：这不够。「安全不能只是一厢情愿地指望 Opus 永远听你的话。」→ 详细
- 原因是攻击面：这些 SRE agent 接入了客户支持系统，外部用户发来的文字会进入 agent 的上下文，也就可能被 prompt injection（提示词注入——在输入里藏指令，骗模型去做别的事）。「谁知道什么样的一串字符，能把 Opus 带进某种糟糕的状态，让它以为自己在采取正确的行动，实际上却在干非常不想要的事。」→ 详细
03
核心立场：agent 是不可信软件，守卫必须放在 agent 外面
- 由此推出全场最核心的一句：「agent 本身必须被当作不可信的软件。你不能依赖 agent 自己去看管自己在做什么，不能把守卫放在 agent 内部。」这是整个方案的第一性原理——不管模型多强、系统提示词写得多好，都不是安全边界。→ 详细
- 哪一层不用管：agent 跑在独立 VM（虚拟机）上，文件系统层面已经隔离，所以他们不担心 agent 碰本地文件。→ 详细
- 哪一层必须管：「agent 可能采取的每一个恶意动作、每一个正常动作，都以某种网络通信的形式出现——就是线路上的一些字节。」这些字节可以走 MCP（模型调用工具的标准协议），也可以走子进程——比如 Postgres 是非 HTTP 协议，OpenClaw 直接 spawn 一个 psql 就能连上服务。所以立场是「非常细致地理解从 agent 里出来的字节到底是什么」。把守卫放在网络层这个唯一的必经之路上，而不是某个工具或某个协议上。→ 详细
04
为什么「只读凭据 + ACL + MCP 工具」堵不住：访问权限会组合出洞
- 真实系统的例子：Deno 的生产 Postgres 在 AWS 的一个 VPC（私有网络）里，只能通过一个 EKS（AWS 托管的 Kubernetes）端点访问。他们怕的场景是：agent 穿过 EKS 做隧道、在里面 spawn 一个 psql、把 users 表 drop 掉。「我们担心的就是这种相当疯狂、变得非常复杂的情况。」→ 详细
- 把这条路径拆开看，难点有三层叠加：一条 agent 主机本来够不着的出站路径 + 走的是非 HTTP 协议 + 把关规则还得能读懂 SQL。而这正是人类 SRE 日常会做的操作，目标是让 agent 拥有「和人类差不多的访问能力」，同时不出事。→ 详细
- 传统答案逐个被否：① ACL / 只读 Postgres 凭据——「在一定程度上是对的，你应该做谨慎的凭据分配」，但要跨很多系统极其小心地做，而且「访问权限的组合会产生漏洞——你能访问一个系统，然后又能访问另一个系统」（单看每个凭据都安全，拼起来就是条隧道）；② 把一切包成权限谨慎的 MCP 工具——「可是这样一来，你就不能 spawn 子进程了」，一旦 OpenClaw 起了 psql，安全边界就已经被突破。→ 详细
05
现有方案巡礼：LLM 网关、HTTP 代理、凭据注入、进程沙箱各管一段
- LLM gateway（OpenRouter、LiteLLM）：带 guardrails，防 prompt injection、扫描表达式，但只管与 LLM 提供商之间的流量，「我们在说的是和数据库那些东西打交道」。→ 详细
- HTTP 层代理：httpjail（可写「能 GET 不能 POST」「只能访问某子路径」这类规则）、Brex 的 Crabtrap（用 LLM 做 judge 判断来回的 HTTP 请求）——都停在 HTTP 层。→ 详细
- 凭据注入代理：AgentVault——agent 从不见真实凭据，只往外传占位符，由代理替换成真值。Ryan 评价：「是问题的重要一部分，但不是完整的解决方案。」→ 详细
- 进程沙箱：NVIDIA 的 OpenShell，操作系统层面拦文件路径和系统调用；Deno 因为已经用独立 VM，对这层不关心。→ 详细
06
Claw Patrol：工作在 HTTP 之下、逐字节解析协议、用 HCL 写规则的防火墙
- 产品定义：Claw Patrol，MIT 许可的开源项目，一个坐在 agent 前面的代理。与 HTTP 代理的本质差别是层级更低——「它理解从你的 agent 流出的每一个字节」，所以能看懂 Postgres 这种非 HTTP 协议；同时像 AgentVault 一样持有并注入凭据，agent 软件永远看不到机密值。→ 详细 → 详细
- 「规则是整个系统的关键部分」。规则用 HCL（HashiCorp Configuration Language，Terraform 用的那种声明式配置语言）写在配置文件里，「在这里实际上用得非常顺手」。Deno 内部有一个提交进 git、约一千行的文件，定义了全公司所有服务的 agent 权限，「我们对它的每一处改动都管得非常细」——权限变成了可 review、可回滚的代码。现场展示的规则示例是拦截某些 Postgres 函数的调用。→ 详细
- 规则「即使在通过其他系统做隧道时也能生效」，正面回答了第四节的 VPC→EKS→psql 难题；支持多种协议，遇到不认识的协议有插件系统可扩展。→ 详细
- Demo（录播非现场）：
claw patrol run codex 用 YOLO 模式（不问确认、照做）启动 Codex，让它「把 Postgres 里的 users 表删掉」；Codex 乖乖起 psql 子进程去删；这个连接经过 Claw Patrol，被逐字节解析、匹配规则，最终拒绝这个 action（他们用「action」而非「请求」来称呼每一次出站动作，因为比 HTTP 请求更通用）。→ 详细
07
仪表盘 + 审批路由：规则不只「拒绝」，还能「问人」「问 LLM judge」或两者串联
- 可观测：Claw Patrol 有一个仪表盘，顶部列出各个设备 / agent 和流过的 action，哪些被拒、哪些待审批一目了然；点进任一 action 能看细节，还有分析功能。Ryan 形容它「非常实用主义，就是我们理解自己 agent 所需要的东西」——不是给人看的炫技，是给运维人看清 agent 在干什么的窗口。→ 详细
- 审批系统是规则的第三种动作：规则除了放行 / 拒绝，还能「去问一个人——比如在某个 Slack 频道里」，或「跑一个 LLM judge（用另一个模型来评判这次动作该不该放）」，或任意组合——「比如先过一遍 LLM judge，再去 Slack 里拿审批」。这让高风险操作既不被一刀切禁掉，也不是无人把关。→ 详细
- 黑盒原则：这一切都发生在「agent 软件本身之外」——「我们把 agent 软件当作黑盒，不要求对那个软件做任何改动。」换 OpenClaw、换 Codex、换任何 agent，防线不动。→ 详细
08
凭据注入的广度 + 跑在 Tailscale 里：为真实系统而生，不是想象场景
- 凭据不只是 bearer header（HTTP 头里的令牌）：Claw Patrol 能处理 cookie、Postgres、ClickHouse、各种 OAuth 协议、甚至 AWS SigV4（AWS 那套复杂的请求签名）。「这东西真的是从实际需求里长出来的，是为真实世界的系统准备的。」→ 详细
- 网络形态：跑在 Tailscale 或 WireGuard（两种组私有虚拟网络的工具）之上。Deno 自己把 agent 和 Claw Patrol 都放进 Tailscale 的 tailnet，Claw Patrol 充当出口节点（所有出站流量的唯一出口）；仪表盘身份认证也直接复用 Tailscale 身份，不再叠一层登录。效果是「我们所有的东西都不暴露在公网上」。→ 详细
09
收束论点：安全边界必须在别处，对齐是好事但不是防线
- 一个提醒：Claw Patrol 本身持有所有生产系统的凭据，「你必须非常小心地对待它」——把信任集中到一个点，这个点就成了最要保护的东西。→ 详细
- 全场论点原话收束：「不能信任 agent 来管束它们自己，这也包括安全插件，或者对 agent 软件本身的改造。安全边界必须放在别的地方。」对齐不是坏事，但「对于真实世界的安全系统，我们确实需要在更高的层面上做控制」。Claw Patrol 是 Deno「为了让这件事在自己这儿跑通所做的尝试」。→ 详细
10
Q1｜你们做了什么样的测试来确保它真的管用？
- 观众提问（转写里这个词 ASR 没听清，按 Ryan 的复述理解为「测试」）。Ryan 补充了一个正文没讲的功能：规则文件自带测试系统——可以提供 fixture（固定的请求样本）让它们流经规则，写成单元测试，确保「那条 fixture 请求永远会被你这套规则拦住」；Claw Patrol 软件本身也有一大套测试。也就是说安全规则和代码一样，有回归测试保护，改规则不会悄悄放开原本拦住的东西。→ 详细 → 详细
11
Q2｜agent 越来越聪明，这个问题会变大还是变小？
- 第二问的原话没录进转写，只有 Ryan 的复述。答：「我们永远没法完全信任 AI。」随着模型更聪明、上下文更充分、知道自己在替一家公司干活、知道哪些坏事不该做，问题会越来越小，Opus 就比前代更对齐——「但我认为我们永远都需要有兜底的安全机制。」→ 详细
12
联系方式
- 演讲里没有留个人联系方式；Ryan 说 Claw Patrol 是 MIT 许可的开源项目，「你们可以在这里看看它」（指向幻灯片，转写未含链接），并表示会后在场可继续交流。→ 详细 → 详细