Как OrcaRouter инспектирует каждый запрос

Шлюз находится между вашим агентом и каждой вызываемой им моделью. Это делает его единственной точкой, которая видит каждый вызов независимо от провайдера — каждый промпт, каждый ответ, каждый вызов инструмента и каждый исходящий запрос, маршрутизируемый через него вашим агентом — независимо от того, какой SDK инициировал вызов. В этой точке принадлежат инспекция и применение. (То, что он не может видеть — инструмент, работающий целиком внутри вашего процесса и никогда не пересекающий шлюз — рассмотрено в §4.) На этой странице объясняется, что именно шлюз может и не может видеть, как работает детектирование и как закрыть пробелы.

​

1. Почему шлюз является правильной точкой инспекции

Большинство средств безопасности живут в приложении: обёртки библиотек, хуки агентских фреймворков, SDK для каждого провайдера. У этих средств есть фатальный структурный недостаток — они ломаются, как только вы добавляете второго провайдера, меняете фреймворки или позволяете агенту самостоятельно установить новый навык. У шлюза нет этих швов. Каждый вызов вашего агента, независимо от модели, провайдера или способа появления возможности инструмента, проходит через единственную точку до того, как что-либо достигнет вышестоящего сервиса. Это единственный слой, где вы можете дать гарантию: если это произошло, шлюз это видел. OrcaRouter использует эту позицию для двух различных проходов применения:

• Guardrails проверяют текст — промпт, который отправляет ваш агент, и ответ, который возвращает модель. Блокировка guardrail возвращает HTTP 400 guardrail_blocked и не стоит квоты.
• Firewall оценивает действия — инструменты, которые вызывает агент, MCP-серверы, к которым он обращается, и сетевые адреса назначения, которые он сообщает. Deny firewall возвращает HTTP 400 firewall_blocked на поверхности inbound или ошибку инструмента на поверхности MCP, чтобы модель видела отказ и могла рассуждать о нём.

Оба слоя настраиваются один раз в вашем рабочем пространстве и привязываются к API-ключу. Без передеплоя. Без изменений SDK. Ваш агент продолжает вызывать https://api.orcarouter.ai/v1 ровно так же, как раньше.

​

2. Четыре поверхности применения

Firewall оценивает каждый вызов инструмента ровно по одной поверхности — точке в жизненном цикле вызова, где шлюз его видит. Guardrails добавляют ещё две текстовые стадии, накладывающиеся поверх вышеперечисленных поверхностей: input (промпт и сообщения запроса) и output (текст ответа модели). Один запрос может пройти через все из них.

​

3. Детектирование при первом использовании

Это означает, что новый инструмент появляется в представлении Discovered tools в момент своего появления в запросе, даже если ни одно правило его не называет. Включите observe mode, чтобы записывать каждый вызов инструмента, не имеющего совпадающего правила, как пробел в покрытии — это представление управляет написанием политики на основе реального трафика.

​

4. Что шлюз не может видеть

Гарантия инспекции распространяется на вызовы, пересекающие шлюз. Она не распространяется на инструмент, который ваш агент запускает целиком внутри собственного процесса — тот, который читает локальный файл, вызывает функцию библиотеки или выполняет подпроцесс, никогда не отправляя сообщение шлюзу. Это честная граница, а не конструктивный недостаток. Цель дизайна — сделать шлюз аудируемым путём для вызовов, которые имеют значение — тех, которые имеют последствия в реальном мире: Если у вас есть инструменты, работающие сегодня внутри процесса с последствиями в реальном мире, путь к покрытию — зарегистрировать их как MCP-серверы за MCP gateway Firewall или вызывать хук evaluate из цикла вашего агента перед диспетчем.

​

5. Ролевое ограничение доступа к данным инспекции

Доступ к поверхностям инспекции ограничен ролями в рамках вашего рабочего пространства:

​

6. Дальнейшие шаги

Шлюз — единственная точка инспекции для каждого пересекающего его вызова — настройте свои политики один раз, и каждый провайдер, каждый агент и каждый вызов инструмента будут охвачены.