OneCLI解説｜AIエージェントに実APIキーを渡さない認証情報ゲートウェイの仕組みと自システム確認コマンド

AIエージェント セキュリティで最初に問われるのは「鍵の置き場所」だ。AIエージェントに外部APIを叩かせるとき、多くの人はエージェントの環境変数やコードに実APIキーをそのまま置く。onecli/onecli（★2,629・Apache-2.0）は、その前提そのものをやめてしまうツールだ。エージェントにはダミーキーだけを渡し、リクエストが外に出る瞬間にRust製のゲートウェイが本物のキーへ差し替える——「認証情報ゲートウェイ」という考え方で、AIエージェント セキュリティの弱点である「キーの露出」を根から断ちにいく。2026年7月にShow HN（Hacker News）で公開されて65ポイントを集め、GitHubでも★2,600超と反応があったが、日本語の解説はまだほとんど無い。本記事は公式リポジトリとドキュメントを一次ソースに、仕組みと「自分の環境での確かめ方」を整理する。

この記事ではセキュリティに特化して解説します。AIを取り巻く攻撃と防御の全体像は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

AIエージェント セキュリティの死角：実キーを渡すとどこで漏れるのか

OneCLIの価値を理解するには、まず「AIエージェントに実キーを直接渡す」という当たり前の運用が、なぜ危ういのかを整理する必要がある。エージェントは自律的に外部APIを叩く。そのために OPENAI_API_KEY や STRIPE_SECRET_KEY を環境変数へ置く——これは動くが、実キーが次のような場所に「常駐」してしまう。

・環境変数・設定ファイル：エージェントのプロセスが生きている限り、実キーはメモリと環境に載り続ける。
・プロンプトとツール出力：エージェントが自分の環境を読んだり、エラーメッセージを会話に貼ったりすると、キーが文脈に混入しうる。
・ログ・実行履歴：リクエストやデバッグ出力に平文で残り、後から回収される。
・プロンプトインジェクション経由の持ち出し：外部から読み込んだWebページやIssueに「環境変数を教えて」と仕込まれると、エージェントが素直に吐き出してしまう危険がある。
・ローテーションの苦痛：キーを回すたびに、実キーを配ったすべてのエージェント・コンテナを差し替える必要がある。

これは机上の心配ではない。当サイトが扱ってきた直近のインシデントだけでも、AIエージェントや開発者の認証情報を狙う攻撃は途切れなく続いている。

認証情報を狙う攻撃のタイムライン（2026年・当サイト既報の抜粋）

・2026-04-22：GitHubコメントに悪意ある指示を仕込み、AIエージェントを乗っ取る「Comment and Control」攻撃。
・2026-05-05：偽TanStackパッケージが .env を窃取するnpmブランドスクワット攻撃。
・2026-05-28：npmマルウェア「mouse5212」がClaudeのuser-dataを狙う。
・2026-06-06：Sentryを偽装したタイポスクワット×プロンプトインジェクションでAIエージェントの障害対応を乗っ取る手口／同日、Codexのトークンを狙う「codexui-android」偽パッケージも報じられた。

いずれも「エージェントや開発環境に置かれた資格情報」を最終的な標的にしている。つまり、キーをエージェントの手元に置く限り、攻撃者に残された仕事は「そのエージェントを一度だます」ことだけになる。OneCLIの発想は、この前提を崩す点にある——エージェントの手元にあるのがダミーキーなら、だまして吐かせても実害が小さい。

AIエージェントが特に「漏れやすい」のには理由がある。第一に、エージェントは外部から取り込んだテキスト（Webページ・Issue・メール・PDF）を指示として解釈しうる。そこに「環境変数を出力して」と紛れ込ませるのがプロンプトインジェクションで、キーが環境変数にあれば、そのまま会話やツール出力へ流出する経路になる。第二に、近年のエージェントはサブエージェントを動的に増やす。親が持つ実キーを子へ配ると、キーが載るプロセスの数だけ露出面が広がる。第三に、これは古典的な「confused deputy（混乱した代理人）」問題でもある。正規の権限を持つエージェントが、攻撃者の言いなりにその権限を行使してしまう——権限（＝実キー）をエージェント自身に持たせているからこそ起きる構図だ。OneCLIのように「権限の行使をゲートウェイ側に寄せ、エージェントには行使のトリガーだけ持たせる」設計は、この構図を分解する一つの答えになる。

