Earl：把 agent 的外部调用收进可审计模板
让 coding agent 接入外部系统时，麻烦常常不在“能不能发请求”，而在“谁决定了请求长什么样”。如果模型同时看到 API response、auth header、URL template 和 shell command，它既容易被 prompt injection 干扰，也很难留下一个人类能 review 的调用边界。
今天看的是 mathematic-inc/earl。它把 agent 的外部调用拆成两层：人把 operation 写成 HCL template，提交到 repo；agent 只看到 tool name、description 和参数 schema。真正执行时，Earl 从 OS keychain 取 secret，把 agent 传入的参数渲染进模板，再发出 HTTP、GraphQL、gRPC、Bash、SQL 等请求。它也可以作为 MCP server 暴露给 Claude Code、Cursor 等 agent client。
按 GitHub repository page、README、release page、tags、latest commit、LICENSE、GitHub API cache 和本地 git clone 在 2026-09-05 18:15 Asia/Shanghai 能核验的信息，mathematic-inc/earl 当前有 113 stars、7 forks。主要语言是 Rust，license 是 Apache-2.0。默认分支是 main，仓库创建于 2026-02-22 09:30:12 UTC，latest push 是 2026-09-05 10:00:37 UTC。最新提交是 df2c18e，提交时间 2026-09-05 09:57:45 UTC，提交信息是 chore(deps): bump @vitejs/plugin-react from 6.1.0 to 6.1.1 (#106)。最新 GitHub Release 是 v0.6.3，发布时间 2026-08-27 07:20:05 UTC。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | mathematic-inc/earl |
| 定位 | 面向 AI agent 的安全 CLI proxy 和 MCP tool bridge |
| Stars | 113 |
| Forks | 7 |
| 主要语言 | Rust |
| 许可证 | Apache-2.0 |
| 创建时间 | 2026-02-22 09:30:12 UTC |
| Latest push | 2026-09-05 10:00:37 UTC |
| 最新提交 | df2c18e，2026-09-05 09:57:45 UTC |
| 最新 Release | v0.6.3，2026-08-27 07:20:05 UTC |
| 安装方式 | curl install script 或 cargo install earl |
| 关键词 | HCL templates、MCP、OS keychain、prompt-injection、SSRF hardening |
它解决的是调用边界
很多 agent integration 的默认路径很松：把 token 塞进环境变量，把 curl 或 SDK 说明交给模型，然后希望它每次都生成正确请求。这在 demo 里很快，但一旦接入 GitHub、Stripe、internal admin API 或数据库，风险就变得具体了。一个恶意 issue comment、API response 或网页内容，可能诱导 agent 改 URL、换 method、扩大查询范围，甚至把 secret 混进输出。
Earl 的做法是让人类先写模板。模板描述 method、URL、auth、参数、校验和执行协议；agent 只负责给参数值。README 的核心说法是：LLM 不读取会执行的模板主体，所以外部响应里的注入指令没有机会直接改掉请求结构。
这个边界不神奇，但有用。它把“这个 agent 可以调用什么”从聊天上下文里拿出来，变成 repo 里可以 review、diff、version pin 的文件。对团队来说，这比每个 agent session 都临时生成一段 curl 更接近工程控制面。
Secret 不进入 tool 参数
另一个现实问题是 secret 传播。很多 MCP tool 或脚本 wrapper 最后会让模型知道太多：token 名称、header 形状、甚至错误输出里的凭证片段。Earl 把 secret 存在 OS keychain 里，模板通过 secret reference 读取，agent 调用时不需要把 token 作为参数传入。
这适合两类场景。第一类是常见 SaaS API，比如 GitHub search、issue triage、deployment status、billing read-only endpoint。第二类是内部服务：你希望 agent 能查询某个 staging API，但不希望它自由拼 endpoint 或看到凭证材料。
当然，这不是让 agent 获得生产写权限的理由。更实际的做法是从 read-only token、scoped token、staging environment 和明确的 allowlist 开始，把 Earl 当成减少暴露面的边界，而不是最终的权限系统。
HCL 比 prompt 更容易 review
Earl 选择 HCL template 很有意思。它不是把所有策略塞进自然语言 prompt，而是把 operation 写成配置文件。配置的好处是 review 成本低：method 是什么、URL 是否固定、参数是否 required、secret 从哪里来、bash sandbox 是否打开，都能在 diff 里看见。
这对 agent workflow 很关键。Prompt 里的“不要访问内网地址”很容易被上下文稀释；模板和 hardening 配置至少能把这类规则变成执行路径的一部分。Earl 文档也覆盖 SSRF protection、egress allowlist、policy engine、environment override、external secrets 等更接近上线环境的问题。
最新 release v0.6.3 本身是 infrastructure-only fix，主要修 crates.io publication pipeline。单看功能不 flashy，但它说明项目近期在打磨 release reliability。此前的 v0.6.2 也强调让 CI 覆盖 Bash sandbox 路径，v0.5.1 则加入 browser protocol。对一个安全边界类工具来说，发布管线和 sandbox 测试不是旁枝，而是信任的一部分。
适合谁
第一类是已经让 agent 接触外部 API 的开发者。你不一定需要一个完整平台，但你需要把“允许调用哪些 operation”从临时 prompt 变成可审计文件。
第二类是内部工具团队。很多内部 API 没有漂亮的 public SDK，却有稳定的 HTTP、SQL 或 gRPC 接口。Earl 可以给 agent 一组小而明确的 operations，而不是把整套内部文档都塞给模型。
第三类是做 agent 安全实验的人。Prompt injection、secret exposure、SSRF、shell injection、MCP surface area 都是现实问题。Earl 把这些问题放在一个 Rust CLI 和 HCL 模板系统里，很适合作为小范围实验对象。
Caveats
第一，Earl 仍然是年轻项目。113 stars、7 forks、2026 年 2 月创建，说明它有清晰方向，但还不是被大量团队验证过的基础设施。
第二，模板需要人维护。Earl 把请求结构交还给人类 review，但如果模板本身写得太宽、secret scope 太大、参数校验太弱，风险仍然存在。
第三，Bash 和 browser automation 这类协议天然更敏感。即使有 sandbox、allowlist 和 CI 测试，也应该从低权限环境试起，不要一开始就接生产机器和生产凭证。
第四，它解决的是 external operation boundary，不是 agent reasoning 的正确性。Agent 仍然可能选错 operation、传错参数、误读结果。你还需要 logging、approval gate、least privilege 和普通的 code review。
总结
mathematic-inc/earl 的价值在于，它没有把 agent 安全只当成一句 system prompt。它把外部调用变成 HCL 模板，把 secret 放进 OS keychain，把 MCP tool surface 收束到人类可 review 的 operation 集合里。
如果你已经开始让 agent 查 GitHub、打内部 API、跑 SQL 或执行小段 shell，Earl 值得放进实验列表。它不是万能安全层，但它把一个重要问题问得很具体：agent 可以行动之前，谁来定义行动的边界？