AI News HubLIVE
站内改写3 分で読了

AI-noleak – AI CLI向けローカル秘密プロキシ

AI-noleak は、AIコーディングエージェントが誤って露出させたローカルシークレット(APIキー、トークンなど)を傍受し、アップストリームのAIモデルに到達する前に決定論的なプレースホルダーに置き換えるローカルリバースプロキシです。3つの層(PTYラッパー、HTTPプロキシ、ファイルウォッチャー)で動作し、TLS MITMやルートCA証明書を必要とせず、ローカルセキュリティの分離を実現します。

ソースHacker News AI著者: ahmedxuhri

AI-noleak は、開発者 ahmedxuhri によって作成されたオープンソースプロジェクトで、AIコーディングエージェントがタスク実行中に誤ってローカル機密情報を流出させる問題を解決します。このツールは、ユーザーの端末とAI APIの間でローカルリバースプロキシとして動作し、3つの独立した保護層を通じて機密情報を傍受、置換、復元します。許可されたAPIキーのみが通過し、他のローカルシークレットはホストを離れる前に決定論的なプレースホルダーに置き換えられます。

第1層はPTYラッパーで、シェル実行前にブラケットペーストからシークレットを除去します。第2層はHTTPプロキシで、送信リクエストとAI応答内のシークレットをスキャンして編集します。第3層はファイルウォッチャーで、inotify(Linux)またはkqueue(macOS)を使用してログファイルや履歴ファイル内のシークレットを監視し、即座にクリーンアップします。全層がローカルボールトデーモン(noleakd)を共有し、プレースホルダーとシークレットのマッピングをメモリ(エフェメラルモード)またはAES-256-GCM暗号化ディスク(パスフレーズモード)に保存します。

セキュリティモデルでは、100%ローカル分離を採用し、テレメトリは送信されません。カスタムルートCA証明書のインストールは不要で、平文トラフィックはローカルループバックインターフェース(127.0.0.1)のみを通過します。ボールトデーモンはUnixドメインソケットで通信し、カーネルレベルのピア資格情報チェック(LinuxのSO_PEERCRED、macOSのLOCAL_PEERCRED)で厳格にUIDを検証し、デーモンを起動したユーザーIDと同じプロセスのみがボールトにクエリ可能です。HTTPプロキシはボールトに対して読み取り専用で、シークレットを変更できません。永続化モードでは、Argon2id鍵導出関数とAES-256-GCMでボールトファイルが暗号化されます。

なぜこれが重要か?Agentic AI CLIはコマンドを記述・実行し、ファイルをgrepし、ログを読み取ります。環境変数、.envファイル、.git/configの認証情報、またはコマンド履歴内の生トークンが存在する場合、エージェントが誤ってそれらを読み取り、プロンプトコンテキストに注入してアップストリームAI APIやサードパーティプロキシに送信するのは非常に簡単です。AI-noleakは、貼り付けられたシークレットがシェル実行前に除去されること(第1層)、AIプロバイダへの送信HTTPリクエスト内の生シークレットがマシン外に出る前にプレースホルダーに置き換えられること(第2層)、ディスクに書き込まれた一時的なシェルスナップショット、ログ、履歴ファイルが即座にクリーンアップされること(第3層)を保証します。アップストリームAIモデルは @TOKEN_a9553f@ のようなプレースホルダーのみを見て、モデルがプレースホルダーを出力した場合、AI-noleakはCLIに返す前にローカルで実際のシークレットに変換します。

インストールはLinuxとmacOSに対応し、ワンライナーでのクイックインストールまたはチェックサム検証付きの推奨インストールが可能です。ソースからのビルドもオプションで、Go 1.22+が必要です。クイックスタートでは、~/.noleak/config.yamlを編集してプロキシ上流アドレスを設定し、noleak start(またはnoleak start --ephemeralでメモリモード)を実行し、最後にAI CLIのベースURLを http://127.0.0.1:9999/v1 に設定します。プロジェクトにはヘルスチェックコマンドnoleak doctorや、list、review、rotate、deleteなどのプレースホルダー管理コマンドが含まれています。

インタラクティブデモでは、エージェントがAWSキーを含むプロンプトを送信しようとすると、AI-noleakが即座に傍受し、キーを@TOKEN_xxxxxx@に置き換え、上流モデルはプレースホルダーのみを見ます。ユーザーは各保護層を手動でテストすることも可能です:第2層はcurlでキーを含むリクエストを送信、第3層は監視ディレクトリにGitHub PATを含むファイルを作成、第1層はprintfでブラケットペーストをシミュレートします。

制限事項として、macOSではファイルウォッチャーがFSEventsの遅延と結合により、高ディスクI/O下でエージェントが数ミリ秒以内にシークレットを書き込み読み取りした場合、第3層が十分に速く反応できない可能性があります。また、CLIツールが監視対象外のディレクトリにスナップショットやログを書き込む場合、第3層の保護は機能しません。ユーザーはワークフローに合わせて監視パスを調整する必要があります。