Что означает делегированная полномочность
Делегированная полномочность - это разрешение, которое человек (или организация) дает агенту ИИ действовать от его имени. Когда ассистент бронирует встречу в вашем календаре, создает тикет в поддержку от вашего имени или получает счет из портала поставщика, он использует полномочия, исходящие от вас.
Хорошая делегация обладает тремя свойствами: она ограничена по области (агент может делать некоторые вещи, но не все), ограничена по времени (она истекает или может быть отозвана) и атрибутируема (принимающее приложение может понять, чьи именно полномочия используются).
Почему это важно для приложений
С точки зрения приложения запрос от агента поднимает до трех отдельных вопросов:
- Какой клиент это отправил? Это идентичность агента, которую могут установить подписанные запросы (см. HTTP Message Signatures).
- Чьими полномочиями он действует? Это делегирование.
- Достаточно ли этих полномочий для этого действия? Это авторизация, которую определяет собственная политика приложения.
Подписанный запрос от известного оператора ассистента хорошо отвечает на первый вопрос. Сам по себе он ничего не говорит о втором. Ассистент может действовать от имени одного из ваших пользователей, от имени человека, который не является вашим пользователем, или полностью по собственной инициативе. Считать идентичность клиента доказательством согласия человека - одна из самых частых ошибок в проектировании систем, ориентированных на агентов. См. что доказывают и чего не доказывают подписанные запросы AI-агентов.
Как обычно выражают делегирование
- Гранты в стиле OAuth. Человек входит в ваше приложение и выдает агенту токен с ограниченными scope, как определено в OAuth 2.0 (RFC 6749). Затем ваше приложение точно знает, чьими полномочиями обладает токен, и грант можно отозвать (RFC 7009).
- API keys, привязанные к аккаунту, которые пользователь создает для конкретной интеграции, желательно с узкими разрешениями.
- Подтверждения внутри приложения для действий с высоким влиянием, когда человек подтверждает конкретное действие, подготовленное агентом.
- Заявления о делегировании на уровне токена. OAuth 2.0 Token Exchange (RFC 8693) определяет claim
act(actor), который фиксирует, что одна сторона действует от имени другой. Более новые работы по выражению делегирования агента в запросах все еще развиваются, и приложениям следует проверять любой claim о делегировании по своим собственным записям, а не принимать его на веру.
Распространенные заблуждения
- "Если агент верифицирован, значит пользователь его одобрил." Верификация определяет клиента. Одобрение должно исходить от человека через канал, которому доверяет ваше приложение.
- "Агент, использующий сессию моего пользователя, - это нормально." Возможно, но сессия была выдана для интерактивного использования человеком. Многие приложения предпочитают отдельный, ограниченный грант для автоматизации, чтобы действия можно было атрибутировать и отзывать.
- "Делегирование - это либо все, либо ничего." Самые безопасные делегации - узкие: широкое чтение, запись только для конкретных действий и подтверждение для всего необратимого.
Как это связано с Proof of Actor
Proof of Actor помогает увидеть, когда взаимодействие инициировано агентом или поддерживается AI, и на каком основании: Verified, Declared, Inferred или Unknown. Этот контекст подсказывает, где возникают вопросы делегирования, например при autonomous agent, действующем внутри сессии человеческого аккаунта. Proof of Actor не выдает и не валидирует учетные данные делегирования, и результат Agent никогда не означает, что человек разрешил действие. Это определяют собственные гранты, scope и подтверждения вашего приложения, а Route позволяет применить нужную политику для каждого route после того, как вы наблюдали реальный трафик. О шаблонах политик см. как проектировать политики уровня приложения для людей и AI-агентов.
Читайте что доказательства могут и не могут установить, или подайте заявку на ранний доступ.
Источники
- RFC 6749: The OAuth 2.0 Authorization Framework: ограниченные гранты от владельца ресурса клиенту
- RFC 7009: OAuth 2.0 Token Revocation: отзыв делегированного токена
- RFC 8693: OAuth 2.0 Token Exchange: claim
act(actor) для делегирования