Pryxor — открытый self-hosted-шлюз, который проверяет действия ИИ-агента до того, как они достигнут внешнего сервиса. Проект опубликован на GitHub; в описании разработчик предлагает разделить агента, точку принятия решения и исполнителя с реальными учетными данными.
Идея не в том, чтобы отозвать у агента все доступы, а в том, чтобы не считать наличие действительного токена достаточным основанием для каждой операции. Агент формирует вызов, Pryxor проверяет его, а доверенный исполнитель обращается к внешнему API.
Проверка на границе действия
По описанию проекта, шлюз аутентифицирует агента, проверяет аргументы вызова и применяет детерминированные правила. Результат — одно из трех решений: разрешить действие, заблокировать его или поставить на удержание для дальнейшего рассмотрения.
Это отличается от обычной авторизации на уровне API. Она отвечает, может ли конкретная учетная запись обращаться к сервису. Pryxor нацелен на более узкий вопрос: допустим ли именно этот вызов с такими параметрами в текущей конфигурации политики.
В качестве примера в проекте приведена отправка письма. Демонстрация использует имитацию HTTP-эндпоинта и, согласно описанию, не отправляет настоящее сообщение. Это важно: пример показывает работу механизма, но не подтверждает готовность системы к эксплуатации с реальными почтовыми или платежными сервисами.
Что получает разработчик
Pryxor предлагает выполнять реальные запросы через отдельного исполнителя, который использует учетные данные внешнего сервиса. Агенту не передаются адрес upstream API и секрет исполнителя в рамках контракта выполнения. Такой разрыв может упростить централизованный контроль и аудит действий, если интеграция действительно устроена через этот путь.
В репозитории есть инструкции для локального запуска через `make init`, `make up` и `make health`, а также пример регистрации агента и вызова инструмента. Это позволяет проверить заявленный сценарий на тестовом окружении. Однако наличие демонстрации само по себе ничего не говорит о надежности, масштабировании или пригодности проекта для конкретной инфраструктуры.
Чего Pryxor не обещает
Разработчик прямо оговаривает: Pryxor не является LLM-файрволом и сам по себе не понимает намерения пользователя. Он применяет явные правила к действиям и аргументам, а не определяет, «хотела ли» модель отправить письмо или изменить запись. Поэтому качество защиты зависит от того, какие политики настроены и какие действия проходят через шлюз.
Отдельно описан статус HOLD: это не ошибка, после которой агенту следует просто повторить запрос. Такое решение предполагает остановку действия и, вероятно, отдельный процесс подтверждения. Конкретные правила согласования и их применение нужно проверять по документации и коду проекта.
Практическая ценность подхода — в переносе контроля с общих прав учетной записи на конкретную операцию. Но это дополнительная точка в архитектуре, которую придется развернуть, настроить и включить во все нужные маршруты. Если агент сможет обращаться к сервису напрямую, шлюз не станет обязательным барьером.
