coding agent に外部 system を触らせるとき、難しいのは「request を送れるか」だけではない。「その request の形を誰が決めたのか」が問題になる。Model が API response、auth header、URL template、shell command を同時に見ていると、prompt injection の影響を受けやすく、human が review できる呼び出し境界も残りにくい。

今日見るのは mathematic-inc/earl。Agent の external operation を二層に分ける project だ。Human が operation を HCL template として書き、repository に commit する。Agent が見るのは tool name、description、parameter schema だけ。実行時には Earl が OS keychain から secret を読み、agent が渡した parameter を template に render して、HTTP、GraphQL、gRPC、Bash、SQL などの request を実行する。Claude Code や Cursor などの agent client には MCP server としても出せる。

GitHub repository page、README、release page、tags、latest commit、LICENSE、GitHub API cache、local git clone を 2026-09-05 18:15 Asia/Shanghai 時点で確認すると、mathematic-inc/earl は 113 stars、7 forks。主要言語は Rust、license は Apache-2.0。Default branch は main、repository 作成日は 2026-02-22 09:30:12 UTC、latest push は 2026-09-05 10:00:37 UTC。最新 commit は df2c18e、commit time は 2026-09-05 09:57:45 UTC、message は chore(deps): bump @vitejs/plugin-react from 6.1.0 to 6.1.1 (#106)。最新 GitHub Release は v0.6.3、published time は 2026-08-27 07:20:05 UTC。

プロジェクト概要

項目内容
リポジトリmathematic-inc/earl
位置づけAI agent 向け secure CLI proxy と MCP tool bridge
Stars113
Forks7
主要言語Rust
ライセンスApache-2.0
作成日2026-02-22 09:30:12 UTC
Latest push2026-09-05 10:00:37 UTC
最新 commitdf2c18e、2026-09-05 09:57:45 UTC
最新 Releasev0.6.3、2026-08-27 07:20:05 UTC
インストールcurl install script または cargo install earl
キーワードHCL templates、MCP、OS keychain、prompt-injection、SSRF hardening

呼び出し境界を扱う tool

多くの agent integration はかなり loose に始まる。Token を environment variable に置き、curl や SDK の説明を model に渡し、毎回正しい request を作ることを期待する。Demo では速い。しかし GitHub、Stripe、internal admin API、database につながった瞬間、risk は具体的になる。悪意ある issue comment、API response、web page content が、agent に URL、method、query scope を変えさせたり、secret を output に混ぜさせたりするかもしれない。

Earl の approach は、human が先に template を書くことだ。Template は method、URL、auth、parameters、validation、execution protocol を記述する。Agent は parameter value だけを渡す。README の中核は、LLM が実行される template body を読まないため、外部 response に入った injection instruction が request structure を直接変える場所を持たない、という考え方にある。

これは魔法ではないが、かなり実用的な境界だ。「この agent が何を呼べるか」を chat context から出し、repository の中で review、diff、version pin できる file に変える。Team workflow では、session ごとに model が curl を生成するより、ずっと engineering control plane に近い。

secret を tool parameter にしない

もう一つの現実的な問題は secret propagation だ。MCP tool や script wrapper の作りによっては、model が知りすぎる。Token name、header shape、場合によっては error output に出た credential fragment まで context に入る。

Earl は secret を OS keychain に置き、template から secret reference として読む。Agent call では token を parameter として渡さない。この設計は、GitHub search、issue triage、deployment status、billing read-only endpoint のような SaaS API にも、stable な HTTP、SQL、gRPC interface を持つ internal service にも合う。

もちろん、これは agent に production write permission を渡す理由にはならない。現実的には read-only token、scoped token、staging environment、explicit allowlist から始めるべきだ。Earl は exposure surface を減らす境界であって、最終的な permission system ではない。

HCL は prompt より review しやすい

Earl が HCL template を選んでいるのは面白い。Policy を natural language prompt に押し込むのではなく、operation を config file として置く。Config の利点は review cost が低いことだ。Method、URL、required parameter、secret source、bash sandbox の有無が diff で見える。

Agent workflow ではこの差が大きい。Prompt に書いた「internal address にアクセスしない」は context の中で薄まりやすい。Template と hardening config なら、その rule を execution path の一部に近づけられる。Earl の docs も SSRF protection、egress allowlist、policy engine、environment override、external secrets など、deployment に近い問題を扱っている。

最新 release v0.6.3 自体は infrastructure-only fix で、主に crates.io publication pipeline の修正だ。機能として派手ではないが、project が release reliability を整えていることは分かる。前の v0.6.2 も Bash sandbox path を CI で確実に test する方向に寄っており、v0.5.1 では browser protocol が入っている。Security boundary 系の tool では、release pipeline と sandbox test は周辺作業ではなく、信頼性の一部だ。

向いている人

一つ目は、agent に外部 API を触らせ始めた developer だ。Full platform までは要らなくても、「許可された operation」を ad hoc prompt ではなく review 可能な file にしたい場面がある。

二つ目は internal tooling team だ。内部 API は public SDK がなくても、HTTP、SQL、gRPC の interface は安定していることが多い。Earl は agent に小さく明確な operation set を渡せる。内部 docs を丸ごと model に渡すより扱いやすい。

三つ目は agent security を実験している人だ。Prompt injection、secret exposure、SSRF、shell injection、MCP surface area はすでに現実の問題になっている。Earl はそれらを Rust CLI と HCL template system の中にまとめており、小さく試しやすい。

Caveats

第一に、Earl はまだ若い project だ。113 stars、7 forks、2026 年 2 月作成という規模なので、方向は明確だが、広く検証された infrastructure ではない。

第二に、template は人間が保守する必要がある。Earl は request structure を human review に戻すが、template が広すぎる、secret scope が大きすぎる、parameter validation が弱いなら、risk は残る。

第三に、Bash や browser automation の protocol はそもそも sensitive だ。Sandbox、allowlist、CI test があっても、まず low-privilege environment で試すべきだ。いきなり production machine や production credential に接続する tool ではない。

第四に、Earl が扱うのは external operation boundary であり、agent reasoning の正しさではない。Agent は今でも wrong operation を選び、wrong parameter を渡し、result を誤読することがある。Logging、approval gate、least privilege、普通の code review は引き続き必要になる。

まとめ

mathematic-inc/earl の価値は、agent security を system prompt の一文だけで済ませていない点にある。External call を HCL template にし、secret を OS keychain に置き、MCP tool surface を human が review できる operation set に絞る。

すでに agent に GitHub を検索させたり、internal API を叩かせたり、SQL や小さな shell task を実行させたりしているなら、Earl は実験リストに入れる価値がある。万能の安全層ではない。それでも重要な問いをかなり具体化している。Agent が action を取る前に、その action の境界は誰が定義するのか。

プロジェクトアドレス：https://github.com/mathematic-inc/earl