Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Один и тот же доступ агента через графический интерфейс, командную строку или API можно проверять как единое действие, не позволяя переносить выданное разрешение между маршрутами. Genliang Zhu и Chu Wang проверили схему на профиле из 60 маршрутов через пять интерфейсов; поскольку препринт не рецензирован, все числа получили сами авторы. Для продуктовой команды это переносит авторизацию с отдельных кнопок и инструментов на весь путь до записи результата.
Почему проверки у одного интерфейса недостаточно
Агент может начать задачу в графическом интерфейсе, продолжить через командную строку, вызвать API, запустить скрипт и обратиться к серверу MCP. Эти пути способны менять один ресурс, но по-разному разбирают параметры, подставляют значения по умолчанию и доходят до хранилища.
Если политика защищает только диалог в интерфейсе, эквивалентная команда может пройти через незарегистрированный обработчик. Даже когда оба маршрута вызывают одну систему авторизации, разрешение для графического интерфейса нельзя безопасно использовать в API: другой маршрут может изменить получателя, целевое хранилище или неявные параметры.
Есть и временная проблема. Между выдачей разрешения и фактической записью ресурс могут переназначить, его версия может измениться, а срок действия права — закончиться. Решение, принятое по старому состоянию, уже не гарантирует допустимый результат.
Отдельные разрешённые действия также могут образовать запрещённую последовательность. Например, агент читает конфиденциальные данные одним способом, а затем отправляет их внешнему получателю через другой интерфейс. Локальная проверка каждого вызова пропустит оба шага, если не учитывает предыдущие действия.
Как разрешение доходит до точки записи
Схема начинается с версионированного профиля развёртывания. В нём команда перечисляет входы, которые создают эффект, маршруты до постоянных хранилищ, обязательные точки контроля и адаптеры записи. Проверка покрытия должна показать, что каждый зарегистрированный путь к хранилищу проходит через контрольную точку.
Конкретный запрос приводят к общей форме эффекта. Она фиксирует исполнителя, операцию, ресурс, получателя, назначение, класс данных, ключ состояния и конечное хранилище. Политика работает с этой формой, поэтому одинаковые эффекты получают одинаковое решение независимо от интерфейса.
После предварительной проверки система выдаёт одноразовый билет. Он связан не только с эффектом и правом, но и с точным маршрутом, хранилищем, версией профиля, снимком состояния и уже выполненной последовательностью действий. Билет из графического интерфейса нельзя предъявить в командной строке: старый билет блокируется, а действие готовится заново.
Перед записью адаптер снова разбирает запрос и сверяет маршрут, эффект, право и текущее состояние. Успех признаётся только после квитанции от хранилища, которая подтверждает ожидаемый результат. Потерянная квитанция означает неопределённый исход: его нужно сверять с авторитетным состоянием, а не считать автоматическим отказом и повторять операцию.
Проверка охватила две различающиеся реализации и 3464 трассы выполнения. Набор тестов отклонил все 720 намеренно внесённых ошибок нормализации, а 168 проверок момента записи совпали с ожидаемым исходом. Независимый проверяющий модуль также отверг все 26 смысловых регрессий.
Гарантии относятся только к зарегистрированному профилю и описанным эффектам. Схема не обнаруживает неизвестные маршруты, скрытые побочные действия и произвольный смысл свободно составленных программ. Она также полагается на достоверное состояние и на хранилище, которое не выполняет скрытую запись без квитанции.
Когда работа меняет архитектурный план
Для гибридного агента одного шлюза перед API или списка разрешённых инструментов недостаточно. Инвентаризацию стоит начинать с постоянных хранилищ и идти назад до всех способов вызвать изменение: обработчиков интерфейса, команд, программных методов, скриптов и инструментов MCP. Для каждого пути нужен собственный преобразователь запроса и проверяемая точка контроля.
Версия профиля становится частью модели безопасности. Изменение маршрута, обработчика или схемы параметров должно создавать новую версию и отменять ранее выданные билеты. Иначе старое разрешение продолжит действовать после изменения смысла операции.
Протокол не заменяет Cedar или другой механизм политик: он связывает его решение с реальным исполнением. Он также не доказывает, что человек понял запрос или выбрал правильное правило. Его задача уже — не дать агенту расширить полученное право сменой интерфейса, состояния или точки записи.
В пакет препринта входят исходники рукописи, но не реализация, трассы и отчёты экспериментов. Поэтому работу пока разумно использовать как архитектурную спецификацию и перечень проверок, а не как готовую библиотеку. Наиболее практичные части для переноса — реестр маршрутов, одноразовый билет, повторная проверка состояния и обязательная квитанция от хранилища.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
