Если вы уже инвестировали в AI gateway или в Guardrails гиперскейлера, первое, что стоит сказать честно: оставьте их — Olivares AI не пытается их заменить. Задача gateway — вызов модели: маршрутизировать, кешировать, балансировать, бюджетировать. Задача Guardrails — безопасность контента в этом вызове. Оба реальны, оба хорошо делают своё дело, и ни один из них не является тем, что представляет собой Olivares.
TL;DR: Olivares AI не является общим AI-шлюзом: он не кэширует и не балансирует трафик моделей и не заявляет никакой универсальной матрицы поставщиков, моделей или маршрутизации. Он разрешает политики маршрутизации в упорядоченную цепочку резервных вариантов и имеет один измеренный путь выполнения — deny-closed, действующий только через настроенный вами клиент, совместимый с Claude Messages, напрямую или с эндпоинтом вашего шлюза в качестве базового URL Messages. За пределами этого пути это плоскость управления и доказательств: внутрипроцессное применение в среде агента, защищённый от подделки журнал, жизненный цикл нечеловеческих идентичностей и human-in-the-loop / break-glass / kill-switch над активными сессиями. Он дополняет шлюз, который вы уже используете, а не заменяет его.
Что gateway и Guardrails делают хорошо (используйте их для этого)
Это устоявшиеся, хорошо понятные возможности, и вендоры описывают их ясно:
- AI gateways — это менеджеры пути запроса для вызовов моделей. LiteLLM — это “OpenAI Proxy Server (LLM Gateway) to call 100+ LLMs in a unified interface & track spend, set budgets per virtual key/user” (LiteLLM); Cloudflare AI Gateway позволяет “Connect to any model, dynamically route requests, and manage usage, billing, and logs from one unified gateway” (Cloudflare); Portkey “records real-time API requests, including cost” (Portkey). Маршрутизация, fallbacks, кеширование, виртуальные ключи, бюджеты на ключ, логирование запросов — это их область.
- Guardrails гиперскейлеров — это фильтры безопасности контента. Bedrock Guardrails “provides configurable safeguards to help you build safe generative AI applications”, которые “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — фильтры контента, запрещённые темы, фильтры слов, редактирование PII, проверки contextual grounding и automated reasoning (AWS).
Если ваша задача — «дать моим приложениям один endpoint ко многим моделям, с бюджетами, кешированием и фильтрацией контента», этот стек её решает, и вам не нужен control plane для этого. Мы интегрируемся с этим паттерном; мы не переимплементируем его.
Что каждый продукт документирует сегодня
Прочитано 2026-09-12 на собственных страницах поставщиков. Это границы прочитанных страниц, а не утверждения о продукте целиком, и ни одна строка не является рейтингом.
| Продукт | Документированная поверхность для агентов | Что страница не охватывает |
|---|---|---|
| LiteLLM | В документации прокси есть раздел “Agent & MCP Gateway”, а также Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | Прочитанная страница документирует поверхность прокси; применение правил внутри среды агента, которая его не проходит, остаётся за её пределами |
| Portkey | В списке продуктов указаны Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | Прочитанная страница — обзор возможностей; она не описывает карту доступа «разрешено против наблюдаемого» по всему парку |
| Cloudflare AI Gateway | ”An intelligent control plane for your AI applications” — “Connect to any model, dynamically route requests, and manage usage, billing, and logs”, “fallback routing, rate limiting, and safety guardrails” (Cloudflare) | Прочитанная страница — обзор продукта; самостоятельное размещение или изолированная эксплуатация этого уровня на ней не описаны |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, применимы встроенно или “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | Это страницы о безопасности контента; жизненный цикл идентичности агента, вмешательство в сессию и согласования не являются их темой и там не документированы |
Поэтому прежняя формулировка была неверной. «Шлюзы не видят агента» не выдерживает проверки приведёнными страницами: LiteLLM и Portkey документируют поверхности для агентов и MCP, а Cloudflare называет свой шлюз плоскостью управления. Различается то, где применяются правила и какого рода запись получается, — это сравнение архитектур, а не утверждение об отсутствии.
В чём архитектуры всё ещё различаются
Условно, а не универсально: каждая строка верна, когда выполняется условие слева.
| Если ваши агенты… | Тогда продукт на пути запроса | Тогда Olivares AI |
|---|---|---|
| …обращаются к моделям только через прокси | управляет каждым вызовом, который видит, на уровне запроса | мало что добавляет на самом пути запроса |
| …также работают локально и обращаются напрямую к БД, объектным хранилищам, MCP или файлам | не видит вызовы, которые его не проходят | применяет deny-closed внутри процесса на агенте, до запуска инструмента |
| …нуждаются в записи, которую аудитор проверит вне системы | выдают логи запросов — изменяемые записи | журнал только на добавление, связанный хешем, подписанный Ed25519, проверяемый вне системы |
| …должны останавливаться посреди сессии | это не место, где останавливают активную сессию | согласования HITL, break-glass и kill switch с повторным включением по двойному контролю |
| …должны быть идентифицированы на протяжении всей жизни | virtual key — это бюджетная корзина | жизненный цикл нечеловеческих идентичностей: блокировка по устареванию, каскад отключения, ротация по двойному контролю |
| …должны оставаться внутри вашего периметра | SaaS-плоскости обрабатывают этот трафик в своём облаке | самостоятельное размещение или изоляция; плоскость данных не покидает ваш периметр |
Путь выполнения Olivares и его реальные ограничения
Olivares действительно затрагивает инференс — в одном измеренном месте, и честное описание то, которое несёт его собственное текущее измерение:
- Маршрут
POST /routing-policies/{id}/executedeny-closed по построению и действует только через клиент, совместимый с Claude Messages, напрямую или с разрешённым эндпоинтом шлюза в качестве базового URL Messages — то есть ваш существующий шлюз может быть этим эндпоинтом. - Разрешение политик создаёт упорядоченную цепочку резервных вариантов. Модуль всегда разрешает маршрут и действует только через порт исполнителя; исполнитель по умолчанию не подключён, поэтому маршрутизация разрешается без единого вызова поставщика, пока оператор его не соберёт.
- Два deny-closed шлюза области и стоп-шлюз kill-switch выполняются до бюджетного шлюза FinOps, который выполняется до исполнителя.
И что он явно не устанавливает, словами той же записи:
- никакой универсальной матрицы поставщиков или моделей — протокол Claude Messages устанавливает один настроенный маршрут, а не матрицу;
- никакого централизованного хранения ключей — поля ключей поставщика являются ссылками;
- никакого выполнения из консоли — консоль разрешает и проверяет политики и не имеет вызова выполнения.
Это измерение текущих источников, а не принятие возможности: действующая запись claims считает эту и все прочие возможности реализованными и непринятыми, без какой-либо квитанции о выполнении. Читайте это как форму пути, а не как сертифицированную функцию.
О Guardrails конкретно: безопасность контента — это hook, а не конкурент
Bedrock Guardrails может применяться двумя способами — inline во время вызова
inference в Bedrock, или “directly through the ApplyGuardrail API without
invoking the foundation models”, что работает “with any foundation model
whether hosted on Amazon Bedrock or self-hosted models”
(AWS). Это действительно полезно,
и Olivares рассматривает безопасность контента как детектор, который вы
подключаете, а не стену, которую мы просим выбрать вместо Guardrails. Два
честных и отдельных факта:
- Inline inference proxy предоставляет шов инспекции контента — подключаемую точку, где детектор контента / DLP возвращает вердикт, по которому действует deny-closed decider. Безопасность контента принадлежит туда, в pipeline, а не реимплементируется как конкурирующий фильтр.
- Olivares читает собственные решения ваших Guardrails в режиме read-first.
AWS-коннектор принимает решения Bedrock guardrails из их логов
CloudWatch / S3 как posture и evidence; он намеренно не вызывает платный
runtime
ApplyGuardrailсамостоятельно. Ваши вердикты по контенту становятся частью tamper-evident record.
Таким образом, безопасность контента компонуется с тем, что вы уже используете. Чего Guardrails не документируют — и где пробел управления остаётся открытым — это остальная часть жизни агента: страницы Bedrock не документируют identity агента, управление сессиями, человеческие одобрения и управление стоимостью (не документировано на этих страницах, проверено 2026-09-12). Olivares — это именно тот дополнительный компонент: он несёт identity, контроли сессий, одобрения и evidence; фильтр контента остаётся там, где он уже живёт.
Как они компонуются
Здоровая конфигурация оставляет каждый инструмент в своей полосе:
- Оставьте ваш gateway (LiteLLM / Portkey / Kong / Cloudflare) как плоскость вызовов моделей — маршрутизация, кеширование, виртуальные ключи, бюджеты на запросе.
- Оставьте ваши Guardrails (Bedrock / Azure Content Safety) как детектор
безопасности контента — PEP Olivares запускает подключаемый детектор в своём
шве инспекции контента и читает собственные решения ваших Guardrails в режиме
read-first как evidence; он не вызывает
ApplyGuardrailсамостоятельно. - Добавьте Olivares рядом как плоскость управления и evidence: PEP в процессе на агентах, которые никогда не проходят через ваш gateway, access map по всей инфраструктуре, tamper-evident ledger и live-контроли HITL/break-glass/kill.
Единственное место, где Olivares касается inference, узкое и явное — путь
gateway только с API key для прямых вызовов SDK/curl, описанный в
Управление агентами с аутентификацией по подписке.
Он существует для управления трафиком, который ваши другие инструменты не могут
охватить, никогда — для конкуренции с ними в маршрутизации, и он никогда не
переносит credential подписки.
Когда вашего gateway достаточно
Честность работает в обе стороны. Если ваши агенты вызывают модели только через ваш gateway, ваши потребности в безопасности контента покрыты Guardrails, у вас нет self-hosted или работающих на ноутбуках агентов, обращающихся к базам данных / object stores / MCP напрямую, и у вас нет требований к суверенитету или tamper-evident evidence — тогда вашего gateway вместе с его логами и Guardrails может быть достаточно, и вам не стоит добавлять control plane ради самого control plane.
Olivares оправдывает своё место, когда вопросы становятся инфраструктурно-масштабными и состязательными: какие агенты существуют и к чему каждый из них реально обращался, могу ли я остановить плохое действие deny-closed в агенте, кто одобрил рискованное, и могу ли я передать аудитору неизменяемое доказательство — всё без отправки этой картины в чужое облако. Для более глубокого рассмотрения двух смежных сравнений см. vs AI control towers и vs LLM observability.