eBPF バックストップは非協調のグラウンドトゥルースオブザーバーです。カーネルの syscall トレースポイントにアタッチし、ユーザースペースのエージェントが回避、無効化、または偽装できないアクセスマップエッジとしてファイルおよびネットワーク I/O を報告します。協調テレメトリがエージェントの正直な報告を信頼するのに対し、バックストップは信頼しません — エージェントではなくカーネルを監視します。
一般的なソースモデルと OLIVARES_SOURCES_CONFIG 構造についてはソースの接続を参照してください。バックストップが補完する協調パスについてはClaude Code の接続を参照してください。
観測するもの
バックストップはカーネルレベルの syscall — open、read、write、connect、sendto、recvfrom およびそのバリアント — をインストルメントし、関連する I/O イベントごとに1つの観測を出力します。読み取り/書き込みの分類は、エージェントの主張ではなく syscall 自体から取得されます。そのため、pgAudit の READ/WRITE クラスが権威あるのと同じ意味で権威的です: カーネルが操作を実行したので、操作は発生しました。
結果は、ホスト上のプロセスIDにファイルおよびネットワーク I/O を帰属させるアクセスマップエッジのストリームです。これらのエッジは、他のすべてのソースと同じアクセスマップに供給されます。
存在理由
協調テレメトリ — OpenTelemetry エクスポート、フックペイロード、MCP イントロスペクション — はよりリッチで高レベルですが、協調的です: エージェントがそれを出力しています。OTel エクスポーターを無効にしたエージェント、または最初からエクスポーターを持たなかったランタイムは、協調シグナルを一切生成しません。
eBPF バックストップはそのギャップを埋めます。テレメトリのエクスポートを停止したエージェントも syscall を行います。カーネルはそれを見ます。バックストップはそれを報告します。これはClaude Code の接続ドキュメントが参照するグラウンドトゥルースです:
真に非協調的な活動のグラウンドトゥルースはカーネル/eBPF バックストップであり、このヒューリスティックではありません。
そのヒューリスティック — フックが発火し続けている間に OTel の出力を停止したセッションの検出 — は協調側の異常シグナルです。バックストップは非協調側を観測可能にします。
カバレッジティア
バックストップは忠実度モデルにおいて clean ティアです。読み取りと書き込みはエージェントの主張ではなく syscall から判定されます。忠実度のドキュメントでは pgAudit や CloudTrail と並んで記載されています: 「カーネルレベルの eBPF グラウンドトゥルース。」clean なカバレッジは clean な帰属を意味しません — 下記の制限事項を参照してください。
協調観測との使い分け
両者は合成されます。置き換えるものではありません。
- 協調（OTel、フック、MCP） — より高レベルのコンテキスト: セッション、ツール、モデル、コスト。よりリッチなマップ。
- 非協調（eBPF） — 回避防止の保証: エージェントが報告するものに関係なく、カーネルレベルで実際に何が起こったか。
両方を実行してください。協調パスがガバナンスの対象となるリッチなマップを構築します。バックストップは、協調パスが見逃したもの — 回避、設定ミス、またはテレメトリのないランタイム — を捕捉する偽造不能なフロアを提供します。
デプロイメントモデル
バックストップは、エージェントが実行される各ホストで実行され、pgaudit、s3cloudtrail、runtime、mcp、claude と並んでソース種別 ebpf としてストック serve に接続されています。eBPF プログラムはホストカーネルにアタッチするため、ホストあたり1つのインスタンスですべてのエージェントプロセスをカバーします。エージェントごとのインストールステップはありません。
Linux ケーパビリティ
eBPF トレーシングには昇格されたカーネル権限が必要です。最低限、eBPF プログラムをロードするプロセスには CAP_BPF および CAP_PERFMON ファミリー（または同等のもの。カーネルバージョンによっては CAP_SYS_ADMIN に統合）のケーパビリティが必要です。
:::caution
正確なケーパビリティセットは、カーネルバージョン、ディストリビューション、セキュリティモジュール（AppArmor、SELinux）に依存します。必要な正確なフラグについてはコネクター自身のドキュメントを確認してください — 環境によって異なるため、このページでは決定的なセットを記載しません。コンテナ内での実行には明示的なケーパビリティ付与（場合によっては BPF ファイルシステムマウント）が必要です。ロックダウンされた Kubernetes Pod では securityContext のオーバーライドが必要です。
:::
設定
OLIVARES_SOURCES_CONFIG で kind: "ebpf" を選択します。他のすべてのコネクターと同じソースエントリ構造を使用します:
{
"sources": [
{
"name": "host-backstop",
"kind": "ebpf",
"tenant": "acme",
"config": {}
}
]
}正確な config キーはコネクターが所有しています。未検証のスキーマをコピーするのではなく、そのディスクリプターを読んでください。上記の config オブジェクトは意図的に空です — このページはソースの接続と同じルールに従っています: 検証したキーのみをドキュメント化し、eBPF コネクターの config サーフェスはこれらの Web ドキュメントからは検証していません。
回避防止の特性
バックストップはエージェントの協力に依存しません:
- OTel エクスポーターを無効にしたエージェントも、カーネル syscall を生成します — バックストップはそれを見ます。
- 協調テレメトリで嘘をつくエージェントは、カーネルに嘘をつくことはできません。syscall レコードは権威的です。
readOnlyHint/destructiveHintを誤報告する MCP サーバーは、バックストップの観測に影響しません — それらはバックストップが消費しない協調シグナルです。
Claude Code の接続の協調側ヒューリスティック — フックが発火し続けている間に OTel が沈黙するセッション — は検出シグナルです。バックストップはそのシグナルが指し示すグラウンドトゥルースです。
正直な制限事項
バックストップはカーネルが見るものを観測し、エージェントが意図するものではありません。この区別は重要です:
- 帰属はプロセスレベルです。 I/O はプロセスID（PID、UID、バイナリパス）に帰属されます。複数のエージェントが1つのプロセスを共有している場合、バックストップはそれらのアクセスを分離できません — 帰属は
firmではなくapproximateです。エージェントごとの帰属にはエージェントごとの ID シグナルが必要です。忠実度を参照してください。 - セッションやツールのコンテキストはありません。 バックストップは syscall を見ますが、セッションやツール名は見ません。どのツールコールがファイル書き込みをトリガーしたかは分かりません — プロセスがファイルに書き込んだことのみです。協調パスがそのコンテキストを持ちます。
- カーネルバージョン依存。 eBPF トレースポイントの利用可能性はカーネルバージョンによって異なります。最低カーネルバージョンはコネクター自身のドキュメントで確認してください。
- ペイロードコンテンツなし。 すべてのソースと同様に、バックストップはIDと読み取り/書き込み分類を出力し、ファイルコンテンツやネットワークペイロードは出力しません。
関連
- ソースの接続 — 一般的なソースモデルと設定ファイル。
- Claude Code の接続 — バックストップが補完する協調パス。
- カバレッジと帰属の忠実度 — clean/lossy/opaque と firm/approximate/unknown の軸。
- アクセスマップ — これらの観測が構築するもの。