結論から言います。AIエージェントに平文のAPIキーを渡すのは、できるだけやめる方が安全です。個人開発のCLIツール「trustless」は、その一点だけに絞った道具です。エージェントには「キー名」だけを知らせ、値はpassやBitwardenなどの外部brokerからプロセス起動時にだけ解決して子プロセスに注入する。設定ファイルにも会話ログにも平文を残さない、という発想です。中小企業が今エージェント導入で必ず引っかかる「APIキーの置き場所問題」に、構造で答えようとしている点が要点です。
なお最初に立場を明かします。この記事を書いている株式会社TOE（AIの鬼）は、AI検索対策やAI導入支援を仕事にしうる利害関係者です。そのうえで、素材と当社の実測から言えることだけを書きます。
エージェントに渡したキーは、なぜ回収できないのか
素材の記事が挙げている問題はシンプルです。AIエージェントにAPIキーを一度渡すと、その瞬間から複数の漏洩経路が開き、しかも回収できない、という点です。
MCP（Model Context Protocol）を使うと、claude_desktop_config.jsonや.mcp.jsonのenvにGITHUB_TOKENを平文で書く、あるいはStreamable HTTPならheadersにAuthorization: Bearer sk-...を書く、という形にほぼ必ず行き着きます。素材によれば、この瞬間からキーは3箇所に残ります。
| 残る場所 | どう漏れるか |
|---|---|
設定ファイル（.mcp.json等のenv/headers） |
git add .でリポジトリに乗る／スクショ・画面共有で漏れる |
| 起動されたMCPサーバのプロセス環境変数 | エージェントがecho $GITHUB_TOKENを実行すれば出力に載る |
| ツール出力→エージェントのコンテキスト | 会話履歴・ログ・プロバイダ側のリクエストログに入る |
さらに素材は、prompt injectionで「envを全部表示して」と指示されればエージェントは素直に従うかもしれない、と書いています。一度渡したキーはもう回収できない。素材の筆者は「2ヶ月ほど自分の環境でエージェントを常時動かして、この回収不能が一番の不安だった」と述べています。だから「保管」ではなく「そもそも渡さない」側に倒した、という経緯です。
trustlessは何をして、何をしないのか
trustlessの設計判断は3つに絞られています。素材から読み取れる範囲で整理します。
- 外部依存は1つだけ。
github.com/pelletier/go-toml/v2のみ（pure Go）。CGO_ENABLED=0で単一静的バイナリのまま配布できる。素材は「ゼロ依存とは謳わない。1つある、と正直に書く」としています。 - エージェントはキー名だけを知る。
trustless run -s my/api-key -- <cmd>とすると、値はbroker（pass/env/bitwarden）から解決して子プロセスにだけ渡す。標準出力は行単位でパターンマッチし[REDACTED]に置換してから返す。--scan-argsで引数への平文混入を起動前に検査し、失敗させる（exit 3, fail closed）。 - 注入経路は2つ。STDIO型は
trustless runやtrustless mcpで子プロセスのenvにだけ注入。HTTP型はtrustless proxy startでHTTPS_PROXY経由のリクエストにヘッダやクエリを注入する。どちらも設定ファイルにはキー名だけが残り、値はプロセスメモリにだけ一時的に存在します。
正直な限界も素材に書かれています。ここが中小企業にとって重要です。
- プロセス境界を越える万能薬ではない。子プロセスのメモリを読める権限があれば値は読める。守れるのは「ファイル・ログ・会話履歴に平文を残さない」「エージェントのコンテキストに載せない」まで。
- 依存はゼロではない（
go-toml/v2が1つ）。 - HTTPの
CONNECTは素通しで、--mitmを付けたときだけ自前CAで終端してヘッダ注入する。素通しでは中身は見えない。 - DLPのLayer 2はエントロピー閾値判定なので、取りこぼしも誤検出もあり得る。
中小企業にとって何が変わるのか
素材は個人開発者の技術記事です。ですが、中小企業の情報システム担当が読むと意味合いが変わります。
第一に、これは「キーを守る新しい金庫」ではなく「金庫から出したキーの渡し方」を変える道具です。素材も「既存のpass/Bitwardenを捨てる必要はない」「trustless runとtrustless proxy`を噛ませるだけ」と書いています。VaultやSecrets Managerに入れても、最後にエージェントへ平文で渡すなら詰めが甘い、という指摘は、すでに秘密情報管理を始めた企業ほど刺さります。
第二に、夜間にエージェントを走らせる運用の話です。素材は「朝に目が覚めた時のサプライズは数万円の課金だけ、という事態は避けたい」と書きます。キー漏洩は課金だけでは済みません。AIエージェントを常時動かすなら、コスト面でも権限面でも「渡さない選択肢」を初期段階で持っておく価値があります。AIエージェントが既存ツールを操作する運用そのものについては、既存ツールをそのまま使いながらAIが画面を操作する時代──Grok Botは中小企業の「システム刷新」問題を解くのかでも扱っています。運用コストの変動という論点はAIコンピュート費用が「固定」から「変動」へと地続きです。
第三に、当社の運用と突き合わせます。AIの鬼では社内業務の自動化を27本走らせ、AI秘書のブリーフィングを毎朝8:00に受け取っています。それでも運用中のAI API課金は0円です。つまり「エージェントを常時動かす＝高い課金と広いキー露出」が必然ではない、という一例です。ただしこれは当社の構成でそうなっているだけで、trustlessを使えば同じになる、という意味ではありません。当社はtrustless自体を導入・検証していません。
この記事で言えないこと
- trustlessの効果を当社は測っていません。 漏洩がどれだけ減るか、導入がどれだけ壊れにくいかは、当社では未検証です。
- 素材にある「起動オーバーヘッドは数ms〜十数ms」「バイナリは数MB台」「1ヶ月常時運用で平文が残る機会はゼロになった」は、いずれも素材の筆者の手元環境（Linux aarch64, Go 1.26）での数字です。当社が再現した数字ではありません。
- 同じ出来事を扱った他社の報道は0件でした。したがって数字や主張を突き合わせて検証することはできず、素材1本に依存しています。この点は割り引いて読んでください。
- trustlessが本番運用に耐えるか、どのMCPサーバと相性が良いかは、素材からは分かりません。
- 中小企業がこれを導入すべきか否かの一般的な結論は、当社では測っていません。自社の構成・権限設計に依存します。
まとめ
- AIエージェントに平文のAPIキーを渡すと、設定ファイル→プロセス環境変数→会話履歴の順に漏洩面が広がり、一度渡すと回収できない、というのが素材の出発点です。
- trustlessは「エージェントはキー名だけを知り、値は起動時にだけbrokerから注入する」一点に絞ったCLIで、外部依存は
go-toml/v21つ・単一静的バイナリです。 - 守れるのは「ファイル・ログ・会話履歴に平文を残さない」まで。プロセスメモリを読める権限があれば値は読める、と素材自身が限界を明記しています。
- 中小企業の実務では「新しい金庫」ではなく「渡し方を1つずらす」道具として読むのが正確です。まずは手元の
.mcp.jsonのenv/headersに平文が残っていないかの確認から始められます。 - 当社はtrustlessを検証しておらず、効果は測っていません。他社報道0件で突き合わせもできないため、素材1本への依存を承知のうえで読んでください。
この記事はZenn AIの記事「AIエージェントにAPIキーを渡さない — trustlessを作った理由」を素材に、当社（株式会社TOE / AIの鬼）の自動化27本・AI API課金0円という運用実測とあわせて書きました。
