Мультиарендность ИИ-агентов: изоляция учётных данных, разделение пространств имён и SOC 2
Мультиарендность ИИ-агентов — это архитектурное свойство платформы агентов, которое изолирует учётные данные, память, контекст выполнения и записи аудита каждого арендатора от всех остальных арендаторов, применяемое на уровне инфраструктуры, а не с помощью соглашений разработчиков или следования инструкциям агента. В отличие от мультиарендности веб-приложений, агенты хранят активные API-ключи, накапливают постоянную память между запросами и выполняют аутентифицированные вызовы инструментов: три измерения, выходящие за рамки изоляции строк данных, которые должны быть разделены по арендаторам для соответствия OWASP LLM06 и SOC 2 CC6.1.
Мультиарендность ИИ-агентов — архитектурное свойство платформы агентов, гарантирующее, что агенты, обслуживающие разных арендаторов, не могут получить доступ к учётным данным, памяти, контексту выполнения или записям аудита друг друга, применяемое на уровне инфраструктуры через специфичные для каждого арендатора области видимости хранилища учётных данных, ACL пространства имён доски, изолированное выполнение в контейнерах и разделённые журналы аудита, так что продукт B2B SaaS, построенный на платформе, наследует изоляцию арендаторов как структурную гарантию, а не ответственность разработчика.
Почему мультиарендность агентов сложнее, чем у веб-приложений
Традиционная мультиарендность веб-приложений изолирует одно: строки данных. Добавьте столбец tenant_id, фильтруйте каждый запрос — готово. Мультиарендность агентов должна изолировать три дополнительных измерения, с которыми веб-приложения никогда не сталкивались. Сбой в любом из них составляет событие межарендаторской утечки данных согласно OWASP LLM06 о раскрытии конфиденциальной информации.
Три измерения изоляции, которых не было у веб-приложений
Изоляция учётных данных: веб-приложения идентифицируют пользователя через токен сессии; сессия не имеет постоянного доступа к внешним сервисам. Агентам нужны реальные API-ключи, ограниченные арендатором. Если агент арендатора A и агент арендатора B используют один ключ OpenAI, интенсивное использование арендатора A снижает запас скорости арендатора B; счёт арендатора A у поставщика включает потребление токенов арендатора B; отзыв ключа после компрометации арендатора A также прерывает работу арендатора B; журналы использования ключа на панели управления поставщика не могут быть разделены по арендаторам, что нарушает требования логического доступа SOC 2 CC6.1.
Изоляция памяти: агенты накапливают рабочую память (контекстное окно), семантическую память (эмбеддинги векторного хранилища) и состояние координации (записи доски) между взаимодействиями. Если какое-либо из этих хранилищ не разделено по арендаторам, документы арендатора A, извлечённые в контекст агента во время одной задачи, могут появиться в контексте агента арендатора B во время семантически схожей задачи без какого-либо враждебного ввода. Это типичный сценарий межарендаторской утечки OWASP LLM06 v1.1.
Изоляция журнала аудита: общий журнал аудита, в котором смешаны вызовы инструментов арендатора A и арендатора B, не может быть экспортирован команде соответствия арендатора A без раскрытия записей арендатора B. SOC 2 CC6.1 требует, чтобы аудитор каждого арендатора мог видеть только свои записи, что требует разделения на уровне хранилища, а не только фильтрации во время запроса.
Shared-Nothing против Pool против Bridge: три модели мультиарендности
Модель Silo (shared-nothing): каждый арендатор получает полностью выделенную инфраструктуру. Максимальная изоляция при наибольших затратах на арендатора. Подходит для корпоративных арендаторов со строгими требованиями к хранению данных и регулируемых отраслей.
Модель Pool: все арендаторы используют общую инфраструктуру с изоляцией, применяемой только на уровне приложения через фильтрацию параметра tenant_id. Наименьшие затраты, слабейшая изоляция. Подходит только для рабочих нагрузок с низкой чувствительностью без корпоративных клиентов.
Модель Bridge: общая вычислительная инфраструктура с изоляцией, применяемой на плоскости управления. Каждый арендатор получает выделенную область видимости хранилища учётных данных и пространство имён памяти, применяемые ACL инфраструктуры; вычисления используются совместно, но управляются Kubernetes namespace ResourceQuota. Это рекомендуемый стандарт для B2B SaaS. Архитектура OpenLegion на основе проектов является реализацией модели Bridge.
OWASP LLM06: межарендаторское раскрытие конфиденциальной информации
OWASP LLM Top 10 v1.1 классифицирует межарендаторскую утечку данных в LLM06: Раскрытие конфиденциальной информации как высокой степени серьёзности.
Вектор атаки межарендаторской утечки
- Агент арендатора A обрабатывает запрос службы поддержки клиентов. Он извлекает внутреннюю документацию по продукту и записи клиентов арендатора A в своё контекстное окно, затем встраивает и сохраняет соответствующие фрагменты в общем векторном хранилище.
- Агент арендатора B обрабатывает семантически схожий запрос. Он запрашивает общее векторное хранилище; запрос возвращает встроенные фрагменты арендатора A как ближайших соседей Top-K, поскольку они тематически схожи и нет индекса, разделённого по арендаторам.
- Внутренние записи клиентов арендатора A появляются в контексте агента арендатора B.
Враждебный ввод не требуется. Утечка является архитектурным сбоем.
Для полной схемы, включая внедрение подсказок (LLM01), смотрите безопасность ИИ-агентов и модель угроз OWASP LLM Top 10.
Утечка памяти: рабочая память, векторные хранилища и состояние доски
Три типа памяти агента требуют отдельной обработки изоляции арендаторов:
Рабочая память (контекстное окно): текущее контекстное окно агента никогда не должно использоваться совместно для запросов разных арендаторов.
Семантическая память (векторное хранилище): при использовании общего векторного хранилища каждая запись должна включать tenant_id в качестве обязательного поля метаданных, а каждый запрос должен включать фильтр метаданных {tenant_id: current_tenant_id}, вводимый на уровне клиента хранилища.
Состояние координации (доска): совместно используемое состояние ключ-значение между агентами должно использовать префиксы ключей с областью видимости арендатора, например projects/{tenant_id}/*, с применением ACL на уровне mesh.
Изоляция учётных данных: ограничение области видимости хранилища для каждого арендатора
Ограничение учётных данных для каждого арендатора: почему общие API-ключи не работают
Наиболее распространённая ошибка с учётными данными при мультиарендности — использование одного API-ключа LLM для всех арендаторов. Это не работает четырьмя различными способами: совместное использование ограничения скорости, невозможность атрибуции затрат, масштаб отзыва и нарушение изоляции аудита.
Правильный подход: каждый арендатор получает собственный API-ключ. Для полной архитектуры хранилища смотрите управление учётными данными и паттерны ограничения области видимости хранилища для каждого арендатора.
Антипаттерн JWT: область видимости токена без отзыва
Три меры по снижению риска, все обязательные:
- Краткосрочные токены: TTL не более 300 секунд (5 минут) для токенов вызова инструментов агента.
- Активный реестр отзыва: таблица действительных идентификаторов токенов для каждого арендатора.
- Ротация токенов по задачам: выдача нового токена для каждой задачи агента.
Изоляция выполнения: пространства имён Kubernetes и квоты ресурсов
Пространство имён для каждого арендатора: RBAC, NetworkPolicy и ResourceQuota
Требуются четыре компонента:
Пространство имён для каждого арендатора: поды агентов каждого арендатора работают в выделенном пространстве имён Kubernetes.
RBAC с ServiceAccounts, ограниченными пространством имён: каждый арендатор получает выделенный ServiceAccount с RoleBindings, ограниченными его собственным пространством имён.
NetworkPolicy с запретом по умолчанию: применение политики запрета всего входящего и исходящего трафика к каждому пространству имён арендатора по умолчанию.
ResourceQuota с LimitRange: применение ограничений по CPU, памяти и количеству подов для каждого пространства имён через ResourceQuota.
Для контролей песочницы на уровне процессов смотрите песочница ИИ-агентов и изоляция выполнения на уровне процессов.
Соответствие SOC 2 для мультиарендных платформ агентов
CC6.1: контроли логического доступа по классификации данных
Соответствие CC6.1 требует трёх конкретных контролей: область видимости хранилища учётных данных для каждого арендатора, пространство имён памяти для каждого арендатора и раздел журнала аудита для каждого арендатора.
Аудиторы SOC 2 отмечают общие API-ключи, используемые несколькими арендаторами, как несоответствия CC6.1. Для полного отображения контролей смотрите управление ИИ-агентами и системы соответствия SOC 2.
CC6.6: ограничение привилегированного доступа для агентов с расширенными разрешениями
Соответствие CC6.6 требует: структурного предотвращения межарендаторских вызовов агентов с расширенными разрешениями, проверяемых определений разрешений привилегированных агентов и записей аудита для каждого вызова привилегированных действий.
Разделение журнала аудита для каждого арендатора
Паттерн ключа хранилища: audit/{tenant_id}/{year}/{month}/{day}/{agent_id}/{tool_call_id}.json
Политика корзины S3 для каждого арендатора: отдельный префикс корзины с отдельной политикой ресурсов для каждого арендатора.
Атрибуты ресурсов OTLP: включение tenant_id в качестве атрибута ресурса в каждую запись журнала OpenTelemetry.
Рабочее пространство SIEM для каждого арендатора: в общих развёртываниях SIEM настройка индексов или рабочих пространств для каждого арендатора.
Для полного проектирования журнала аудита смотрите журнал аудита ИИ-агентов и записи соответствия для каждого арендатора.
Антипаттерны: чего не следует делать
Антипаттерн 1: идентификатор арендатора в подсказке агента, а не в инфраструктуре
Внедрение tenant_id в системную подсказку агента и зависимость от агента в применении собственной границы арендатора является наиболее распространённым и опасным антипаттерном мультиарендности. Это не работает из-за обхода внедрения подсказки, дрейфа галлюцинаций и отсутствия применения на уровне инфраструктуры.
Антипаттерн 2: общее векторное хранилище без фильтров арендатора
Это основной вектор утечки OWASP LLM06. Исправление требует обязательного поля метаданных tenant_id при каждой записи и фильтра метаданных, вводимого на уровне клиента хранилища при каждом запросе.
Антипаттерн 3: общий API-ключ LLM с заявкой арендатора в подсказке
Этот антипаттерн не соответствует CC6.1: совместное использование ограничения скорости, сбой атрибуции затрат, масштаб отзыва и записи аудита поставщика, которые не могут быть разделены по арендаторам.
Мнение OpenLegion: изоляция архитектурой, а не соглашением
OpenLegion применяет изоляцию арендаторов через три механизма уровня инфраструктуры, которые код агента не может обойти: ограничение области видимости хранилища учётных данных для каждого проекта, ACL пространства имён доски и межпроектные сообщения агентов, заблокированные по умолчанию.
| Контроль изоляции | OpenLegion | LangChain / LangGraph | CrewAI | AutoGen | OpenAI Agents SDK |
|---|---|---|---|---|---|
| Область видимости хранилища учётных данных для каждого арендатора | Применяется инфраструктурой | Соглашение разработчика | Соглашение разработчика | Соглашение разработчика | Соглашение разработчика |
| ACL пространства имён доски | Применяется инфраструктурой | Недоступно | Недоступно | Недоступно | Недоступно |
| Межпроектные сообщения агентов заблокированы | Заблокировано по умолчанию | Недоступно | Недоступно | Недоступно | Недоступно |
| Ограничение бюджета для каждого арендатора (Zone 2) | Применяется инфраструктурой | Соглашение разработчика | Соглашение разработчика | Соглашение разработчика | Соглашение разработчика |
| Раздел аудита для каждого арендатора (WORM) | Применяется инфраструктурой | Соглашение разработчика | Соглашение разработчика | Соглашение разработчика | Соглашение разработчика |
| Пространство имён Kubernetes + ResourceQuota | Управляется платформой | Самоуправление | Самоуправление | Самоуправление | Самоуправление |
Для размещённого уровня инфраструктуры смотрите управляемая платформа ИИ-агентов с гарантиями изоляции арендаторов.
Часто задаваемые вопросы
Что такое мультиарендность ИИ-агентов?
Мультиарендность ИИ-агентов — архитектурное свойство платформы агентов, гарантирующее, что агенты, обслуживающие разных арендаторов, не могут получить доступ к учётным данным, памяти, контексту выполнения или записям аудита друг друга, применяемое на уровне инфраструктуры, а не с помощью соглашений разработчиков. Она отличается от традиционной мультиарендности веб-приложений тем, что требует трёх дополнительных измерений изоляции: ограничения области видимости хранилища учётных данных для каждого арендатора, разделения памяти для каждого арендатора (векторные хранилища и доска) и разделения журнала аудита для каждого арендатора.
Что такое OWASP LLM06 и как он влияет на мультиарендные системы агентов?
OWASP LLM Top 10 v1.1 LLM06 о раскрытии конфиденциальной информации классифицирует межарендаторскую утечку данных как высокой степени серьёзности: сценарий, при котором агент обрабатывает данные арендатора A, сохраняет извлечённые документы в общем уровне памяти без разделения по арендаторам, а затем показывает их в ответе арендатора B. Атака не требует враждебного ввода. Для снижения риска требуется разделение памяти для каждого арендатора на уровне клиента хранилища, ограничение учётных данных для каждого арендатора и разделы журналов аудита для каждого арендатора.
Как SOC 2 CC6.1 и CC6.6 применяются к мультиарендным платформам агентов?
SOC 2 Type II CC6.1 требует ограничения логического доступа на основе классификации данных; в мультиарендной системе агентов граница арендатора является основной границей классификации. CC6.6 применяется к агентам с расширенными разрешениями инструментов, такими как запись в базы данных или вызовы внешних API; эти агенты являются функционально привилегированными пользователями и должны быть структурно предотвращены от обработки запросов за пределами назначенной области арендатора. Общий API-ключ, используемый несколькими арендаторами, как правило, будет отмечен как несоответствие CC6.1.
Какова уязвимость TTL JWT-токена в мультиарендных системах агентов?
JWT-токены доступа, используемые для контекста арендатора в вызовах инструментов агента, обычно истекают через 3600 секунд (1 час); если токен, выданный для арендатора A, кэшируется неправильно, используется совместно из-за ошибки инфраструктуры или фиксируется в журнале отладки, его можно использовать для аутентифицированных вызовов, приписанных арендатору A, в течение всего срока TTL без обнаружения. Для снижения риска требуются три одновременно применяемых контроля: краткосрочные токены с TTL не более 300 секунд, активный реестр отзыва токенов для каждого арендатора и ротация токенов по задачам.
Как работает изоляция пространств имён Kubernetes для мультиарендных агентов?
Изоляция пространств имён Kubernetes обеспечивает изоляцию выполнения через четыре компонента: выделенное пространство имён для каждого арендатора, RBAC с ServiceAccounts для каждого арендатора и RoleBindings с областью видимости пространства имён, NetworkPolicy с запретом по умолчанию и явным списком разрешений только для необходимых внешних конечных точек, и ResourceQuota с ограничениями вычислений для каждого пространства имён. Изоляция пространства имён устраняет вычислительное измерение мультиарендности и должна сочетаться с ограничением учётных данных для каждого арендатора и разделением памяти.
Что такое антипаттерн общего векторного хранилища в мультиарендных системах агентов?
Использование общего векторного хранилища без обязательных фильтров арендатора для каждого запроса, вводимых на уровне клиента хранилища, является основным вектором утечки OWASP LLM06. Правильная реализация требует поля метаданных tenant_id при каждой записи и фильтра метаданных, вводимого на уровне клиента векторного хранилища при каждом запросе. Для строгих требований соответствия пространства имён для каждого арендатора или отдельные индексы применяют ограничения на уровне адресации хранилища.
Как OpenLegion применяет изоляцию арендаторов?
OpenLegion применяет изоляцию арендаторов через три механизма уровня инфраструктуры: ограничение области видимости хранилища учётных данных для каждого проекта (Zone 2 разрешает дескрипторы $CRED{} с использованием аутентифицированного контекста проекта из сессии mesh, а не параметров, предоставленных агентом; межпроектное разрешение учётных данных архитектурно невозможно), ACL пространства имён доски (агенты имеют права на чтение и запись только для префикса ключей своего проекта, применяемые супервизором mesh) и межпроектные сообщения агентов, заблокированные по умолчанию.
Каковы три модели мультиарендности для платформ агентов?
Три модели мультиарендности имеют различные гарантии изоляции и профили затрат: модель Silo (shared-nothing) предоставляет каждому арендатору полностью выделенную инфраструктуру; модель Pool использует всю инфраструктуру совместно с изоляцией только на уровне приложения; модель Bridge использует вычислительную инфраструктуру совместно, применяя изоляцию на плоскости управления через области видимости хранилища учётных данных для каждого арендатора и ACL пространства имён памяти. Модель Bridge является рекомендуемым стандартом для B2B SaaS.