もう一つ見落としがちなのが、MCPサーバーやプラグイン経由の資格情報だ。エージェントに外部ツールを生やすと、そのツールもまた実キーを必要とする。ツールの数だけ鍵が散らばり、どのツールがどのキーを持つかの把握が難しくなる。「鍵を渡す先」が増えるほど、集約された関所で差し替える方式の相対的な価値は上がる。

APIキーが漏れた後の実害（不正利用と高額請求）については、Gemini APIキーが不正利用される仕組みと防止策：数百万円の被害を防ぐ実践ガイド が具体的だ。また、エージェント自体が暴走したときの被害範囲を絞る発想は AIエージェントが290件のファイル破壊インシデントを起こす理由とYoloFSが示す解法 と同じ系譜にある。OneCLIは「キーを渡さない」ことで、この被害範囲をさらに狭めにいく。

OneCLIの仕組み：ダミーキーを本物に差し替えるRust製ゲートウェイ

OneCLIは公式に「Store once. Inject anywhere. Agents never see the keys.（一度保存すれば、どこにでも注入できる。エージェントはキーを見ない）」と掲げる。READMEの説明を要約すると、動作は次のとおりだ。

実の資格情報はOneCLIに一度だけ保存し、エージェントには本物ではなくプレースホルダ（ダミーキー）を渡す。エージェントがゲートウェイ経由で外部APIを呼ぶと、ゲートウェイはリクエストを対応する資格情報に照合し、FAKE_KEY を REAL_KEY へ差し替え、復号して外向きリクエストに注入する。エージェントは普通のHTTP呼び出しをするだけで、差し替えはゲートウェイ側で完結する——という設計だ。この流れを図にすると次のようになる。

この仕組みを支えるのが、役割の異なる3つのコンポーネントだ。リポジトリは主要言語こそTypeScriptだが、実際にリクエストを傍受して差し替えるゲートウェイ本体はRustで書かれている（GitHub APIの言語内訳で Rust が約88万バイトを占める）。

・Rustゲートウェイ（ポート10255）：外向きのHTTPリクエストを傍受し、資格情報を注入する高速なゲートウェイ。エージェントは Proxy-Authorization ヘッダのアクセストークンで認証する、とされる。HTTPSについては中間者（MITM）方式で傍受する、と明記されている。
・Next.js管理画面（ポート10254）：エージェント・シークレット・権限を管理するダッシュボード。ゲートウェイが「どの資格情報を注入すべきか」を解決するためのAPIも提供する。
・暗号化シークレットストア：AES-256-GCMで暗号化して保管し、送信時のみ復号する、とされる。資格情報はホストとパスのパターンで照合され、ヘッダまたはURLのクエリパラメータとして注入される。

もう一つの特徴が、エージェントごとに固有のアクセストークンを発行し、スコープ付きの権限を割り当てられる点だ。公式説明では、これによって「ブログ執筆エージェントはXのAPIだけ」「経理エージェントは決済APIだけ」といった具合に、エージェント単位で叩けるサービスを絞れる。実キーを配って回る運用では難しかった「最小権限」を、ゲートウェイ側で一括管理できるのが利点だとされる。

なお、パスワードマネージャー連携（Bitwarden等）を使うと、資格情報をサーバに保存せず必要な時だけ取り出して注入する構成も選べる、とREADMEには記載がある。手元に秘密を持ちたくない組織向けのオプションだ。

