Безопасное обнаружение инструментов для корпоративных ИИ-агентов: реестр, шлюз и политики

Вопрос, стоящий за инструментами агента

Если предоставить агенту несколько API и позволить модели самой выбрать, какой из них использовать, то доступ к инструментам кажется решенной проблемой. Однако ситуация меняется в корпоративной среде: там каталог содержит сотни или тысячи инструментов. Некоторые из них представляют собой безвредные инструменты для чтения только, другие могут изменять данные клиентов или персональную информацию, а еще небольшая группа может инициировать финансовые операции, перенастраивать счета или выполнять административные действия. «Как агент находит подходящий инструмент?» — это простой вопрос. Сложнее ответить на вопрос о том, как гарантировать, что агент будет видеть и использовать только те инструменты, которые ему разрешены для выполнения конкретного запроса пользователя.

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

Изолировать модель от зоны безопасности

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

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

Теперь измените запрос: если возврат средств ещё не произведён, осуществите его. Агент больше не просто собирает информацию, поскольку это может иметь финансовые последствия. Это небольшое изменение лежит в основе принципа, на котором строится всё остальное:

Агент может обдумать действие и предложить его. О том, будет ли это действие реально выполнено, решает детерминистическая платформа.

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

Реестр инструментов вместо огромного списка

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

Лучшим решением является реестр инструментов — корпоративный каталог возможностей. Он включает не только названия API и схемы данных. Каждая запись содержит метаданные, которые платформа может использовать для поиска, управления и принятия решений по правилам:

• сфера бизнеса, владелец и версия
• возможность чтения или записи данных
• классификация рисков и необходимые функции
• классификация данных
• схемы входных и выходных данных
• характеристики идемпотентности
• требования к аудиту

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

Обнаружение — это не авторизация

Возможно, это самое полезное различие во всей архитектуре: обнаружение инструмента и наличие разрешения на его использование — это разные вещи.

Обнаружение позволяет определить, какие инструменты должны быть предоставлены данному агенту для выполнения конкретной задачи. Авторизация отвечает на вопрос о том, разрешена ли в данный момент конкретная операция.

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

Однако этот фильтр всё ещё не может быть последней линией защиты. Модель может сделать вызов, которого никто не ожидал, неправильно интерпретировать намерение пользователя или быть скомпрометирована через внедрение промптов. Поэтому каждый вызов проходит через контролируемый Tool Gateway по пути к основной корпоративной API.

По сути, шлюз анализирует совокупность фактов (кто является пользователем, какой агент осуществляет вызов, что запрашивается, на каком ресурсе, с какими параметрами, в каком контексте) и применяет соответствующую политику.

Разрешать действие, а не только инструмент

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

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

Здесь подход к безопасности меняется: вместо вопроса о том, имеет ли агент доступ к API возврата средств, ставится вопрос о том, разрешены ли в данном контексте этот пользователь, агент, действие и ресурс.

Когда часть рабочего процесса терпит неудачу

Как только действие разрешено, возникает вторая проблема: что делать, если одна часть рабочего процесса успешна, а другая — нет? Предположим, возврат средств прошел успешно, но письмо с подтверждением — нет. Перезапуск всего рабочего процесса агента может привести к двойному возврату средств.

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

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

Утверждения находятся в ведении политики

ГЛМ также не должен решать, когда человек обязан что-то одобрить. Это вопрос политики. Организация может разрешить автоматическое возврат средств при сумме ниже определенного порога и требовать подтверждения при сумме выше этого порога, всегда требовать одобрения для административных операций, а также вводить меры контроля для транзакций с необычными пунктами назначения или повышенным риском. Модель может указать на возможную необходимость принятия действий. Система политик решает, требуется ли одобрение, а Tool Gateway обеспечивает выполнение этого решения. Это также способствует улучшению управления, поскольку правила явны, подлежат проверке, имеют версии и могут быть аудитированы, и они не скрыты внутри промпта.

Плоскость управления и плоскость выполнения

Учитывая эти сценарии, данная конструкция сильно отличается от простой цепочки «пользователь — ГЛМ — инструменты» и больше похожа на платформу корпоративного управления. Она естественным образом делится на две области.

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

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

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

Оценка действий, а не только ответов

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

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

Основополагающий принцип

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

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