Встроенный inference-прокси (PEP для /v1/messages)

Встроенный inference-прокси — это точка применения политик для трафика инференса, который не относится к Claude Code: прямые вызовы из SDK и curl, обращающиеся непосредственно к контракту Claude /v1/messages. Решение принимается в корне композиции (cmd/olivares/inferenceproxy.go); modules/inferenceproxy владеет конфигурацией управления по тенантам и политикой DLP на исходящем инференс-трафике, которые служат входными данными для этого решения, а сам модуль ничего не решает относительно живого запроса. Управляемые сервером настройки (server-managed settings) до такого трафика не дотягиваются: собственный ANTHROPIC_BASE_URL полностью их обходит. Прокси встаёт перед api.anthropic.com и выполняет управляемый конвейер in-band — резидентность, доступ к моделям, DLP и content gate, затем определение размера контекстного окна и бюджета — до того, как будет переслан хоть один байт. Запись по умолчанию выполняется до пересылки: авторизованное намерение записывается в журнал с обнаружением подделки (tamper-evident) (ledger) до пересылки, и нет доказательства — нет пересылки (deny-closed). Тенант может отключить это осознанно (record_mandatory: false), и тогда прокси привязывает доказательства после пересылки, best-effort и громко — неудавшаяся привязка сообщается, её никогда не скрывают.

Раньше умолчание было обратным, и разница здесь не академическая: тенант, который ни разу не открывал страницу конфигурации, — это ровно тот, о ком никто не думал, и привязка best-effort делала гарантию доказательства опциональной для всех, кто ничего не выбирал. Два ограничения лучше прочитать, чем обнаружить. Первое: эта позиция управляет только моментом до пересылки — после неё вызов уже состоялся и никакая позиция его не отменит, так что этот путь по построению является «громким пробелом». Второе: оператор, выставивший аудиторский spool в degrade, уже сказал, что делать при его исчерпании. Для тенанта, который никогда не выбирал позицию по доказательствам, этот объявленный degrade побеждает, и вызов пересылается с зафиксированным пробелом. Тенанту, который явно выставил record_mandatory: true, наоборот, будет отказано — его собственный выбор старше выбора spool’а. Предварительный запрос count_tokens для определения размера сам является исходящим трафиком к поставщику, поэтому он выполняется лишь после прохождения всех локальных content gate: промпт, отклонённый DLP или firewall, никогда не передаётся, даже для подсчёта. Это один из четырёх PEP с политикой deny-closed, поставляемых платформой.

Зрелость, без приукрашивания

ЧАСТИЧНО. Разделение честное и намеренное:

• РАБОТАЕТ — конфигурация управления по тенантам и политика DLP на исходящем инференс-трафике: авторинг, хранение и аудит. Два хранилища под /v1/m/inferenceproxy/: синглтон config (переключатели по каждому gate, поведение при недоступности прокси, режим DLP для ответов, обязательность записи) и набор dlp/rules (одно правило на класс чувствительности → allow|deny).
• ПО ЖЕЛАНИЮ, по умолчанию не смонтирован — собственно слушатель /v1/messages. Он по умолчанию привязывается к loopback (127.0.0.1:8448), однако оператор может явно настроить другой адрес; по умолчанию действует режим fail-CLOSED (прокси, который не может принять решение, не должен пересылать), а без развёрнутой оператором конфигурации слушатель не монтируется.

Этот модуль ничего не решает относительно живого запроса. Это долговечная, авторизуемая через консоль политика, которую корень композиции (composition root) читает через Policy(); само решение собирается из существующих seam (EvaluateModelAccess, CheckBudget, резидентность, ClassifySensitivity, проверка контекстного окна) на краю.

In-band-конвейер

Каждый gate по умолчанию включён и остаётся инертным под собственным нативным opt-in, пока не сконфигурирован: DLP — до первого правила, доступ к моделям — до первого гранта, резидентность — только когда закреплён регион, бюджет — пока не появится принуждающий бюджет. Тенант явно ослабляет конкретный gate, и аудит фиксирует, кто открыл периметр. Запись политики DLP для исходящего трафика — операция admin-уровня: разрешать, какому контенту дозволено покидать систему, — это привилегированное изменение управления.

Ограниченный контекст

• Минимум данных по построению. Ни одна сохраняемая строка — конфигурация, правило DLP, аудит — никогда не несёт промпт, ответ, секрет или совпавшее значение PII. Байты, которые прокси инспектирует на лету, снабжаются отпечатком (SHA-256) и привязываются к журналу (ledger) корнем композиции, но никогда здесь не хранятся.
• Это третья опора прокси: протокольная оболочка (разбор, пересылка, ответвление тел запросов/ответов) — это слепой к идентичности Apache-коннектор; управляемый принимающий решения компонент — это движок. Этот модуль владеет только политикой, к которой обращаются оба, — удерживая решение вне границы open-core-коннектора.

Связанное

• Модуль X — управление моделями и провайдерами — политика доступа к моделям и контекстного окна по каждой поверхности, которую применяет этот прокси.
• Запуск Claude Code с Olivares — управляемый путь Claude Code, который покрывается внутрипроцессным хуком; этот прокси — резервный PEP для вызывающих, до которых тот путь не дотягивается.
• Честность и ограничения — что работает, что подключается по желанию, а что находится на стадии проектирования по всей платформе.