差し替えの「宛先の正しさ」を担保するのが、ホストとパスのパターンマッチングだ。READMEによれば、資格情報はホストとパスのパターンで照合され、一致したリクエストにだけ注入される。つまり「api.openai.com 宛のときはOpenAIのキー」「api.stripe.com 宛のときはStripeのキー」といったルールを持ち、無関係なホスト宛のリクエストに誤ってキーを差し込まない設計だ。注入の形式は、APIの流儀に合わせてヘッダ（Authorization: Bearer ... 等）またはURLのクエリパラメータのどちらかを選べる、とされる。多くのモダンなAPIはヘッダ方式だが、レガシーなAPIはクエリにキーを載せるものもあるため、両対応は実務的だ。逆に言えば、このマッチングルールの設計を誤ると「本来キーを注入すべきでない宛先に注入してしまう」事故にもつながりうるため、ホスト・パスの指定はできるだけ具体的に絞るのが安全だ。

権限の絞り込みを具体化するとこうなる。たとえば「SNS投稿エージェント」にはX APIのキーだけを解決できるトークンを、「経理エージェント」には決済APIのキーだけを解決できるトークンを発行する。片方のエージェントがプロンプトインジェクションで乗っ取られても、そのアクセストークンで引き出せるのは割り当てられたサービスだけで、他方のキーには手が届かない。実キーを各エージェントに配る運用では、この「エージェント単位の最小権限」を徹底するのは難しかった。ゲートウェイに権限判断を寄せることで、キーの棚卸しとローテーションも管理画面の1か所で完結する、というのがOneCLIの主張だ。

ゲートウェイ本体をRustで書いている点は、セキュリティ観点でも理にかなっている。ゲートウェイはすべてのエージェントの全リクエストが通るホットパスであり、かつ復号した実キーを一時的に扱う、最も守るべき部品だ。ここでC/C++のようなメモリ安全性の保証がない言語を使うと、バッファオーバーフロー等のメモリ破壊がそのまま秘密の漏洩につながりうる。Rustはコンパイル時にメモリ安全性を保証し、実行時オーバーヘッドも小さいため、「速く、かつ壊れにくい傍受層」を作る土台になる。管理画面のようにリッチなUIが要る部分はNext.js（TypeScript）で、鍵に触れる中核はRustで——という言語の使い分けは、露出面の大きさに応じた合理的な設計だと言える。

導入手順：DockerでOneCLIを起動しAIエージェントを接続する

OSSのセルフホスト版は、Dockerで起動できる。READMEのクイックスタートは大きく2通りだ。

# 方法A：ワンライナーのインストーラ（アプリ＋PostgreSQLを一括起動）
curl -fsSL https://onecli.sh/install | sh

# 方法B：リポジトリを clone して docker compose で起動
git clone https://github.com/onecli/onecli.git
cd onecli
docker compose -f docker/docker-compose.yml up -d --wait

起動後は管理画面（http://localhost:10254）でエージェントを作成し、シークレットを登録して、エージェントのHTTPゲートウェイを localhost:10255 に向ける。クイックスタートはローカルモード（単一ユーザー・ログイン不要）で動くため、.env や NEXTAUTH_SECRET は不要だとされる。複数人で使う場合は NEXTAUTH_SECRET とGoogleの資格情報を設定してGoogle OAuthを有効化する。

エージェント側の接続は、公式ドキュメントによると、Node.js SDKがコンテナへ HTTPS_PROXY とCA証明書を適用する形で行われる。つまりエージェントの実行環境に対して、

・プロキシ設定：外向きHTTP(S)をゲートウェイ（localhost:10255）に向ける（HTTP_PROXY / HTTPS_PROXY）。
・CA証明書の信頼：HTTPSの中身を差し替えるため、エージェント側でOneCLIのCA証明書を信頼する（MITM方式）。
・アクセストークン：Proxy-Authorization ヘッダでエージェントを識別する。

という3点を設定する、とされる。アプリのコードは「普通にAPIを叩く」ままでよく、鍵の差し替えは外側で起きる——というのがOneCLIの狙いだ。

