【脱・AIへの鍵渡し】AIエージェントの暴走を防ぐOSS「OneCLI」で、認証情報を安全に管理しよう

皆さん、こんにちは！OneCLI (https://onecli.sh/) 開発者のJonathanとGuyです。OneCLIは、AIエージェントのためのオープンソースな「シークレットゲートウェイ」です。従来のVault（鍵保管庫）は、人間が扱うことを前提としていました。しかし、AIエージェントの世界では話が別です。一度渡した認証情報がどこに保存され、どう悪用されるか（あるいはプロンプトインジェクションで盗まれるか）を制御するのは困難だからです。そこで私たちは、AIエージェントと呼び出し先のサービス間に配置するネットワークゲートウェイ「OneCLI」を開発しました。ホスト名やパスでリクエストを識別し、アクセス権限を検証した上で、プレースホルダを本物の認証情報に差し替えて通信を中継します。シークレットはOneCLIのVault内で暗号化して管理するか、Bitwardenや1Passwordからリアルタイムで取得可能です。デモ動画はこちら：https://www.youtube.com/watch?v=5e5pbPEzZfY 。私たちは、自身の開発ツールであるChartDBの運用中に、AIエージェントに認証情報を渡すことの危険性に気づき、本プロジェクトを開始しました。エージェントはメモリ内やログに平文で鍵を残しやすく、攻撃者に簡単に情報を引き渡してしまいます。OneCLIを使えば、エージェントに鍵を渡さず、ネットワーク層で通信を制御できます。機密性の高い操作にはHuman-in-the-Loop（人間による承認）を挟むことができ、MCPやCLI、curlなど、どのようなインターフェース経由の通信であっても強制力が働きます。Rustで実装されたプロキシ、Next.jsのダッシュボードで構成され、データはAES-256-GCMで暗号化。Claude Code、Cursor、OpenClawなど、HTTPS_PROXYを設定できるあらゆるエージェントフレームワークで動作します。AIモデルの自律的な動作を完全に信じるのではなく、決定論的なルールで制御し、安全を確保しましょう！ご意見・ご質問お待ちしています。

onecliが動いてる環境ってエージェントが制御してるの？（イエス）

いやはや、みんなまた同じようなことを考えてるんだな。コメント欄でみんな必死に自分の実装を宣伝しようとしてるよ。

結局のところ、あるキーを別のキーに置き換えてるだけだろ。どの抽象化レイヤーを信頼しようが、結局どこかのタイミングで認証情報が今週のLLMに渡されるんだから。

OAuthやSAML、OIDCを使えばもっと成熟した方法で同じことができるんだから、すでにSSOを使ってるなら、わざわざ故障点を増やすような真似はせずにそっちを使うべきじゃない？

静的な認証情報にはすごくいいね。プロダクトとして、役に立ちそうな機能をあといくつか思いついたよ。（ちなみにこれの開発者じゃないけど、実務上の課題として知ってることなんだ）

1. OAuthクライアント認証情報のサポート - ゲートウェイ側でOAuthのやり取りをしてアクセストークンを取得する仕組み。これはかなり実用的だし、クラスタをまたいでclientIdとsecretIdを共有するような一般的なサービスでも便利だよ

2. 特定のエラーに対するリトライ機能と、他のケースでのサーキットブレーカー機能

ほとんどのコメントが多かれ少なかれ自分のプロダクトを売り込んでるの、笑えるよね。

おっ、これは興味深い。ネットワークレベルでブロックできるのはいいね。

agent-vaultやclawpatrolと比べてどうなの？

なんで1passwordじゃダメなの？

これ、データベースの世界では昔からある定石だね。DBクライアントはディスクには直接触らず、ディスクを管理するサーバーにリクエストを送る。あなたのプロダクトも同じだ。キーとエージェントを分離して、必要ならエージェントがキーを持つプロキシにリクエストを送る。実績のある古い設計だよ。頑張って。

MITM（中間者攻撃）が今や機能扱いか。