Axonius добавляет AI-агентов в свою SaaS-платформу кибербезопасности, не отказываясь от модели изоляции по клиентам, лежащей в основе ее существующего развертывания в AWS, согласно новому кейс-стади в блоге AWS Machine Learning Blog.

Компания использовала Amazon Bedrock AgentCore, чтобы запускать агентов для сотен отдельных клиентских сред. Этот дизайн решает ключевую проблему для поставщиков ПО, добавляющих агентные функции: агент должен быть полезен для многих арендаторов, оставаясь при этом ограниченным данными, API, механизмами идентификации и эксплуатационными затратами того клиента, которого он обслуживает.

AWS описывает архитектуру и заявленные преимущества в публикации, написанной самим вендором. Источник не содержит независимых тестов производительности или комментариев клиентов Axonius, поэтому заявления о масштабе развертывания и операционных результатах следует считать сообщенными AWS.

Axonius сохраняет свою SaaS-модель на основе силосов

Axonius предоставляет платформу intelligence по активам для команд безопасности и ИТ. По данным AWS, сервис сверяет информацию из более чем 1 400 систем и работает с сотнями изолированных клиентских сред. Каждая клиентская нагрузка выполняется в выделенной Amazon Virtual Private Cloud, или Amazon VPC, содержащей такие компоненты, как балансировщики нагрузки, базы данных и общую вычислительную инфраструктуру.

Первый AI-агент, описанный в публикации, анализирует крупные корпоративные среды, выявляет пробелы и риски и интерпретирует миллионы точек данных, поступающих из множества интеграций. AWS говорит, что эта функция предназначена для того, чтобы младшие аналитики могли проводить сложный анализ, не заставляя старших аналитиков тратить часы на ручное расследование.

Вместо того чтобы переводить эту нагрузку в общую SaaS-архитектуру, Axonius хотела, чтобы агент следовал ее существующей модели арендатора. Это решение определило технические требования: агент, работающий с окружением одного клиента, не должен получать доступ к данным другого клиента, при этом он все равно должен интегрироваться с уже существующими схемами аутентификации, развертывания и API сервиса.

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

Три модели развертывания с разными компромиссами

AWS описывает выбор архитектуры через три распространенных шаблона развертывания SaaS-агентов: silo, pool и bridge.

В silo-архитектуре каждый арендатор получает выделенные ресурсы. В применении к AgentCore Runtime это может означать развертывание отдельного агента для каждого клиента. Это дает четкую инфраструктурную границу, но увеличивает число ресурсов, которые нужно выделять, обновлять, мониторить и выводить из эксплуатации.

Модель pool использует общие ресурсы. Один агент может обслуживать нескольких арендаторов, при этом каждая сессия получает отдельный идентификатор сессии. AWS говорит, что AgentCore Runtime предоставляет выделенную microVM для каждой сессии, а разделение между арендаторами обеспечивается средствами на уровне приложения.

Этот подход упрощает развертывание и подключение клиентов, но возлагает больше ответственности на приложение. Агент должен корректно интерпретировать контекст арендатора в каждом запросе и предотвращать кросс-арендаторский доступ. Поведение, специфичное для арендатора, также может потребовать дополнительной условной логики в общем развертывании.

Модель bridge объединяет оба подхода. Среда выполнения агента может быть общей, тогда как более строгий контроль арендаторов применяется на уровне инструментов. В архитектуре, описанной AWS, AgentCore Gateway находится между агентом и исходящими инструментами, позволяя проверять вызовы инструментов на соответствие границам арендатора до выполнения.

AWS представляет этот гибридный шаблон как способ снизить инфраструктурные накладные расходы и при этом сохранить более сильную контрольную точку для доступа к системам клиентов. Кейс-стади не раскрывает все детали производственной реализации, поэтому по доступным данным невозможно оценить, как Axonius распределила все компоненты между общими и выделенными ресурсами.

Идентичность и доступ к инструментам — часть границы изоляции

У Axonius уже был модуль аутентификации и авторизации, работающий на инфраструктуре Amazon EC2, специфичной для каждого арендатора. Требование заключалось в том, чтобы добавить агентов, не заменяя этот поток идентификации.

AWS описывает проект, в котором арендаторы проходят аутентификацию через OAuth 2.0 identity provider, например Amazon Cognito. Токены содержат claim, специфичный для арендатора, например пользовательский идентификатор арендатора. Встроенный JWT-авторизатор в AgentCore Runtime проверяет токен с помощью discovery endpoint identity provider, а агент читает claim, чтобы направлять запросы в правильную клиентскую среду.