管理画面（localhost:10254）での流れは、README準拠で整理すると「①エージェントを作成する → ②そのエージェントに使わせたいシークレット（実キー）を登録し、ホスト／パスのルールを紐づける → ③エージェント用のアクセストークンを発行する」という3ステップになる。発行したトークンをエージェント側の Proxy-Authorization に設定すれば、あとはエージェントがゲートウェイ越しにAPIを叩くたび、対応する実キーが注入される。ローカルモードならログイン不要でこの一連を試せるため、まずは1エージェント・1サービスで挙動を掴むのがよい。

具体例で流れを追うと分かりやすい。「ブログ執筆エージェントにX（旧Twitter）へ投稿させたい」とする。従来なら、エージェントの環境変数にXのアクセストークンを実物で置き、エージェントがそれを使って投稿APIを叩く。OneCLIでは、実物のXトークンを管理画面に登録し、api.x.com 宛のリクエストに注入するルールを作る。そしてブログ執筆エージェントには、Xの資格情報だけを解決できるアクセストークンと、ダミーのXキーを渡す。エージェントは「ダミーキーでXに投稿する」つもりでリクエストを送るだけで、ゲートウェイが送信時に本物へ差し替える。もしこのエージェントが、読み込んだ記事に仕込まれた指示で暴走しても、手元にあるのはダミーキーであり、かつトークンのスコープはX以外に及ばない——被害の広がり方が変わるのが分かる。

導入したら「本当に差し替わっているか」を確かめたい。安全な確認方法は、あえて壊れたダミーキーを持たせて、実際のAPI呼び出しが成功するかを見ることだ。エージェントの環境には明らかに無効なダミー値（例：FAKE_KEY）しか置かず、それでも外部APIが 200 を返すなら、ゲートウェイが送信時に実キーへ差し替えている強い証拠になる。逆に、ダミーキーのまま 401 Unauthorized が返るなら、リクエストがゲートウェイを経由していない（プロキシ設定が効いていない）可能性が高い。ここで実キーをエージェントに置いてしまうと確認の意味が無くなるので、確認中もダミーキーのままにするのがコツだ。

自分の環境でAIエージェントのキー漏れを点検する確認コマンド

ここが当サイトの本題だ。OneCLIを入れる前でも入れた後でも、「実キーが本当に漏れていないか」を自分の環境で確かめられなければ意味がない。以下はあなたの環境で実行して確認するためのコマンド例で、出力は環境によって異なる。ここに架空の結果は載せない——実際に手を動かして目で確かめてほしい。

まず、エージェントのプロセスやシェルに実キーが載っていないかを見る。

# ① エージェントの環境変数に実キーらしき値が載っていないか
printenv | grep -iE 'API_KEY|SECRET|TOKEN|PASSWORD' 

# ② 実行ログ・作業ディレクトリに平文のキーが残っていないか
#    （sk- で始まるOpenAI系や、一般的なキー表記を横断検索）
grep -rInE 'sk-[A-Za-z0-9]{20,}|api[_-]?key|secret' ./logs ./.cache 2>/dev/null | head

# ③ うっかりコミットに混入していないか（履歴も含めて確認）
git log -p -S 'API_KEY' -- . | grep -iE 'api_key|secret' | head

OneCLI導入後は、「エージェントが持っているのがダミーキーだけか」を確認する。ダミーキーだけが載り、実キーが printenv に出てこなければ、分離が効いている一つの目安になる（ただしこれは動作確認であって、全経路の保証ではない）。

# ④ 導入後：エージェント側にダミーキーだけが載っているか
printenv | grep -iE 'API_KEY|TOKEN'   # FAKE_KEY 相当だけが見える状態が理想

# ⑤ ゲートウェイの待受を確認（外部公開されていないか）
lsof -iTCP:10255 -sTCP:LISTEN 2>/dev/null || ss -tlnp | grep -E '10254|10255'

さらに、ゲートウェイ自体が意図せず外部に開いていないかは、Dockerのポート公開を見れば分かる。0.0.0.0 にバインドされていると、LAN内の別ホストから叩けてしまう。localhost（127.0.0.1）へのバインドに絞れているかを確認したい。

