AIエージェントに平文のAPIキーを渡すのはやめる、という一点だけを実装した個人開発のCLIがあります。「trustless」は、エージェントにはキー名だけを知らせ、値は外部のbroker（pass・Bitwarden・環境変数）からプロセス起動時にだけ解決して子プロセスに注入し、標準出力は行単位でマスクします。外部依存はgithub.com/pelletier/go-toml/v2の1つ、配布は単一静的バイナリ。中小企業がエージェント導入で最後に必ず詰まる「APIキーをどこに置くか」を、保管ではなく渡し方の側で埋める道具です。以下、素材から読み取れることだけを整理します。

なお、この記事を書いている株式会社TOE（AIの鬼）は、AI導入支援・AI検索（AEO）対策を事業として売りうる立場です。利害のある側が書いている前提で読んでください。

何が起きたか ― 「渡したキーは回収できない」を出発点にした

素材はZenn AIに2026-08-20に公開された、作者本人による解説記事です。今回、同じ出来事を扱った他社の報道は0件でした。つまり第三者による検証や反論は現時点で見つからず、記事の内容はすべて作者の主張として読む必要があります。この点は最初に断っておきます。

作者の出発点は単純です。MCP（エージェントが外部ツールに接続する仕組み）を使うと、設定ファイルのenvやheadersにトークンを平文で書くところに必ず行き着く。いったん書くと、キーは3箇所に残ります。

残る場所 具体例 漏れ方
設定ファイル .mcp.json / claude_desktop_config.json の env・headers git add . でリポジトリに乗る、スクショ・画面共有
プロセス環境変数 起動したMCPサーバの環境変数 メモリを読める権限があれば取得可能
会話履歴・ログ ツール出力がエージェントのコンテキストに入る prompt injectionで「envを全部表示して」に従う

一度渡したキーはもう回収できない ― これが作者が2ヶ月ほどエージェントを常時動かして感じた一番の不安であり、「そもそも渡さない」側に倒す動機になった、と書かれています。

trustlessは何をどう変えるのか

設計判断は3つに絞られています。

  1. 外部依存は1つだけ。go-toml/v2だけ（config.tomlとDLPのrules.tomlのパースに使用）。pure GoなのでCGO_ENABLED=0で単一静的バイナリのまま配れる。「ゼロ依存」とは謳わず「1つある」と正直に書いている点が特徴です。
  2. エージェントはキー名だけを知る。trustless run -s my/api-key -- <cmd>で、値はtrustlessがbackendから解決して子プロセスにだけ渡す。標準出力は行単位でパターンマッチし[REDACTED]に置換。--scan-argsで引数への平文混入を起動前に検査し、混ざっていれば失敗する（exit 3, fail closed）。
  3. 注入経路を2つ用意する。STDIO型はtrustless mcp -- npx -y <server>で子プロセスのenvに注入。HTTP型はtrustless proxy start --port 8080とし、HTTPS_PROXY経由のリクエストにヘッダやクエリを注入する。

どちらの経路でも、設定ファイルに残るのはキー名だけで、値はプロセスメモリに一時的に存在するだけになります。既存のpassやBitwardenを捨てる必要はなく、保管はそのまま、渡し方だけを差し替える構成です。

中小企業にとって何が変わるのか

中小企業がエージェント導入でつまずくのは、たいてい高度なモデル選定ではなく、この「キーの置き場所問題」です。VaultやSecrets Managerに入れても、最後にエージェントへ平文で渡すなら意味がない ― 素材のこの指摘は、情シス担当が実際に直面する詰めの甘さを言い当てています。

trustlessの発想を借りるなら、明日からでも確認できることが2つあります。素材が最後に勧めているのも、まさにこの2点です。

  • 手元のclaude_desktop_config.jsonと.mcp.jsonを開き、envとheadersに平文が残っていないか確認する。
  • キーは用途ごとにスコープを絞って1つずつ発行する。1つのキーを全MCPで使い回すと、1プロセスの侵害で全部が漏れる。

