Управление инструментами агентов через шлюз AI API: объемы работ, утверждения, бюджеты и журналы аудита

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

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

В этой статье собраны факты, рекомендации и прогнозы. Факты взяты из текущих публичных рекомендаций: Топ-10 приложений LLM OWASP включает такие риски, как раскрытие конфиденциальной информации, уязвимости цепочки поставок и чрезмерное агентство; Профиль генеративного ИИ NIST для системы управления рисками ИИ уделяет особое внимание картированию, измерению и управлению рисками генеративного ИИ; Руководство агента OpenAI рекомендует оценивать риск инструмента по доступу для чтения/записи, обратимости, разрешениям и финансовому влиянию; а в руководстве по авторизации MCP используются концепции авторизации с ограниченной областью действия для конфиденциальных ресурсов и операций. Приведенные ниже рекомендации представляют собой шаблоны реализации, а не универсальные требования.

Проблема читателя: путают доступ к модели и доступ к инструментам

Во многих ранних приложениях LLM ключ API отвечал на один основной вопрос: может ли этот сервис вызывать модель? Агенты делают это слишком грубо. Ключ, который может отправлять завершения чата, не должен автоматически экспортировать данные о клиентах, запускать команды оболочки, публиковать сообщения в Slack, изменять заявки, просматривать произвольные веб-сайты или вносить изменения в платежи.

Уровень управления должен отвечать на более конкретные вопросы:

<ул>

Какой клиент, рабочая область, пользователь, учетная запись службы или клиент-посредник инициировали запуск?

Какая модель, шаблон запроса, версия агента и схема инструмента использовались?

Был ли запрошенный инструмент доступным только для чтения, обратимым, необратимым, внешним, финансовым или привилегированным?

Имеет ли запрашивающая сторона необходимые возможности?

Было ли одобрение требуемым, предоставленным, отклоненным, срок его действия истек или было обойдено политикой чрезвычайной ситуации?

Сколько стоил инструмент, сколько раз его вызывали и какой совокупный бюджет остался?

Какие существуют доказательства для отладки, проверки соответствия и отката?

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

Эталонная архитектура: уровень управления инструментом на уровне шлюза

Практическая система управления агентами состоит из семи компонентов:

<ол>

Реестр инструментов. авторитетный список одобренных инструментов, серверов MCP, размещенных функций, инструментов локального выполнения и внутренних API.

Уровень идентификации и ключа: ключи шлюза, пользователи, клиенты, сервисные учетные записи, команды и клиенты-посредники.

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

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

Рабочий процесс утверждения: утверждение человеком или системой действий с высоким уровнем риска перед их выполнением.

Книга ограничений бюджета и ставок: ограничения для каждого инструмента и каждого агента, а не только ограничения для каждой модели.

Хранилище аудита и трассировки: объединенные записи вызовов моделей, вызовов инструментов, утверждений, ошибок и результатов.

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

Шаг 1. Создайте центральный реестр инструментов

Реестр инструментов — это инвентарь, который не позволяет «возможностям неизвестного агента» стать стандартными. У каждого инструмента должен быть владелец, уровень риска и операционные метаданные. Минимальная запись реестра может выглядеть так:

