Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

Общий принцип работы

Платформа состоит из двух основных модулей: StarGuard Gate (LLM-Firewall) и StarGuard Base (платформа управления). Схема архитектуры StarGuard представлена ниже.

Архитектурная схема платформы

1. Синхронизация конфигурации

StarGuard Gate периодически опрашивает StarGuard Base на наличие обновлений конфигурации. При каждом опросе шлюз также сообщает Core о своей активности (ping), что позволяет интерфейсу отображать статус шлюза. Поведение при получении изменений зависит от их типа:

  • Изменения настроек пользователей (лимиты, права доступа к моделям, состав групп), настроек OIDC, требования авторизации, адреса Meta Saver и интервала опроса — применяются немедленно, без прерывания работы.

  • Изменения режима шлюза, настроек детекторов, обработки вложений, моделей, путей, параметров forward-прокси или политик — StarGuard Gate завершает активные соединения, после чего автоматически перезапускается для повторной инициализации детекторов с новой конфигурацией.

Для сокращения сетевого трафика StarGuard Gate отправляет вместе с запросом хэш текущей конфигурации; если конфигурация на стороне Core не изменилась, ответ возвращается пустым.

Примечание. Изменение любой SafeGuard- или Tool Call-политики затрагивает все шлюзы: они перезапускаются, чтобы применить новый текст политики.

2. Обработка запроса: от пользователя до LLM и обратно

Запрос поступает от пользователя или агента на StarGuard Gate. В зависимости от заголовков и пути запроса шлюз определяет клиентский формат (OpenAI Chat Completions, Anthropic Messages или OpenAI Responses).

Аутентификация. Если на шлюзе настроена OIDC-аутентификация, токен из заголовка Authorization валидируется через OIDC Provider — при неуспешной проверке запрос отклоняется с кодом 401. При использовании статичного токена проверяется совпадение с настроенным значением. Без аутентификации запрос принимается сразу. В режиме forward proxy учётные данные проверяются на этапе установления туннеля; отказ возвращается кодом 407 (неверные учётные данные) или 403 (нет прав на запрошенный Путь).

Обработка вложений. Если в сообщениях запроса присутствуют файлы или изображения, StarGuard Gate обращается к сервису File Recognizer, который извлекает текстовое содержимое. Полученный текст подставляется в сообщение вместо вложения. Поведение при отказе или недоступности сервиса определяется настройкой «При сбое распознавания».

Входные детекторы. Далее запрос передаётся в цепочку входных детекторов. Каждый детектор анализирует текст запроса согласно своей логике — часть детекторов (семантические) при этом обращается к Guard LLM Inference, пользовательский детектор — к внешнему HTTP-сервису. По итогам проверки возможны следующие исходы:

  • Пропуск — запрос продолжает обработку.

  • Блокировка — запрос нарушает политику. Пользователю возвращается заглушка с описанием причины блокировки; к LLM запрос не уходит.

  • Маскирование — чувствительные данные в тексте заменяются на маски. Запрос продолжает обработку с уже замаскированным содержимым.

  • Добавление сообщения — запрос не блокируется, но к ответу LLM добавляется предупреждающее сообщение.

  • Перенаправление — детектор перенаправляет запрос на другую модель (например, на резервную).

Обращение к LLM. Если запрос прошёл все входные проверки, StarGuard Gate отправляет его к настроенному внешнему LLM-провайдеру. Поддерживается как обычный, так и потоковый режим (streaming).

Выходные детекторы. Полученный ответ LLM проходит через цепочку выходных детекторов (Output Safe Guard, Tool Policies Detector и пользовательский детектор ответов). Если ответ заблокирован по выходной политике, пользователю возвращается шаблонный ответ о блокировке вместо ответа модели. Если в исходном запросе применялось маскирование, StarGuard Gate выполняет обратное замещение (демаскирование) — восстанавливает оригинальные значения в ответе перед передачей пользователю.

Примечание. Включение любого выходного детектора переводит потоковый режим в буферизованный — Gate собирает весь ответ полностью перед прогоном детекторов, поэтому первый фрагмент отдаётся клиенту только после полной генерации ответа апстримом.

Аудит и учёт. По завершении обработки, независимо от результата, StarGuard Gate отправляет метаданные события (время, пользователь, модель, применённые политики, количество токенов, стоимость, результаты срабатываний и трассировку) в сервис Meta Saver платформы StarGuard Base, где они сохраняются в ClickHouse. При наличии интеграции с SIEM события дополнительно передаются во внешнюю систему мониторинга. Если для пользователя настроен лимит, StarGuard Gate фиксирует количество использованных токенов и рассчитанную стоимость и обновляет счётчик в сервисе User State.