夜間にエージェントを走らせる運用では、朝のサプライズが数万円の課金だけで済むか、キー漏洩まで含むかで被害の桁が変わります。当社（AIの鬼）でも社内業務の自動化は27本動いており、AI秘書のブリーフィングは毎朝8:00に自動で回っていますが、運用中のAI API課金は現時点で0円です。課金が発生する構成に踏み込む前に「キーを渡さない」選択肢を用意しておく、という順番は、コストの面でも理にかなっています。ただし、これは当社が課金ありのエージェント運用で漏洩を防げたという話ではありません。そこはまだ測っていません。

なお、prompt injectionでキーを吐かせるという攻撃経路については、Gartner（2026年5月・n=645）でBtoB購買担当者の51%がAIで誤情報に遭遇したという調査があるように、AIの出力が指示に素直に従ってしまう性質は広く観測されています。trustlessはその「素直さ」を前提に、そもそも見せないという構造で対処しています。

できないこと ― 素材が正直に書いている限界

作者自身が限界を明記しているのは、AEOを名乗る当メディアから見ても誠実な書き方です。

  • プロセス境界を越える万能薬ではない。子プロセスのメモリを読める権限があれば値は読める。守れるのは「ファイル・ログ・会話履歴に平文を残さない」「エージェントのコンテキストに載せない」まで。
  • 依存はゼロではない。go-toml/v2が1つある。
  • HTTPのCONNECTは素通し。--mitmを付けた場合のみ自前CAで終端してヘッダ注入する。
  • DLPのパターン検出は確率的。Layer 1（既知の値の部分一致）は確実だが、Layer 2（gitleaks互換の正規表現＋エントロピー閾値）は閾値次第で取りこぼしも誤検出もある。

この記事で言えないこと

  • 第三者による検証結果。同じ出来事の他社報道は0件で、動作や安全性を独立に確かめた報告は素材からは見つかりません。作者の主張として読むしかありません。
  • 導入効果の数値。「漏洩がどれだけ減るか」を示す実測は素材になく、当社も測っていません。素材にある「鍵の平文を.mcp.jsonや会話ログに残す機会はゼロになった」という記述も、作者1名の1ヶ月の運用感想であって、効果の保証ではありません。
  • 他ツールとの優劣。VaultやSecrets Managerと比べてどちらが安全かは、条件次第で当社は比較検証していません。
  • 当社での再現。trustlessを当社環境で動かした実測はありません。上記の課金0円・自動化27本は当社の別の運用実績であり、trustlessの効果ではありません。
  • 起動オーバーヘッドの一般値。素材の「数ms〜十数ms」は作者環境（Linux aarch64, Go 1.26）の目安で、環境で変動すると明記されています。

まとめ

  • trustlessは「エージェントにキー名だけ知らせ、値は起動時にだけ注入する」一点に絞った個人開発のCLIで、外部依存はgo-toml/v2の1つ、配布は単一静的バイナリです。
  • APIキーは「設定ファイル→プロセス環境変数→会話履歴」の順に広がり、一度渡すと回収できない ― これが設計の出発点です。
  • 中小企業がまず確認できるのは、.mcp.jsonとclaude_desktop_config.jsonのenv・headersに平文が残っていないか、そしてキーを用途ごとに1つずつ発行しているか、の2点です。
  • 作者は限界も正直に書いています。プロセスメモリを読める攻撃者は防げず、依存はゼロではなく、CONNECTは素通し、パターン検出は確率的です。
  • 同件の他社報道は0件、当社の再現実測もありません。効果は保証できず、「渡さない」という選択肢を早い段階で持っておくことの意味だけが、素材から確かに言えることです。

関連して、AIエージェントに渡したAPIキーは回収できない ― 中小企業は「渡さない」を最初に選べるのか？と、夜間課金のサプライズに触れたAIコンピュート費用が「固定」から「変動」へ──GPU先物市場が動き出すと中小企業のAIコスト計画はどう変わるのかも併せてお読みください。既存ツールを使いながらAIに操作させる文脈では既存ツールをそのまま使いながらAIが画面を操作する時代──Grok Botは中小企業の「システム刷新」問題を解くのかも参考になります。

この記事は、Zenn AIに公開された「AIエージェントにAPIキーを渡さない — trustlessを作った理由」を素材に、当社（株式会社TOE／AIの鬼）の運用実測（社内自動化27本・AI秘書の毎朝8:00ブリーフィング・AI API課金0円）と、Gartner（2026年5月・n=645）の調査とあわせて書きました。