Это разделение существенно. Проверка токена устанавливает, что запрос пришел от принятого identity provider, но агент и его инструменты все равно должны корректно применять claim арендатора. На практике граница безопасности зависит как от механизма авторизации платформы, так и от кода, который сопоставляет идентичность с API, хранилищами данных и инструментами.

Тот же принцип применим и к интеграции с сервисами. AWS говорит, что агент, привязанный к арендатору, должен иметь безопасный доступ к API этого арендатора. В публикации AgentCore Gateway представлен как возможная точка принудительного контроля для исходящих вызовов инструментов, создавая слой, где можно проверять контекст арендатора до того, как инструмент взаимодействует с клиентской нагрузкой.

Доказательства, контроль затрат и операционный масштаб

AWS называет учет затрат одним из ключевых требований Axonius, поскольку вызовы модели, как ожидается, составят большую часть расходов агента. Учет по арендаторам может помочь SaaS-провайдеру определить, как устанавливать цену на AI-функцию, задавать лимиты использования и выявлять клиентов или рабочие процессы с необычно высоким потреблением.

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

Наблюдаемость была еще одной заявленной проблемой. AWS говорит, что Axonius требовались мониторинг, алерты и трассировка на уровне всего парка для большого числа агентов, с достаточной детализацией для расследования сбоев. Эти требования делают эксплуатацию агентов отличной от обычного мониторинга приложений. Команды должны понимать не только, доступен ли сервис, но и какие вызовы моделей, инструменты, сессии и права арендатора повлияли на результат.

Доступные доказательства поступают от AWS, а не от независимого аудитора или из интервью с клиентом. AWS сообщает, что AgentCore позволил Axonius развернуть изолированных мультиарендных агентов без создания с нуля собственной инфраструктуры для изоляции вычислений, аутентификации или наблюдаемости. Это заявление вендора о роли платформы, а не независимо проверенное сравнение по времени разработки, безопасности или совокупной стоимости.

Что это значит для разработчиков и корпоративных покупателей

Для SaaS-компаний пример Axonius показывает практическую последовательность добавления агентов: начать с существующей модели арендатора, определить границы данных и инструментов, а затем решить, какие контрольные механизмы должны находиться в runtime, в приложении или на уровне gateway.

Выбор также влияет на экономику продукта. Выделенные ресурсы могут обеспечивать более четкую изоляцию и кастомизацию, но общие runtime могут упростить онбординг и эксплуатацию. Bridge-дизайн может сократить дублирование, но требует тщательного enforcement политики на каждой границе инструмента. Ни одна из моделей не устраняет необходимость тестировать сбои авторизации, некорректные claims арендатора, избыточные права инструментов и случайные утечки данных.

Корпоративные покупатели, оценивающие AI-функции, должны спрашивать у поставщиков, как идентичность арендатора сопровождает запрос агента, авторизуются ли вызовы инструментов независимо, как атрибутируется использование модели и как разделяются трассы для реагирования на инциденты. Эти вопросы особенно важны для ПО безопасности, где агент может обрабатывать конфиденциальную информацию об активах, конфигурации и уязвимостях.

Более широкий рыночный вывод состоит в том, что платформы агентов конкурируют не только доступом к моделям, но и операционными примитивами. Изоляция runtime, интеграция идентичности, gateway, автоматизация развертывания и наблюдаемость могут определить, сможет ли агент перейти от демонстрации к продукту, который SaaS-провайдер способен поддерживать в сотнях сред.

Что смотреть дальше

Следующие сигналы — это конкретные производственные детали от Axonius или AWS: использует ли компания в продакшене общую среду выполнения, выделенные среды выполнения или bridge-схему; как реализован учет затрат на уровне арендатора; и какие controls применяются в коде приложения, а какие — в AgentCore Gateway.

Разработчикам также стоит следить за независимыми свидетельствами относительно накладных расходов на развертывание, обработки инцидентов и тестирования изоляции. Более подробные данные о выборе модели, пропускной способности, задержках и стоимости работы первого агента Axonius помогли бы оценить архитектуру не только по заявленным целям дизайна.

Взгляд Creati.ai

Пример Axonius — это не столько добавление чатбота в продукт безопасности, сколько подгонка выполнения агента под существующий SaaS control plane. Сложная работа заключается в том, чтобы связать идентичность, доступ к данным, инструменты, биллинг, релизы и отладку с арендатором, которому принадлежит запрос.

Кейс-стади AWS показывает, почему управляемая агентная инфраструктура привлекательна для ISV, но не доказывает, что абстракция платформы устраняет риск безопасности на уровне приложения. Главный урок для разработчиков — рассматривать маршрутизацию арендаторов и авторизацию инструментов как критически важные для продукта controls, а затем проверять заявления вендора данными о развертывании и сбоях, прежде чем переходить к крупномасштабной архитектуре.