Проблема с разрешениями, которые живут в коде
Фреймворки агентов хороши в оркестрации. Они не являются системами идентификации, и модели разрешений, которые они предоставляют, не являются средствами управления. Список разрешённых инструментов в фреймворке — это список в коде приложения. Он версионируется вместе с агентом, развёртывается вместе с агентом и читается средой выполнения, которая выполняет агента. Он не виден команде идентификации, не появляется в проверке доступа и не может быть сверен с процессом приёма-перемещения-увольнения, который работает с объектами каталога.
Этот разрыв сейчас проверяется в масштабе. Расширение управления идентификацией на ИИ-агентов в Университете Вандербильта — полезный ориентир, потому что там агенты рассматриваются как субъекты той же системы управления, что и люди, а не как программные артефакты с конфигурационными файлами (SiliconAngle). Урок структурный, а не институциональный: если субъект может читать данные, вызывать API или действовать от чьего-то имени, ему нужна идентификация, которую каталог может выдать, ограничить, проверить и отозвать.
Почему разрешения фреймворка не проходят аудит
Три режима отказа повторяются.
Во-первых, невидимость. Списки разрешённых инструментов и строки областей действия живут внутри конфигурации самого агента. Проверяющий доступ, глядя на поставщика идентификации, видит сервисную учётную запись с широкими правами или вообще ничего, если агент аутентифицируется через общие учётные данные. Проверяющий не может увидеть, что агент может вызывать платёжный API, систему тикетов и хранилище документов, потому что эта деталь находится в репозитории, который проверяющий не читает.
Во-вторых, сохранение после вывода из эксплуатации. Когда агент выводится из эксплуатации, его учётные данные часто остаются в переменных окружения, хранилищах секретов или конфигурационном файле, который всё ещё загружается другой системой. Ничто в жизненном цикле фреймворка не заставляет их удалить, потому что фреймворк не знает, что у агента был владелец, который ушёл, или что функция, которую он поддерживал, была выведена из эксплуатации. Учётные данные переживают цель.
В-третьих, разрастание прав. Агенты накапливают области действия по мере выпуска функций. Новая интеграция добавляет область; рефакторинг добавляет ещё одну. Области действия редко удаляются, потому что удаление требует знания, какая область соответствует какой функции, а это соответствие не поддерживается. Результат — агент с большим доступом, чем требуется для любой отдельной задачи, удерживаемый бессрочно.
Как выглядит идентификация агента, встроенная в каталог
Идентификация агента, встроенная в каталог, — это полноценный объект в том же каталоге, который содержит учётные записи людей. У него есть атрибуты, делающие управление возможным:
- Владелец и спонсор. Владелец — это команда, ответственная за поведение агента. Спонсор — это человек, который санкционировал его существование. Оба являются ссылками на каталог, а не полями свободного текста.
- Срок действия. У идентификации есть период действия. По умолчанию она не существует вечно.
- Права. Области действия предоставляются как права каталога, прикрепляются к объекту агента и отображаются в том же цикле проверки, что и доступ людей.
- Ссылка делегирования. Агент действует от имени указанного субъекта. Эта ссылка хранится и доступна для запросов, поэтому аудитор может спросить, какая человеческая инстанция стоит за данным действием.
Это не косметическое изменение. Оно переносит вопрос с «что может делать этот код?» на «на что этот субъект имеет право, кто это санкционировал и когда это санкционирование заканчивается?»
Операции жизненного цикла, которые фреймворки не могут выразить
Как только агент становится объектом каталога, операции жизненного цикла становятся возможными так, как они невозможны внутри фреймворка.
Ротация и отзыв по расписанию. Учётные данные ротируются по календарю, а не по развёртыванию. Отзыв — это операция каталога, которая вступает в силу во всех системах, доверяющих каталогу, а не изменение кода, которое нужно доставить в каждую интеграцию.
Автоматическая приостановка. Если команда-владелец распущена или спонсор покидает каталог, идентификация агента может быть приостановлена автоматически. У фреймворка нет понятия ухода спонсора, потому что фреймворк не моделирует трудоустройство или членство в команде.
Аттестация. Периодическое подтверждение человеком подтверждает, что агенту всё ещё нужна каждая область действия, которой он обладает. Аттестация — это примитив управления: она заставляет принять решение по каждому праву и создаёт запись о том, кто принял это решение.
Ничто из этого не выражается как разрешения фреймворка, потому что они зависят от состояния каталога, которым фреймворк не владеет.
Конкретный механизм: сопоставление прав с телеметрией используемых областей действия
Практический способ реализовать это — рассматривать каталог как источник истины для прав, в то время как фреймворк остаётся точкой принуждения, по крайней мере изначально.
При выдаче каталог создаёт идентификацию агента и предоставляет набор прав. Фреймворк получает токен или учётные данные, которые кодируют эти права. Во время выполнения фреймворк записывает, какие права фактически используются. Эта телеметрия записывается обратно в каталог как атрибут объекта агента.
Затем каталог предоставляет два представления: предоставленные области действия и используемые области действия. Соотношение между ними — основной показатель гигиены. Агент, который имеет двенадцать областей действия и использует три, является кандидатом на сокращение. Механизм не требует, чтобы фреймворк понимал управление; он требует, чтобы фреймв
Это намеренно скучный дизайн. Он использует каталог для того, в чём каталоги хороши, а фреймворк — для того, в чём фреймворки хороши. Сложная часть — не сантехника; это дисциплина проверки соотношения и действий по нему.
Миграция без дня флага
Распространённая ошибка — попытка чистого перехода: переместить выдачу и принуждение в каталог одновременно. Это ломает работающие системы, потому что точки принуждения, которые не были обновлены, отклонят новый формат учётных данных, а выдача, которая переместилась, не будет создавать старый формат.
Более безопасная последовательность имеет три фазы.
- Зеркалирование. Прочитайте области действия на уровне фреймворка и создайте соответствующие права каталога. Пока ничего не принуждается. Цель — дать проверкам доступа что-то для изучения.
- Выдача из каталога. Переместите выдачу учётных данных в каталог, пока фреймворк всё ещё принуждает свой собственный список разрешённых инструментов. Оба должны согласовываться; несоответствия регистрируются и сверяются.
- Принуждение из каталога. Как только выдача стабильна, а зеркало точно, переключите принуждение на права, выданные каталогом. Список разрешённых инструментов фреймворка становится избыточной проверкой, которую можно удалить.
Этот порядок важен. Сначала выдача, потом принуждение. Обратный порядок означает, что каталог принуждает права, которые не были выданы ни одной системе, что приводит к сбоям, которые выглядят как отказы идентификации, но на самом деле являются ошибками последовательности.
Честный компромисс
Идентификация агента, встроенная в каталог, добавляет задержку и связанность. Каждое действие агента, зависящее от права, выданного каталогом, наследует доступность каталога. Локальный список разрешённых инструментов фреймворка не имеет такой зависимости; это список в памяти. Перенос управления в каталог означает принятие того, что каталог находится на критическом пути для операций агента, и что отказ каталога — это отказ агента.
Этот компромисс обычно оправдан, потому что альтернатива — поверхность доступа, которую никто не может проверить. Но его следует делать явным, а не обнаруживать во время инцидента. Смягчение — это кэширование и краткосрочные токены с чёткими семантиками отзыва, а не отказ от каталога как источника истины.
Что измерять
Основной показатель — соотношение предоставленных и используемых прав на агента, проверяемое по расписанию. Вторичные показатели включают время от ухода спонсора до приостановки агента и долю агентов с установленной датой истечения срока действия. Это запросы к каталогу, а не журналы фреймворка, и в этом суть: на вопросы управления должны быть ответы из системы учёта, а не реконструироваться из телеметрии приложения.
Управление идентификацией агентов — это не функция фреймворка агента. Это свойство каталога, и оно работает только тогда, когда каталог выдаёт, ограничивает, проверяет и отзывает идентификации, которые используют агенты.