CLRK：gVisorとMitMガードレールを備えたオープンソースのエージェントランタイム

CLRK（「クラーク」と発音）は、LLMエージェント向けのKubernetesネイティブランタイムです。各エージェントをgVisorサンドボックスで実行し、エージェントコードを変更することなく、すべての出力トラフィック（LLM API呼び出し、MCP（モデルコンテキストプロトコル）、ツール呼び出し）を透過的にインターセプトします。このインターセプトポイントにより、可観測性、ポリシー適用、ルーティングベースのコスト制御が可能になり、エージェントの内部動作を詳細に把握できます。

仕組み

CLRKは、gVisorサンドボックス内でフレームワークに依存しないエージェントワークロードを実行します。ユーザーはエージェントを宣言的に記述します（コンテナイメージ＋トリガー＋出力ポリシー）。CLRKはそれをサンドボックスワーカープールにスケジュールし、独自のスケジューラを使用するため、Pod作成のレイテンシに依存しません。サンドボックス内外のすべてのバイトはCLRKが制御する透過プロキシを通過するため、プラットフォームはエージェントコードが意識することなく、すべてのLLM API呼び出し、MCPトラフィック、外部ツール呼び出しを監視・制御できます。これにはTLS暗号化接続も含まれます。エージェント内部は、HTTP(S)呼び出しを行う任意のもので構いません。例えば、OpenAIやAnthropic SDKを使用するPythonスクリプト、Node MCPクライアント、シェルのワンライナーなどです。特定のエージェントライブラリは不要で、CLRKはネットワークとプロセスの境界でインターセプトを行います。

動機

本番環境でエージェントを実行するには、汎用コンテナオーケストレーションだけでは解決できない問題があります。CLRKはこれらに直接対処するために構築されています：

• 可観測性：サンドボックス内外のすべてのI/Oをインターセプトして記録するため、LLM、MCP、リモートツールコールのテレメトリが自動的に計装されます。
• ガバナンス：サンドボックスエスケープを防止し、組織全体のポリシー（エージェントが接続できる場所、使用できる認証情報）を出力境界で適用します。
• 帰属性：エージェントループを開始した顧客リクエストやトリガーに紐付け、第一級のInvocationレコードとしてキャプチャします。
• ゼロトラストアクセス：エージェントに監査・承認された内部サービスへのアクセスを提供し、全か無かのネットワークアクセスを回避します。
• スケーラビリティ：サーバーレスバーストと長期実行の「オンプレミス」Kubernetesフリートの両方に対応する統一モデル。
• 信頼性：シンプルで堅牢なリトライと負荷破棄を、Kubernetesコントロールプレーン外で実現。
• 認証情報の安全性：認証情報はエージェント内に決して保存されません。AIプロバイダー、MCPサーバー、内部サービスのAPIキーは、出力MITMによってリクエスト時に注入され、Pod環境変数、マウント、引数を介さないため、サンドボックスが侵害されても認証情報が漏洩することはありません。

アーキテクチャ

CLRKは2つの長期実行バイナリとCLIを提供します：

• cmd/controller-manager：コントロールプレーン。controller-runtime reconcilerを実行し、CRD用に集約APIサーバーを埋め込みます。Kubernetes Deploymentとしてデプロイされますが、スタンドアロンでも動作可能。UIダッシュボードもホストします。
• cmd/worker：gVisor/runscを介してサンドボックスライフサイクルを管理し、カスタムsentrystackプラグインを使用してサンドボックスごとのネットワークインターセプションを設定し、インターセプションパスにルーティングします。Linuxのみ（CGO）。
• cmd/clrk：オペレーター/開発者CLI。インストール、アップグレード、開発、apply、get、logs、traces、status、run-task、コンテキスト管理、ローカルクラスター開発ループを提供。

出力インターセプションはEnvoyベースのデータプレーン（TLS終端（MITM）とカスタムフィルターを備えたEgressGateway）を介して行われます。テレメトリはClickHouseに記録され、/logsや/tracesサブリソース、およびOpenTelemetryシンクを介して利用できます。

API

CLRKはCRDを通じてKubernetes APIを拡張します。主要なタイプは以下の通りです：

• TaskAgent：短時間のエージェント実行（リクエスト→サンドボックス→レスポンス）
• DaemonAgent：再起動ポリシーを持つ長期実行エージェントプロセス
• WorkerPool：ワーカーPodのフリート（Deployment + Service）
• EgressGateway：TLS終端モードを持つ透過出力プロキシ
• EgressL4Route：L4出力ルーティングルール
• MCPRoute：MCPプロトコルルーティング
• AIProviderRoute：AIプロバイダー固有の出力ルーティング
• Invocation：インターセプトされたエージェント呼び出しの帰属レコード（ClickHouseバックエンド）

FAQ

• エージェントは特定のフレームワークやSDKを使う必要がありますか？ いいえ。CLRKはネットワークとプロセスの境界でインターセプトするため、HTTP/S呼び出しを行う任意のエージェントが動作します。提供される例ではOpenAI/Gemini SDK、プレーンなシェルツール、MCPクライアントを使用しています。
• APIキーはどこに保存されますか？ エージェント内には保存されません。認証情報は出力MITMによってリクエスト時に認証情報注入ポリシーを介して注入され、Pod環境変数、マウント、引数には決して配置されません。侵害されたサンドボックスから漏洩する秘密はありません。秘密情報はKubernetes Secretに安全に保存されています。
• サンドボックスはどのように隔離されますか？ gVisor（runsc）を使用して強力なシステムコール境界を提供し、各サンドボックスは独自のネットワーク名前空間で実行され、すべての出力はインターセプションパスを強制的に通過します。
• ローカルで実行するにはKubernetesクラスターが必要ですか？ いいえ。clrk devでローカルクラスターと開発ループを起動できます。
• ライセンス：CLRK全体はAGPL-3.0ですが、api/とclient/ディレクトリはApache 2.0であり、AGPLの制約なしにAPIタイプをインポートして使用できます。

リポジトリ構成

主なディレクトリ：api/（CRDタイプ）、client/（生成されたKubernetesクライアント）、internal/controller/（reconciler）、internal/worker/とinternal/sandbox/（サンドボックスライフサイクル）、internal/egress/（Envoy出力データプレーン）、internal/clickhouse/（テレメトリ保存）など。

コントリビューションとテスト

現在、外部からのコントリビューションは受け付けていません。テストは存在しますが、まだ公開されていません。内部的には最低70%のユニットテストカバレッジを維持し、パブリックAPI向けの統合テストも行っています。コードはAI支援を受けていますが、すべての出力行は注意深くレビュー・テストされてからコミットされています。

全体として、CLRKは本番環境のLLMエージェント向けに、セキュアで可観測性が高く、管理しやすいプラットフォームを提供し、特にゼロトラストときめ細かいガバナンスが必要なシナリオに適しています。