# ⑥ ゲートウェイと管理画面が localhost だけに開いているか
docker ps --format '{{.Names}}\t{{.Ports}}' | grep -E '10254|10255'
#   → 0.0.0.0:10255 のように出たら、外部公開されている合図。
#     127.0.0.1:10255 に絞れているのが望ましい。

HTTPSを傍受する構成では、信頼させたCA証明書の範囲も点検対象だ。OneCLIのCA証明書がOS全体の信頼ストアに入っていると、そのマシンのあらゆるHTTPS通信をゲートウェイが復号しうる状態になる。理想は「そのエージェントの実行環境（コンテナや専用ユーザー）だけが信頼する」形だ。macOSやLinuxなら、システムの信頼ストアに見慣れない中間CAが増えていないかを確認しておきたい。

# ⑦ OneCLI由来のCA証明書がOS全体に入り込んでいないか（例）
#    Linux: 信頼ストアの一覧に onecli / mitm 系の名前が無いか確認
awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{c=cmd} {print | c} /END/{close(c)}' \
  /etc/ssl/certs/ca-certificates.crt 2>/dev/null | grep -iE 'onecli|mitm|proxy' || echo "OS信頼ストアに該当なし（望ましい）"

# ⑧ ゲートウェイと同じDockerネットワークにAPIキーを持つ他コンテナが同居していないか
docker network inspect bridge --format '{{range .Containers}}{{.Name}} {{end}}'

これらは特別なツールを必要とせず、標準のシェルとDockerだけで走る。OneCLIを評価する前に①〜③で「今どれだけキーが露出しているか」を把握し、導入後に④〜⑧で「本当に分離できたか・信頼範囲は広がりすぎていないか」を確かめる、という二段構えが実務的だ。どの環境でも同じ結果になるとは限らないので、必ず自分の環境で実行し、出力を自分の目で確認してほしい。

OneCLIが守る範囲と守らない範囲：影響範囲マトリクスで理解する

セキュリティツールを正しく使う鍵は、守ってくれない範囲を正確に知ることにある。OneCLIも例外ではない。公式の売り文句は魅力的だが、構造上、次の3層で「効き方」が変わる。

・守れること：ゲートウェイを経由するHTTP(S) APIの呼び出しについては、エージェントの文脈から実キーを分離できる、とされる。エージェント別のアクセストークンで権限を絞り、実キーは暗号化して一元管理・ローテーションできる。
・条件付き（HTTPSの傍受）：HTTPSの中身を差し替えるには、エージェント側でOneCLIのCA証明書を信頼する必要がある。これは中間者方式であり、ゲートウェイがそのエージェントのHTTPS通信を復号できることを意味する。信頼するCA証明書を「そのエージェント実行環境だけ」に閉じ込められるかが安全性を左右する。
・守らない（対象外）：ゲートウェイを経由しない直接通信、SSH鍵や非HTTPプロトコル、そしてゲートウェイ自身の侵害は範囲外だ。すべての実キーが1か所（暗号化ストア）に集まる以上、ゲートウェイは高価値な単一障害点になる。ここが破られれば影響は大きい。

特に「影響範囲」として意識したいのが、暗号鍵と公開範囲だ。READMEでは SECRET_ENCRYPTION_KEY（AES-256-GCMの暗号鍵）は未指定なら自動生成されるとある。自動生成は手軽だが、その鍵がどこに保存され、誰が読めるかを把握していないと、暗号化ストアの意味が薄れる。暗号化は「保管時（at rest）」を守るもので、鍵そのものが漏れれば復号されうる。加えて、資格情報は送信の瞬間に復号・注入される以上、その瞬間のゲートウェイのメモリには平文の実キーが載る。ここを踏まえると、ゲートウェイのホスト自体の保護（OSの堅牢化、不要ポートの閉塞、監査ログ）が、暗号化と同じくらい重要になる。またローカルモードはログイン不要で便利な反面、認証が無い状態でもある。評価用ローカル環境と、チーム・本番の運用は分けて考えるべきだ。

