7月28日、Tigeraが「Why eBPF Is Useful for Watching and Sandboxing AI Agents」と題した記事を公開した。この記事では、eBPFをAIエージェントの監視・サンドボックス化に活用するアプローチについて詳しく解説されている。

TigeraはKubernetesネットワーキングおよびセキュリティのOSSであるCalicoの開発元であり、eBPFをデータプレーンとして採用したCalico eBPFの開発・運用で知られる。Ciliumなどと並び、Kubernetes環境でのeBPF活用における第一線の実践者だ。

AIエージェントは「決定論的なワークロード」ではない

従来のサービスはコードが規定した通りに動く。コードをレビューし、イメージに署名すれば、挙動は基本的に予測できる。AIエージェントはそうではない。

エージェントの挙動は、コンテキストウィンドウに入力された情報に対してモデルが推論した結果として生まれる。その入力には、検索で取得したドキュメント、ツールの出力、ユーザーのプロンプトなど、完全には制御できないものが含まれる。一方でエージェントは、サービスアカウント、ネットワーク到達性、マウントされたシークレット、ファイルシステムといった実際の権限を持ちながら動作する。

プロンプトインジェクション対策（プロンプトの衛生管理、インジェクション分類器、ガードレールモデル）は重要だが、それと並行して問うべき問いがある。「エージェントが意図しない動作をした場合、どこまで影響が及ぶか」——これがブラスト・ラジウス（爆発半径、blast radius）の問題であり、プロンプト処理とは独立してランタイム層で決定できる。

なぜ eBPF がここに刺さるか

eBPF（extended Berkeley Packet Filter）は、Linuxカーネル内でサンドボックス化されたプログラムを動かす仕組みで、カーネルの改変やモジュールのロードなしにシステムコールやネットワークイベントを観測・制御できる。KubernetesエコシステムではすでにCiliumやCalico eBPFがネットワークポリシーの高速処理にeBPFを活用しており、セキュリティ観測の分野ではTetragon（Ciliumプロジェクト傘下）やFalcoのeBPFドライバーがランタイム脅威検知に広く使われている。本記事が論じるAIエージェントの監視・制御は、こうした既存のeBPF活用の延長線上に位置づけられる。

eBPFがAIエージェントの監視に適している理由は明快だ。エージェントが行うほぼすべての操作はシステムコール（syscall）に帰着する。ファイルの読み書き、コマンドの実行、ネットワーク接続——これらはすべてカーネルを経由する。eBPFはワークロードの下層、カーネルに張り付いてそれらを直接観測できる。

具体的には次の3種類の活動を補足できる：

• ファイル操作 — LSMフック（BPF-LSM / KRSI）や openat、read、write へのkprobeを用いる。/var/run/secrets のような機密パスへのアクセス試行を含め、エージェントが何を読み書きしているかを正確に把握できる。
• プロセス活動 — sched_process_exec や LSMの bprm_* フックを用いる。エージェントが実行しようとするすべてのバイナリ（予期しないシェルの起動を含む）を可視化できる。
• ネットワーク活動 — cgroupの connect フック、tc/XDP、DNSの可視化を用いる。エージェントがどこにトラフィックを送ろうとしているか、モデルゲートウェイを迂回しようとしているかを確認できる。

たとえばTetragonではTracingPolicyというCRDでこれらのフックをYAML定義として記述でき、kprobe や lsm のフック種別・対象syscall・フィルタ条件を宣言的に管理できる。Falcoも独自のルール記法で類似の検知ルールを表現し、eBPFドライバー経由でカーネルイベントを収集する。いずれもエージェント自体に手を加えることなく、ランタイムでの実際の挙動を、改ざんされにくい形で記録できる。

「観測」から「強制」へ：サンドボックスとしてのeBPF

eBPFはインライン（実行パスの途中）で動作させることもでき、ポリシー違反時にsyscallをオーバーライドしたりプロセスを停止したりできる。これにより、observe（観測）→ alert（警告）→ enforce（強制） という自然な段階的移行が同一レイヤーで実現する。しかもエージェントを再デプロイする必要はない。

実際のサンドボックスルールは次のように表現できる：

• 読み取り専用エージェントに対し、/workspace 以下の読み取りは許可するが書き込みを禁止し、シークレットへのアクセスを完全に遮断する。
• 実行許可バイナリのallow-listにエージェントを縛り付けるか、シェルを起動すべきでないエージェントには exec を全ブロックする。
• エグレストラフィックがモデルゲートウェイを経由するよう強制し、直接通信を遮断する。

この仕組みには2つの実用上の強みがある。第一に、eBPFはワークロードの下層で動作するため、すでに稼働中のPodや変更を加えていないエージェントにも適用できる。再コンパイル、サイドカー、新しいベースイメージは不要だ。本番稼働中のエージェントに対して適用できるのは実際的なアドバンテージだ。第二に、ワークロードとは異なるトラスト・ドメインで動作するため、エージェントからの改ざんが難しく、オーバーヘッドもフリート全体に適用できるほど低い。

eBPF が苦手なこと、プロキシとの分担

eBPFが得意なのは「プロセスが何に触れられるか」というブラスト・ラジウス（blast radius）の制御だ。接続の開始やファイルパスへの書き込みは検知・制御できるが、プロンプトのセマンティクスを理解したり、暗号化されたリクエストボディ内のフィールドをリダクション（マスク）したりすることはできない。

そのようなコンテンツレベルの制御は、TLSを終端してエージェントの意図や行動を意味的にチェックできるモデルゲートウェイ側のプロキシが担う。eBPFは「何をできるか」を制限し、プロキシは「何を送るか」を制御する。両者は補完関係にある。

AIエージェントのセキュリティは、モデル側のガードだけでは不十分だという認識は業界でも広がりつつある。eBPFをランタイム層の「均一なフロア」として活用し、その上に高精度なアプリケーション認識型の制御を重ねるという設計は、エージェントが本番環境で実権限を持って動作する今、実践的な選択肢となる。

詳細はWhy eBPF Is Useful for Watching and Sandboxing AI Agentsを参照していただきたい。