インライン推論プロキシ（/v1/messages 向け PEP）

インライン推論プロキシは、Claude Code で ない推論トラフィック、すなわち Claude の /v1/messages コントラクトに 直接アクセスする生の SDK や curl の呼び出し元に対する強制ポイントである。 判断はコンポジションルート（cmd/olivares/inferenceproxy.go）で行われ、 modules/inferenceproxy は、その判断で参照されるテナント単位のガバナンス設定と 推論エグレス DLP ポリシーを 所有するが、同モジュール自体はライブリクエストについて何も判断しない。 サーバー管理の設定はそのトラフィックに届かない。カスタムの ANTHROPIC_BASE_URL がそれらを完全にバイパスするためだ。このプロキシは api.anthropic.com をフロントに立て、いずれかのバイトが転送される前に、 ガバナンスされたパイプライン（residency、モデルアクセス、 DLP と content gates、その後に context-window sizing と予算）をインバンドで実行する。

記録はデフォルトで転送前に行われる。認可された意図は転送の前に 改竄検知可能な台帳へ書き込まれ、証跡がなければ転送もない（deny-closed）。 テナントは意図的にこれを無効化でき（record_mandatory: false）、その場合は 証跡を転送後にベストエフォートかつ声高にアンカーする——アンカーの失敗は 必ず報告され、決して隠されない。

このデフォルトは以前は逆であり、その差は机上のものではない。設定ページを 一度も開いたことがないテナントは、まさに誰も検討していないテナントであって、 それをベストエフォートでアンカーすることは、何もオプトインしていない者すべてに 対して証跡の保証をオプトインにしていた。発見する前に読んでおくべき限界が 二つある。第一に、この姿勢が支配するのは転送前の瞬間だけである。転送後は 呼び出しが既に発生しており、どんな姿勢もそれを取り消せないため、その経路は 構造上「声高なギャップ」となる。第二に、監査スプールを degrade に設定した オペレーターは、枯渇時にどうすべきかを既に述べている。証跡の姿勢を一度も 選択していないテナントについては、その宣言された degrade が優先され、 呼び出しは記録されたギャップを伴って転送される。明示的に record_mandatory: true を設定したテナントは逆に拒否される——テナント自身の 選択がスプールの設定に優先する。 count_tokens sizing pre-flight はそれ自体が provider egress であるため、すべての local content gate を通過した後にのみ実行される。DLP または firewall で拒否された prompt は、カウントのためでさえ決して送信されない。プロキシはプラットフォームが提供する 4 つの deny-closed PEP の 1 つである。

成熟度、率直に述べる

PARTIAL（部分的）。 この切り分けは正直かつ意図的である。

• 稼働中 — テナント単位のガバナンス設定と推論エグレス DLP ポリシー、 すなわちオーサリング、永続化、監査。/v1/m/inferenceproxy/ 配下に 2 つの ストアがある。シングルトンの config（ゲート単位のトグル、プロキシダウン時の フェイルポスチャ、レスポンス DLP モード、記録の必須化）と、dlp/rules セット（感度クラスごとに 1 ルール → allow|deny）である。
• オプトイン、デフォルトでは未マウント — 実際の /v1/messages リスナー。 デフォルトではループバック（127.0.0.1:8448）にバインドするが、 オペレーターは別のバインドアドレスを明示的に設定できる。デフォルトで fail-CLOSED（判断できないプロキシは転送してはならない）であり、 オペレーターがプロビジョニングしない限りマウントされない。

このモジュールはライブリクエストについて何も判断しない。これは、 コンポジションルートが Policy() 経由で読み取る、永続的かつコンソールで オーサリング可能なポリシーである。判断は既存のシーム （EvaluateModelAccess、CheckBudget、residency、ClassifySensitivity、 コンテキストウィンドウチェック）からエッジで構成される。

インバンドのパイプライン

各ゲートはデフォルトで有効であり、設定されるまでそれぞれ独自のネイティブな オプトインの下で不活性のままとなる。DLP は最初のルールまで、モデルアクセスは 最初のグラントまで、residency はリージョンがピン留めされたときのみ、予算は 強制する予算が存在するまで不活性である。テナントは特定のゲートを明示的に 緩和し、監査は誰が境界を開いたかを記録する。DLP エグレスポリシーの記述は admin-tier である。どのコンテンツが外部に出てよいかを承認することは、 特権的なガバナンス変更だからだ。

境界づけられたコンテキスト

• 構造上、最小限のデータ。 このモジュールが永続化する行（設定、DLP ルール、 監査）は、プロンプト、レスポンス、シークレット、マッチした PII 値を一切 保持しない。プロキシが通過中に検査するバイトは指紋化（SHA-256）され、 コンポジションルートによって監査台帳にアンカーされ、ここには決して 保存されない。
• これはプロキシの第 3 の脚である。プロトコルシェル（パース、転送、 ボディの分岐）はアイデンティティを持たない Apache コネクタであり、 ガバナンスされた判断器はエンジンである。このモジュールは両者が参照する ポリシーのみを所有し、判断を open-core のコネクタ境界の外に保つ。

関連

• Module X — モデルおよびプロバイダー管理 — この プロキシが強制するモデルアクセスおよびサーフェス単位のコンテキストウィンドウ ポリシー。
• Olivares で Claude Code を実行する — イン プロセスフックがカバーするガバナンスされた Claude Code パス。このプロキシは、 そのパスが到達できない呼び出し元向けのフォールバック PEP である。
• 正直さと限界 — プラットフォーム全体で何が稼働中、 オプトイン、または設計段階であるか。