🔒 AIエージェントに本番のAPIキーを渡さない、gVisorで包む新runtime「CLRK」

突然ですが、社内のAIエージェントにAWSやOpenAIのAPIキーを、そのままPodの環境変数で渡していないだろうか。

便利だけど、エージェントがプロンプトインジェクションで乗っ取られたら、そのキーごと持っていかれる。「サンドボックスに閉じ込めておけば安心」と思っていても、コンテナの中に鍵そのものがある時点でリスクは消えていない。

そこに2026年7月7日、Apoxy社のDmitry Ilyevsky氏が投げ込んだのがCLRK(Cognitive Loop Runtime for Kubernetes)だ。Show HNでの反応はスコア4と地味だったが、中身を読むと発想がおもしろい。

エージェントの中にAPIキーを置かない

CLRKの核心は「credentials never live in the agent」という設計方針。各エージェントはgVisor(Googleが開発したユーザー空間カーネルのサンドボックス)の中で動く。Podから出ていく通信は全部、EnvoyベースのEgressGatewayを経由する。

ここがポイントで、GatewayはTLSをMITM方式で終端し、LLM APIやMCPサーバー、内部サービスへのリクエストが実際に通るその瞬間にだけAPIキーを注入する。Podの環境変数にもマウントにも起動引数にも、鍵は一度も現れない。サンドボックスが乗っ取られても、鍵ごと持っていかれることがない理屈だ。

エージェント側のコードは変更不要。HTTP/Sで喋っていれば、フレームワークを問わず素通りでインターセプトされる。

8種類のCRDで宣言的に管理する

アーキテクチャは3つに分かれている。CRDのreconcileと集約APIサーバーを担う制御平面、gVisor/runscでサンドボックスのライフサイクルを管理するworker、そしてデプロイとローカル開発用のclrk CLI(install/upgrade/dev)だ。

cmd/controller-manager   # 制御平面: CRD reconciler + 集約APIサーバー
cmd/worker               # gVisor/runscでサンドボックスのライフサイクルを管理

管理対象はTaskAgent(短命タスク)、DaemonAgent(常駐)、WorkerPool、EgressGateway、EgressL4Route、MCPRoute、AIProviderRoute、Invocationという8種のCRD。ふだんKubernetesを触っている人なら、「Podを直接立てる代わりにTaskAgentを宣言する」感覚のほうがイメージしやすいはずだ。

可観測性は監査ログとして全部残る

透過的にインターセプトするということは、Gatewayを通る全バイトがログに残るということでもある。テレメトリはClickHouseとOpenTelemetryで蓄積する設計で、LLM呼び出し・MCPトラフィック・アウトバウンドのツール呼び出しを、エージェントのコード自体には気づかれずに監査できる。

コスト管理にも効いてくる。ルーティング層でトークン量やAPI呼び出し回数を見られるので、「どのエージェントがコストを食っているか」を後から追いかけられる設計だ。

日本語の解説はまだゼロ

ZennとQiitaで「gVisor」と「AIエージェント」を掛け合わせて検索してみたが、解説記事は見当たらなかった。海外では2026年4月にgVisor公式ブログがマルチエージェント分離機能「MAGI」を発表していて、サンドボックス側からもエージェント特化の動きが進んでいる。CLRKはそこにEgress制御と資格情報管理を足した格好だ。

自社でAIエージェント基盤を組んでいるチームなら、Podに直接APIキーを渡す設計を一度見直したほうがいい。バグより先に、鍵の置き場所を疑うべきだ。あなたのチームでは、エージェントにどこまで鍵を渡している?