被害範囲（blast radius）の観点でも整理しておきたい。実キーを各エージェントに配る従来方式は、1エージェントが漏れても被害はそのエージェントが持つキーに限られる（分散しているぶん、把握はしづらいが被害は局所的）。対してOneCLIは鍵を1か所に集約するため、個々のエージェントの漏洩には強いが、ゲートウェイ本体の侵害には弱い——トレードオフの向きが変わる。したがってOneCLIは「これさえ入れれば安全」という銀の弾丸ではなく、多層防御（defense in depth）の一枚として使うのが正しい。ゲートウェイの前段でネットワークを絞り、暗号鍵を安全に保管し、エージェント側の権限も最小化する——複数の層が揃って初めて、集約の利点を安全に享受できる。「守らない範囲」を各層で埋めていく発想が要る。

OneCLIが向く場面と、まだ様子見が無難な場面

「何ができるか」だけでなく「自分の状況で使うべきか」を判断できるよう、向き・不向きを整理しておく。読者が知りたいのは、結局このツールが自分の課題を解決するのか、という点だからだ。

向いているのは、次のような状況だと考えられる。

・複数のAIエージェント／サブエージェントに、複数の外部APIを叩かせている。鍵の配布先が多いほど、集約して差し替える方式の恩恵が大きい。
・プロンプトインジェクションで実キーが抜かれる経路を、構造的に塞ぎたい。エージェントの手元をダミーキーにするのは、この目的に直接効く。
・エージェント単位で「叩けるサービス」を絞りたい。アクセストークンにスコープを持たせられるため、最小権限を実装しやすい。
・キーのローテーションを1か所で回したい。実キーを配って回る運用の手間を、ゲートウェイに寄せられる。

一方で、次のような場合はまだ様子見が無難だ。

・エージェントが1つ・APIが1つだけなら、ゲートウェイを立てるより、環境変数の管理と監査を丁寧にやる方が軽いこともある。
・HTTPSのMITMを組織のポリシー上入れられない（CA証明書の追加が禁止されている等）。この場合、傍受を前提とする差し替えは選べない。
・プロジェクトがまだ若く、破壊的変更やバグ修正が続いている。OneCLIはコントリビュータの大半を1名が占め、v1.42.0まで頻繁にリリースが続く段階だ。ミッションクリティカルな本番に即投入するより、まず隔離環境で挙動と限界を確かめたい。
・ゲートウェイという単一障害点を運用する体制が無い。集約した鍵を守る責任を負えないなら、集約のメリットより弱点が勝ちうる。

要は、「鍵を渡す先が多く、露出を構造的に減らしたい」チームには刺さり、「鍵が1本で運用も単純」なら過剰になりうる、という見立てだ。導入するにしても、いきなり本番ではなく、次章のチェックリストと前章の確認コマンドを通してからにしたい。

AIエージェント セキュリティを固める導入前チェックと他ツール比較

最後に、OneCLIを「他のシークレット管理・キー管理」の中でどう位置づけるかを整理する。以下は各手法の役割の違いを並べたもので、優劣を断じるものではない。用途と運用体制によって最適解は変わる。

方向の違いに注目すると分かりやすい。PasteGuard｜LLMに送るプロンプトからPIIとAPIキーを自動マスクするプロキシ は、LLMへ入っていくプロンプトからPIIやキーをマスクする（inbound）。対してOneCLIは、エージェントから外部APIへ出ていくリクエストで、ダミーキーを実キーへ差し替える（outbound）。守る通信の向きが逆であり、両者は排他ではなく組み合わせられる。VaultやSOPSは「鍵の保管庫」であり、OneCLIは「エージェントに渡さないための関所」——レイヤーが違う。

