ソースを接続する

本ページでは、一般的なコネクタモデルと、実際のソースをエンジンに配線する方法を説明します。コーディングエージェントだけを接続したい場合は、Connect Claude Code から始めてください — それは協調経路上の特定の 1 ソースであり、本ページはその下にあるモデルです。

コネクタモデル

ソースは 1 つの仕事をします。外部システムを観測し、正規化された観測を発する ことです。決してデータ経路に入らず、決してトラフィックをプロキシせず、決してペイロードを読みません。R/RW access map は、流れるものを傍受して構築されるのではなく、ソースが報告するものから構築されます。

具体的には、ソースは小さなインターフェース — Open（一度だけ構成）、Gather（実行し、発する）、Close（解放）— を実装し、Gather の間にシンクを通じて一度に 1 つずつエンジンへ観測を渡します。スケジューリングはエンジンが所有します。ストリーミングソース（ログテール、レシーバー）は Gather でブロックし、キャンセルされるまで発し続けます。バッチソースは作業を行って返り、エンジンが次の実行時期を決めます。コネクタは自分自身のタイマーを決して所有しません。

ソースが発しうる観測は、ちょうど 3 種類です:

観測	運ぶもの	利用先
`edge`	起点（エージェント / アイデンティティ / セッション）がリソースに触れたこと、read/write モード付き	R/RW access map
`cost`	モデル/プロバイダーの使用コスト	FinOps
`finding`	guardrail / red-team / フォレンジックの finding	セキュリティ

この集合は設計上閉じています — サードパーティが新たな観測種別を導入することはできません。エンジンは発された各観測を in-process イベントバス上へ 持ち上げ 、そこでモジュールは、それを生成したソースに結合することなく消費します。access map については特に、エンジンはコネクタの文字列参照をエンティティへ解決し、観測を永続化されたアクセスエッジへマージします。

コネクタは Apache-2.0 であり、決して core をインポートしない

コネクタはコネクタ SDK をインポートし、製品からはそれ以外をインポートしません。/core（AGPL エンジン）を決してインポートしません。その境界は CI で強制され、それこそがコネクタを Apache-2.0 で出荷可能にし、サードパーティが copyleft の摩擦なしに独自のものを構築できるようにします。同じコネクタバイナリが in-process でも、gRPC 越しの out-of-process でも同一に動作します。完全な境界については Open core とライセンスを参照してください。

来歴と信頼度: なぜソースが重要か

各エッジは どのソースが生成したか と 信頼度 レベルを記録し、製品はそれらを潰さずに両方を表示します。pg_audit の READ と mcp_annotation のヒントは同じ証拠ではなく、決して同じものとして扱われません。

2 つの信頼度レベルは正直なものであり、見せかけではありません:

attributed — アクセスがその起点に確固として結びついている（例えば、監査証跡に存在するエージェント単位のアイデンティティ）。
approximate — 帰属が推論的または損失を含む（共有サービスアカウント、または呼び出し元をきれいに分離できない監査を持つストア）。

アクセスモードは unknown、read、write、readwrite のいずれかです。unknown は明示的であり、決して推測されません — 製品は read/write ラベルを捏造するより、「これを分類できなかった」と表示することを選びます。

シグナル別の第一者ソースのカテゴリー

第一者ソースは、運ぶ シグナル によって異なります。観測対象のシステムが正直に伝えられるものによって、ソースを選んでください。

`pg_audit` — PostgreSQL READ/WRITE

pgAudit ソースは PostgreSQL 自身の構造化監査ログをテールし、監査されたデータアクセスごとに 1 エッジを発します。read/write モードは pgAudit の CLASS フィールドからそのまま 取られます（READ、WRITE、DDL）— SQL テキストから推論されることは決してありません。起点は、ログがアクセスを帰属させるロールまたは application_name です。コネクタはログファイルに対して読み取り専用であり、データベースに接続することも書き込むこともありません。これはクリーン層です。アクセスをネイティブな証跡で分類するオブジェクト/リレーショナルストアです。

`cloudtrail` — AWS S3 readOnly

CloudTrail ソースは CloudTrail ログファイルを読み、S3 イベントごとに 1 エッジを発します。read/write モードは CloudTrail の readOnly フィールドからそのまま 取られ、推論されることはありません。起点は、CloudTrail が呼び出しを帰属させる IAM プリンシパルです。多数の呼び出し元で共有される assumed role は、その背後の本当の呼び出し元を証跡が分離できないため、意図的に approximate とマークされます。

`otel` — 協調エージェント

これは協調経路です。OpenTelemetry のツールテレメトリを発するエージェントが自身の行ったことを報告し、エンジンがそれを取り込みます。Claude Code はここでの正規の第一者ソースであり、OTLP テレメトリと MCP イントロスペクションを組み合わせます — Connect Claude Code を参照してください。協調テレメトリは存在するときには最高忠実度のシグナルですが、エージェントが協調的であることに依存します。だからこそカーネルのバックストップが存在します。

`ebpf` — Tetragon カーネルバックストップ（非協調経路）

eBPF ソースは map の反回避の半分です。協調経路がエージェントの報告するものを見るのに対し、これはカーネルが実際に行ったこと — ファイルの read/write とネットワーク接続 — を、エージェントが自身のテレメトリを無効化していても見ます。これは エージェントの制御の外 で動作します。

2 つの正直な制約がこれを定義します:

自身で eBPF プログラムを ロードしません。カーネルキャプチャは別の堅牢化サービスとしてデプロイされる Tetragon が行います。このソースは Tetragon のイベントストリームの読み取り専用コンシューマーであり、自身のカーネルケイパビリティを必要としません。
TLS 本体に対して盲目 です。アクセス関係を観測し、ペイロードは決して観測しません。

そのエッジは常に approximate です。理由は明確で、カーネルはアクセスをプロセスまたはコンテナ — ランタイムアイデンティティ — に帰属させ、解決済みのエージェントには帰属させないからです。アクセスそのものは ground truth です（syscall は起きた）。信頼度は帰属を限定するものであり、access-map モジュールはアイデンティティをエージェントに結びつけた時点でそれを格上げします。

`mcp_annotation` — 信頼できない

MCP イントロスペクションソースは、サーバーのツール、リソース、プロンプトを列挙し、各ツールの readOnlyHint / destructiveHint から read/write の ヒント を導きます。MCP 仕様によれば、サーバー自身が信頼されていない限り、クライアントは これらの注釈を信頼できないものとして扱わなければなりません（MUST） 。そしてデフォルトは非対称です。したがってこのシグナルは 宣言された能力ヒントであり、決して観測されたアクセスではありません 。そのようなエッジはすべて approximate であり、observed でも permitted でもないとマークされます。これは差分を取るための 能力面 を供給します — 何かが実際に行われた証拠ではありません。観測されたソースによって裏付けられねばならず、単独で信頼してはなりません。

厳しい依存関係: エージェント単位のアイデンティティ

帰属は、基盤システムが記録するアイデンティティの良し悪しに左右されます。ネイティブ監査はアクセスを 認証情報またはロール に帰属させ、エージェントには帰属させません。多数のエージェントが 1 つのサービスアカウントまたは 1 つの接続プールを共有している場合、観測されたすべてのアクセスはその単一のアイデンティティに潰れ、帰属は approximate になります — 製品はエージェントを見分けられるふりをするのではなく、そう述べます。

attributed エッジを得るには、各エージェントに独自のアイデンティティを与えてください。これがガバナンスへの橋渡しです。エージェント単位のアイデンティティを発行または強制することが、access map を鋭くするものです。

段階的なカバレッジ — 現実的であること

カバレッジは、システムの監査面が正直に支えられるものによって段階化されます:

クリーン — アクセスをネイティブに分類する SQL データベース、オブジェクトストア、ウェアハウス（Postgres、S3、その同類）。read/write はそのまま取られます。
損失あり — read と write、あるいは呼び出し元と呼び出し元をきれいに分離できない監査を持つストア（ドキュメントストアおよびベクターストア）。エッジは着地しますが、しばしば approximate です。
受動的には不可能 — 使える受動的監査面を持たないシステム（インメモリキャッシュ、埋め込み単一ファイルデータベース）。捉えるべき正直な read-first シグナルがなく、製品はそうでないふりをしません。

段階を意図的に選んでください。エージェント単位のアイデンティティを持つクリーン層のストアこそ、map が最も鋭い場所です。

実際のソースを配線する

実際の（デモではない）ソースは、環境変数 OLIVARES_SOURCES_CONFIG で名指される単一のオペレーター設定ファイルから配線され、エンジン起動前 に読まれます。設定は JSON ドキュメントです。シークレットはそのファイル内に存在し（値で参照される）、エンジンによって永続化されることは決してありません。

ドキュメントはソースのリストを宣言します。各ソースエントリは kind でコネクタを選び、その観測が属するテナントを名指し、コネクタ自身の設定を運びます。一般的な形は次のとおりです:

{
  "sources": [
    {
      "name": "prod-postgres",
      "kind": "pgaudit",
      "tenant": "acme",
      "config": {
        "...": "connector-specific settings"
      }
    }
  ]
}

コネクタごとの config ブロックより上のフィールド — ソース名、コネクタ kind、所有する tenant、そしてバッチソース向けの任意のポーリング間隔 — が安定した配線契約です。

未構成のソースは正直に警告する

何も配線されていないとき、エンジンは騒がしくではなく安全側に倒れます:

OLIVARES_SOURCES_CONFIG が 未設定 の場合、エンジンはソースなしで起動します。
ファイルが 存在しない、読めない、または有効な JSON でない 場合、エンジンは 警告して続行 し、ソースなしになります — 起動時にクラッシュしません。
ソースリストが空の場合、エンジンはコネクタが何も取り込まないこと、そして estate がライブトラフィックなしで稼働していることを警告します。

いずれの場合も、起動ログは空の map で何事もなく健全に見えるのではなく、実際には何も配線されていないことを明白に伝えます。正直な警告が設計です。空の access map が決してクリーンなものに見えてはなりません。

これが動作する場所

データプレーン — これらのソースを実行するコレクター — は、control plane が単一のセルフホストバイナリであれ、分散デプロイであれ、エアギャップであれ、常に顧客のインフラ上で動作します 。ソースはローカルで観測し、エンジンが取り込みます。必須のテレメトリはなく、デフォルトではコントロールプレーンからのエグレスもありません。あなたの境界を越えるのは、あなたがそのように設定したものだけです。具体的には、あなたのモデル API への呼び出し、接続した SIEM／Webhook 出力、用意した場合の外部埋め込みプロバイダーです。デプロイトポロジーについてはセルフホスティングとエアギャップインストールを参照してください。