ほとんどのチームは、同じ居心地の悪い事実を同じ順序で発見します。まず、自社の環境全体ですでに AI エージェントが稼働しており、モデルを呼び出し、MCP サーバーを開き、データベースやオブジェクトストアに手を伸ばしていることに気づきます。次に、それらを棚卸ししようとして、リストが存在しないことに気づくのです。独立した業界調査（CSA/Token、n=418）はこのギャップを数字で示しています。およそ 82% の組織が、把握していないエージェントを稼働させています。これらを統制する前に、まずそれを「見る」必要があります。問題は、事態を悪化させずにどうやってその可視性を得るかです。
正直な答えは 2 つあり、それらはリスクスペクトラムの両極に位置します。
エージェントを見る 2 つの方法
1 つ目は インラインプロキシ です。エージェントのトラフィックを自分が管理するコンポーネント経由でルーティングすると、すべてのリクエストとレスポンスがそこを通過するため、リアルタイムで可視化、整形、ブロックができます。これは正当で強力な設計です。今日、多くのエグレスフィルタリング、シークレットの仲介、リクエストレベルのポリシーがこの方式で実施されています。
2 つ目は パッシブディスカバリ です。フローの中に立つのではなく、横から観測します。エージェントがすでに出力している OpenTelemetry、エージェントが触れるシステムのネイティブな監査証跡（PostgreSQL の pgAudit、AWS CloudTrail のようなクラウド監査ログ、Kubernetes の監査）、そしてグラウンドトゥルースのバックストップとしての eBPF によるカーネルレベルのシグナルです。接続を終端することは決してありません。何が起きたかを観察し、誰が何に触れたのかを再構成します。カーネルレベルの取得は、お客様がデプロイする Tetragon センサーから行われます。Olivares AI は Tetragon のエクスポートを読み取るだけで、eBPF プログラム自体は読み込みません。
重要な違いは、最良の場合にそれぞれが「どれだけ」見られるかではありません。可視化レイヤーそのものが故障したときに何が起きるか、です。
影響範囲こそが本当の軸
インラインプロキシは、構造上データパスの中にあります。それはリアルタイムの制御をもたらしますが、共有された障害モードという代償を伴います。プロキシが遅ければ、エージェントも遅くなります。プロキシが倒れれば、安全なデフォルトはたいてい fail closed（フェイルクローズ）、すなわちエージェントが停止するか、fail open（フェイルオープン）、すなわち最悪のタイミングで制御が静かに消失するか、のいずれかです。いずれにせよ、可視化コンポーネントは今や本番環境と影響範囲を共有することになります。さらに、すべての呼び出しにレイテンシのホップが 1 つ加わり、誰かがクリティカルパス上で運用・スケール・パッチ適用しなければならないデプロイ面が増えます。
パッシブディスカバリは正反対のプロファイルを持ちます。コレクターはアウトオブバンドかつ read-first です。テレメトリ、監査証跡、カーネルイベントを読み取りますが、エージェントのトラフィックを転送したり書き換えたりはしません。劣化しても停止しても、リクエストパス内では何も変わりません。失われるのは復旧までの「最新の」可視性であって、スループットでも可用性でもありません。これが read-first で低・非対称リスクであるということの実際の意味です。見ることだけを仕事とするものから、本番環境への上振れリスクは存在しません。
| インラインプロキシ | パッシブディスカバリ | |
|---|---|---|
| 位置 | データパス内 | アウトオブバンド、その横 |
| リアルタイムブロック | ネイティブ | アクセスポイントでの強制が必要 |
| 追加されるレイテンシ | あり、呼び出しごと | なし |
| 故障した場合 | エージェントが停滞、または制御が消失 | 可視性が古くなる。エージェントには影響なし |
| サイレントパスのカバレッジ | 高い（フローを終端するため） | 出力されるシグナル + eBPF バックストップに依存 |
だからこそ製品のスタンスは「プロキシは無用だ」ではなく 必須プロキシなし（no mandatory proxy） なのです。インラインコンポーネントが正解となるパスは存在し、それらは組み合わせて使えます。しかしディスカバリ、つまり棚卸し対象のものを決して停止させてはならない部分は、クリティカルパスに組み込むべき仕事ではありません。
トレードオフを正直に述べる
パッシブディスカバリには本物の弱点があり、それを取り繕うのは、設計を静かに信頼されなくさせるたぐいのストローマン論法でしょう。フローを終端するプロキシは、そのすべてのバイトを見られます。パッシブコレクターは、エージェント、そのランタイム、あるいはリソースが出力すると決めたものしか見られません。完全に 非協調的 なパス、つまりログをほとんど残さず有用なテレメトリも出力しないパスでは、アプリケーションレベルのディスカバリは薄くなります。「何か」が起きたとは推測できても、帰属の特定は難しくなります。
これを致命的にではなく正直に保つものが 2 つあります。
1 つ目は eBPF カーネルバックストップ です。アプリケーションログは不完全だったり、遅延したり、敵対的なケースでは意図的に抑制されたりすることがあります。しかしカーネルに、システムコールを忘れてくれと丁寧にお願いすることはできません。データベースへソケットを開いたり、ファイルを書き込んだりするエージェントは、そのロギングが何を記録すると決めたかに関係なく、システムコール境界に痕跡を残します。これが eBPF を回避不能のグラウンドトゥルースたらしめています。上位レベルのシグナルが食い違ったり沈黙したりしたとき、カーネルの視点が裏付けのレイヤーとなるのです。これはまた、readOnlyHint や destructiveHint のような MCP のツールアノテーションが、ヒントとしては有用でも、MCP 仕様に従い 信頼できない（untrusted） ものとして扱われる理由でもあります。読み取り専用を自称しながら書き込みが観測されるツールは、まさに表面化させる価値のある食い違いであり、その主張を実際に起きたことと照合して初めて捕捉できるのです。
2 つ目は 正直な確度レベル です。すべての観測が同じ重みに値するわけではないため、アクセスマップもそうであるかのように装いません。ソースがエージェント単位の識別情報を持つエッジ、たとえばエージェント ID 付きの協調的な OpenTelemetry や、エージェントが専用のデータベースロールを持つ監査証跡に基づくエッジは attributed（帰属済み）と記されます。部分的なテレメトリから推測されたエッジと、カーネルだけが捉えたすべてのエッジは approximate（近似）と記されます。カーネルシグナルが示すのはプロセス、cgroup、コンテナであり、エージェントではないためです。製品が推測を事実に仕立て上げることは決してありません。レビュアーは、各行をどの程度信頼すべきかを一目で把握できるべきです。
観測から、重要となる差分へ
ディスカバリは入力にすぎません。出力は、ポリシーが許可するもの PERMITTED と、コレクターが実際に見たもの OBSERVED の比較です。その差分が最小権限のドリフトであり、その代表例が、ポリシーが一度も付与しておらず誰もレビューしていない、観測された書き込みです。
アクセスフィードからの数行が、これを具体的にしてくれます。読み取りはありふれたもので、フラグの立った書き込みが本題です。
agent action resource outcome confidence
data-export-job READ s3://billing-exports allowed attributed
data-export-job READ prod-postgres allowed attributed
data-export-job WRITE prod-postgres flagged approximate
support-rag READ internal-wiki-mcp allowed approximate本番データベースを読み取るエクスポートジョブは、何ら注目に値しません。同じジョブが、ポリシーが読み取りしか付与していないのにそこへ「書き込む」というのは、レビューを経ずに通過させてはならないたぐいのエッジです。カーネルは書き込みが起きたことを裏付けますが、示すのはプロセスやコンテナであってエージェントではないため、このエッジは approximate と記されます。
ドリフトを見ることは仕事の半分にすぎず、それを塞ぐことがもう半分です。強制はアクセスポイントに属し、policy-as-code として表現されます。そうすることで、ルールはレビュー可能になります。Olivares AI は Cedar を、デフォルト拒否のロールの上に重ねる forbid オーバーレイとして評価するため、ルールにできるのはアクセスを取り除くことだけです。次のルールは、ロールが何を許していても、シークレットの認証情報に触れるリクエストをすべて拒否します。
permit(principal, action, resource);
forbid(principal, action, resource)
when { resource.kind == "credential" && resource.sensitivity == "secret" };独自の Cedar ルールを書くには Business が必要です。Community では、組み込みロール、ネイティブの拒否オーバーレイ、キルスイッチが適用されます。カスタムロールとスコープ付き権限は Business の機能です。
パッシブディスカバリが許可されていない書き込みを見つけ、アクセスマップがそれをドリフトとして示します。Olivares AI がアクションをブロックするのは、4 つの適用ポイント（Claude Code 内、モデルプロキシ、すべての MCP ツール呼び出し、エージェント間）に限られます。これらのいずれかを通り、かつエージェントのロールが許可しない書き込みは、実行される前に拒否され、署名済みで改ざんを検知できる監査ログに記録されます。データベースへの直接の書き込みは、観測されますがブロックされません。可視性と制御は別個の関心事として保たれ、まさにそれゆえに、ディスカバリレイヤーは read-first であることを許容できるのです。
まとめ
AI エージェントの可視性は、機能の判断である以前に、リスクの判断です。インラインプロキシは、本番環境と影響範囲を共有するという代償と引き換えに、リアルタイムの制御をもたらします。パッシブディスカバリは、本番環境を決して停止させ得ないことと引き換えに、サイレントパスでのリーチをいくらか手放し、その後 eBPF のグラウンドトゥルースバックストップと、実際に何が見えたかについて正直であり続ける確度レベルによって、そのリーチの大部分を取り戻します。インベントリ、すなわち見ることが全仕事であるレイヤーにとって、その非対称性こそが正しいデフォルトなのです。
コレクター、アクセスマップ、監査台帳がどのように組み合わさるのか全体像を知りたい方は、アーキテクチャ概要 が端から端まで解説しています。