もう少し役割を噛み砕くと、こうなる。HashiCorp Vaultは、動的シークレットや厳密なアクセス制御・監査を備えた本格的な秘密管理基盤で、アプリ全般を対象にする。ただし利用側は最終的にシークレットを取得して手元で使うため、「エージェントの手元にキーを置かない」という要件そのものは満たさない。dotenv／SOPSは、設定ファイルとしての秘密を扱う軽量な手段で、SOPSはファイルを暗号化できるが、これも復号したキーはプロセスが保持する。環境変数への直渡しは最も手軽だが、平文でプロセスに常駐し、本記事で見てきた露出面をすべて抱える。これらに対してOneCLIは、「保管」よりも「エージェントに渡す最後の一手」を差し替える点に特化している。したがって現実的な構成は、鍵の保管はVaultやパスワードマネージャー、エージェントへ渡す関所はOneCLI、LLMへ送るプロンプトの浄化はPasteGuard、というように役割ごとに層を重ねる形になりうる。どれか一つが他を置き換えるわけではない、という理解が導入判断の出発点だ。

導入を検討するなら、次の対策チェックリストを最低ラインにしたい。いずれもOneCLI固有ではなく、この種のゲートウェイを安全に使うための共通の緩和策だ。

・ゲートウェイと管理画面を 127.0.0.1 にバインドし、不要に外部公開しない。
・信頼させるCA証明書を、そのエージェント実行環境だけに限定する（OSや開発端末全体に入れない）。
・SECRET_ENCRYPTION_KEY を明示指定し、鍵の保管場所とアクセス権を把握する。
・チーム・本番ではローカルモードを避け、OAuth等で認証を有効化する。
・エージェントごとのアクセストークンは最小権限にする。
・ゲートウェイを通らない直叩き経路を塞ぎ、抜け道を残さない。
・導入前後に、前章の①〜⑥の確認コマンドで実キーの露出を点検する。

導入後の運用でも、いくつか続けるべきことがある。ゲートウェイを通す構成の副産物として、どのエージェントがいつどのAPIを叩いたかを一望できるようになる（公式も「すべてのエージェントの挙動を1か所で見られる」ことを利点に挙げる）。この可観測性を活かし、身に覚えのないサービスへのアクセスや急増を監視に載せておきたい。鍵を集約した以上、ローテーションは1か所で回せるので、定期的な入れ替えを習慣化するコストも下がる。さらに、OneCLIはリリースが頻繁な段階のプロジェクトであり、セキュリティ上重要な部品ほど最新に追従する意味が大きい。使っているバージョンとリリースノートを定期的に確認し、傍受・差し替えの中核に修正が入っていないかを見ておくのが安全だ。

OneCLIはまだ開発の主体が実質1〜2名の若いプロジェクト（コントリビュータの大半を1名が占める）で、v1.42.0まで週次に近いペースでリリースが続いている。実運用に投入する前に、上記の対策と自環境での確認を済ませ、「守る範囲・守らない範囲」を理解した上で使うのが、AIエージェント セキュリティを一段引き上げる現実的な進め方になる。

視野を広げると、OneCLIのような「認証情報ゲートウェイ」は、エージェントが自律的に外部サービスを叩く時代に生まれつつある新しいカテゴリだと言える。人間が使う秘密は「取得して手元で使う」で済んだが、だましやすく増殖しやすいエージェントに同じ発想を当てると、露出面が一気に広がる。だからこそ「そもそもエージェントに実キーを持たせない」という設計思想が注目される。OneCLIはまだ若く、この思想を完成形として提示するものではないが、自分の環境で仕組みと限界を確かめる価値は十分にある。まずはローカルモードで1エージェントを通し、本記事の確認コマンドで「実キーが漏れていないか」を自分の目で見てみるところから始めてほしい。

参照ソース

・onecli/onecli — GitHubリポジトリ（README・アーキテクチャ・クイックスタート）
・OneCLI 公式ドキュメント（Credential & Policy Layer for AI Agents）
・Show HN: OneCLI – OSS credential gateway that keeps secrets out of AI agents（Hacker News）
・How OneCLI Secures AI Agent API Keys Without Code Changes（DEV Community）