{
  "tool_id": "crm.create_ticket",
  "display_name": "Создать заявку в службу поддержки CRM",
  "owner_team": "автоматизация поддержки",
  "execution_type": "internal_api",
  "server_url": "https://tools.internal.example/crm",
  "allowed_tenants": ["предприятие", "поддержка"],"allowed_models": ["general-large", "general-fast"],
  "risk_tier": "reversible_write",
  "data_classification": "customer_metadata",
  "required_scopes": ["tool:crm.create_ticket"],
  "approval_policy": "not_required_under_100_tickets_per_day",
  «default_timeout_ms»: 8000,
  «max_cost_per_call_usd»: 0,05,
  "max_calls_per_run": 3,
  "rollback_owner": "вызов службы поддержки",
  "retention_policy": "redacted_30_days"

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

Рекомендуемые поля реестра

<ул>

Название инструмента, канонический идентификатор, владелец и контактное лицо.

Место выполнения: инструмент размещенного поставщика, сервер MCP, внутренний API, рабочий браузер, средство выполнения кода, задание очереди или локальный инструмент SDK.

Разрешенные арендаторы, команды, пользователи, версии агентов и профили моделей.

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

Уровень риска и обратимость.

Необходимые области применения и политика утверждения.

Тайм-ауты, ограничения скорости, максимальное количество вызовов за сеанс, совокупный бюджет запуска и максимальная стоимость звонка.

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

Инструкции по откату и путь эскалации.

Шаг 2. Отделите области действия модели от областей действия инструментов

Ключ производственного шлюза должен отражать то, что может сделать вызывающая сторона. Доступ к модели и доступ к инструментам должны быть независимыми. Например:

модель:чат
модель:вложения
инструмент:docs.search_readonly
инструмент: crm.create_ticket
инструмент:email.send_requires_approval
инструмент:billing.refund_blocked
инструмент:code.execute_blocked

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

<ул>

Помощник разработчика: чат модели, поиск документации, объяснение кода, отсутствие инструментов для написания рабочей версии.

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

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

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

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

Рекомендуется закрывать при сбое: неизвестные инструменты запрещены, отсутствующие области запрещают выполнение, недавно объявленные инструменты MCP неактивны до тех пор, пока не будут одобрены, а локальные инструменты должны использовать ту же оболочку политики, что и размещенные инструменты.

Шаг 3. Классифицируйте инструменты по радиусу взрыва

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

<таблица> <голова> Уровень рискаПримерыКонтроль по умолчанию <тело> Публикация только для чтенияПоиск в общедоступных документах, получение общедоступных веб-сайтовРазрешено с ограничениями скорости Внутренний доступ только для чтенияВнутренняя вики-страница, документация по продуктуРазрешено для групп с ограниченной областью действия; редактировать журналы Данные о клиентах, доступные только для чтенияПоиск учетной записи, история поддержкиПроверка арендаторов и пользователей; строгий аудит Обратимая записьСоздать заявку, добавить черновую заметкуРазрешить с ограничениями и откатом владельца Внешнее общениеОтправка электронной почты, публикация сообщений, публикация контентаУтверждение или предварительный просмотр для большинства случаев использования Необратимая записьУдалить запись, отправить юридическую формуОтклонить по умолчанию или потребовать одобрения высокого уровня доверия Финансовые действияВозврат денег, покупка, изменение счетаНадежное одобрение, низкие лимиты, полный аудит Выполнение кодаЗапуск оболочки, выполнение Python, развертывание сценарияПесочница, сетевые ограничения, тайм-ауты, утверждение при необходимости Привилегированный администраторСоздать пользователя, изменить роли, сменить учетные данныеЗапретить по умолчанию; только процесс разбития стекла

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

Шаг 4. Добавьте шлюзы одобрения для действий с высоким риском

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

Общий процесс утверждения:

<ол>

Агент запрашивает вызов инструмента со структурированными аргументами.

Шлюз оценивает личность, объем, уровень риска, бюджет и политику.

Если требуется утверждение, шлюз возвращает ожидающее событие утверждения вместо запуска инструмента.

Приложение показывает пользователю предварительный просмотр или отправляет уведомление в канал утверждения.

Утверждающее лицо может утверждать, отклонять, редактировать аргументы, если это разрешено политикой, или запрашивать разъяснения.

Шлюз записывает решение и выполняет только утвержденную версию.

Полезные данные утверждения должны отображать действие в человеческом понимании, а не только в виде необработанного JSON:

{
  "approval_id": "appr_123",
  "agent_run_id": "run_456",
  "requested_by_user": "user_789",
  "tool_id": "email.send",
  "risk_tier": "external_communication",
  "summary": "Отправьте ответ на адрес [email protected] по поводу заявки № 4812",
  "редактированные_аргументы": {
    "кому": "[email protected]",
    "subject": "Обновление по заявке № 4812",
    "body_hash": "sha256:..."
  },
  "expires_at": "2026-08-09T12:30:00Z"

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

Шаг 5. Отслеживайте бюджеты и ограничения по каждому инструменту

Бюджета токенов недостаточно. Дешевая модель может вызвать дорогостоящие поисковые запросы, сеансы браузера, запуск кода, вызовы сторонних API или длинные циклы инструментов. Шлюз должен отслеживать как минимум четыре счетчика:

<ул>

Количество вызовов для каждого инструмента: максимальное количество вызовов за запуск, пользователя, клиента и временной интервал.

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

Совокупная стоимость работы агента: токены модели плюс затраты на инструменты.

Глубина цикла: максимальное количество итераций модель-инструмент-модель.

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

Шаг 6. Объединение телеметрии модели и инструмента в одну запись аудита

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

<ул>

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

Идентификатор агента, версия агента, версия шаблона приглашения и идентификатор модели.

Имя инструмента, версия реестра, URL-адрес сервера или среда выполнения, а также хеш схемы.

Хеш входных данных инструмента или отредактированные входные данные, по умолчанию никогда необработанные конфиденциальные полезные данные.

Статус утверждения, личность утверждающего, временная метка утверждения и хеш утвержденного аргумента.

Задержка, повторные попытки, ошибки поставщика, ошибки инструментов, стоимость токена, стоимость инструмента и конечный результат.

Ссылка на откат, если действие изменило состояние.

Документация по отслеживанию OpenAI Agents SDK включает трассировки для генерации LLM, вызовов инструментов, передач обслуживания, ограждений и пользовательских событий, что поддерживает более широкий принцип наблюдения: трассировки агентов должны включать в себя активность инструмента, а не только использование токенов и задержку. Однако один конвейер SDK не может охватывать все размещенные инструменты, локальные пути выполнения или внутренние API. Аудит на уровне шлюза помогает нормализовать записи между поставщиками и платформами.

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

Шаг 7. Относитесь к серверам MCP и сторонним инструментам как к зависимостям цепочки поставок

Серверы MCP и сторонние инструменты должны пройти тот же процесс проверки, что и библиотеки, веб-перехватчики и зависимости инфраструктуры. Рекомендуемые элементы управления включают:

<ул>

Поддерживать белый список утвержденных серверов MCP и источников инструментов.

Закрепите версии, где это возможно, и запишите хэши схемы.

Требовать владельца для каждого сервера и инструмента высокого риска.

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

Отключить новые добавленные инструменты до проверки.

Проверьте необходимые области для каждого маршрута или возможности.

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

Запускайте ненадежные инструменты или инструменты с высоким уровнем риска в изолированных программных средах с ограничениями сети и файловой системы.

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

Контрольный список реализации

Разработка политики

<ул>

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

Создайте отдельные области для вызовов моделей и инструментов.

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

Настройте поведение запрета по умолчанию для неизвестных инструментов и отсутствующих областей.

Определяйте правила одобрения только для действий с высоким риском.

Применение шлюза

<ул>

Требовать от каждого агента вызывать инструменты через шлюз или подписанную оболочку политики.

Перед выполнением проверьте арендатора, пользователя, ключ, агент, модель, инструмент, объем, бюджет и статус утверждения.

Обеспечить максимальную глубину вызова инструментов и совокупную стоимость выполнения.

Записывать версию реестра инструмента и хэш схемы для каждого вызова.

Закрытие при сбое, когда механизм политики не может принять решение.

Аудит и операции

<ул>

Объединяйте вызовы моделей и инструментов под одним идентификатором трассировки или запуска агента.

По умолчанию редактируйте или хешируйте конфиденциальные данные инструмента.

Сохраняйте доказательства утверждения вместе с протоколом окончательного исполнения.

Предоставлять администраторам аналитику стоимости каждого инструмента и ограничений скорости.

Документируйте владельцев отката для инструментов, изменяющих состояние.

Ожидаемые компромиссы

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

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

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

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

Жесткие ограничения по сравнению с выполнением задач. Ограничения стоимости каждого инструмента предотвращают неконтролируемость агентов. Они также могут прерывать законную длительную работу. Укажите пути продолжения, такие как разрешение на продолжение, фоновые очереди или обобщенные частичные результаты.

Прогнозы: куда движется эта закономерность

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

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

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

Практическое заключение

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

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

Связанное чтение

• практика изоляции и ротации ключей командного API
• объединенные трассировки, реестры токенов и безопасное ведение журнала запросов
• структурированные выходные данные и шаблоны проверки вызовов инструментов