Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Полученный ИИ-агентом ресурс предложили считать не новым полномочием, а объектом, который ещё должен пройти отдельную проверку. Архитектуру AcquireBound описал Genliang Zhu из Accentrust и Georgia Institute of Technology; хотя препринт не рецензирован и все числа получили сами авторы, в испытаниях опасные сценарии блокировались, а разрешённые завершались. Для команд это добавляет отдельную границу безопасности между созданием облачного ресурса, учётной записи или ключа и их первым использованием.
Успешная операция ещё не даёт права на результат
Платёжная система подтверждает заказ и перевод денег. Бюджетный контроль проверяет сумму, OAuth разрешает обратиться к API поставщика, а журнал исполнения фиксирует доставку. Ни одна из этих проверок сама по себе не определяет, какие действия позволяет доставленный ресурс.
Один и тот же разрешённый запрос на создание вычислительной среды может вернуть изолированный экземпляр с доступом только на чтение или среду с административной учётной записью и выходом во внешнюю сеть. Запрос, цена и квитанция при этом совпадут. Решение зависит от фактической конфигурации результата, а не только от параметров операции.
Скалярный лимит тоже не закрывает этот разрыв. Бесплатные регистрации позволяют распределить ресурсы между псевдонимами, а возврат денег может восстановить бюджет, не уничтожив уже выданный ключ. Политика должна учитывать общую цепочку происхождения, каноническую личность получателя и сочетание полномочий во всём графе приобретений.
AcquireBound рассматривает оплату, разрешение API и подтверждение поставщика как входные свидетельства. Новое полномочие появляется только после отдельной активации доставленного объекта.
Как карантин превращается в действующее полномочие
Процесс разделён на заявку, резервирование исходных прав, отправку запроса поставщику, карантин результата, разбор его возможностей и активацию. Разделение сохраняется в состоянии системы: успешная доставка не может незаметно перевести ресурс в рабочий режим.
Сначала брокер помещает результат в хранилище, которое не раскрывает агенту исходный ключ или иной носитель полномочий. Версионированный преобразователь читает заверенные сведения поставщика и строит нормализованный профиль: кто контролирует ресурс, какие данные он видит, какие эффекты создаёт, кому может делегировать доступ и как долго действует.
Затем монитор добавляет будущий ресурс в типизированный граф и проверяет его вместе со всеми уже активными связями. Политика может разрешить чтение или публикацию по отдельности, но запретить их сочетание у одного получателя. Она также может ограничить глубину делегирования, число активных потомков и область данных.
Такая политика замкнута в сторону сужения: если набор полномочий допустим, удаление ресурса или сокращение его возможностей не делает набор опаснее. Псевдонимы сводятся к канонической личности, поэтому новый идентификатор разрешения не сбрасывает общий лимит.
После активации агент получает непрозрачный дескриптор вместо исходного секрета. Перед защищённым действием брокер заново проверяет происхождение ресурса, текущие версии политик и запрошенный эффект, а затем выдаёт одноразовое разрешение. Оно погашается атомарно в момент фиксации действия, чтобы сбой или повтор запроса не создали второй эффект.
Проверка охватила пять классов ресурсов. Эталонная модель приняла 20 безопасных трасс и отвергла 40 зарегистрированных опасных трасс на 810 событиях. Независимый проверяющий модуль согласился с решениями и обнаружил все внесённые подмены; в отдельной связке MCP с Docker ни один из 16 опасных путей не отправил неразрешённый запрос на запуск контейнера.
Граница этих результатов проходит по зарегистрированным профилям с полностью наблюдаемыми выходами и посредником перед каждым защищённым эффектом. Испытания использовали детерминированные локальные вызовы, инертные учётные данные и локальные контейнеры без сети, поэтому они проверяют семантику и точки отказа, но не промышленную облачную эксплуатацию.
Когда AcquireBound меняет архитектурный план
Работа касается систем, где агент может не только вызвать готовый инструмент, но и создать средство для последующих действий: вычислительную среду, учётную запись, ключ, сервис или другого агента. Обычный вызов инструмента не входит в этот контур, если он не создаёт новый внешний ресурс или нового субъекта.
В такой системе контроль бюджета и разрешение API нельзя считать последней проверкой. В план управляющего контура придётся добавить карантинное хранилище, адаптеры к заверенным сведениям поставщиков, нормализованное описание возможностей, реестр канонических личностей и брокер всех последующих эффектов.
Самое жёсткое требование относится к посредничеству. Если поставщик возвращает исходный ключ прямо агенту, псевдонимы нельзя связать или действие способно обойти брокер, заявленные гарантии не действуют. Такой профиль должен оставлять ресурс в неопределённом состоянии и не активировать его либо использовать внешний шлюз, который удерживает полномочие у себя.
AcquireBound не заменяет OAuth, облачные роли, платёжные протоколы и проверку параметров инструмента. Он связывает их свидетельства с отдельным решением после доставки. Практический вывод для проектирования прост: состояние заказа, состояние поставки и состояние полномочий должны храниться и изменяться раздельно.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
