Суть
Частая последовательность: команда сначала делает умного агента, потом задумывается, кто он с точки зрения управления доступом. К этому моменту все вызовы уже идут от одного технического пользователя, и после инцидента расследование упирается в пустоту — каждое действие выглядит так, будто его совершил один и тот же всемогущий субъект.
Правильный вопрос ставится раньше и звучит иначе: от чьего имени идёт это конкретное действие.
Четыре субъекта
| Субъект | Что представляет | Какие права |
|---|---|---|
user_principal |
Конкретный пользователь | Права текущего пользователя, не шире |
agent_runtime_principal |
Сам рантайм | Оркестрация и чтение метаданных |
tool_principal |
Конкретный инструмент или коннектор | Учётные данные с ограниченной областью |
approval_actor |
Человек или группа, подтверждающие операции | Право одобрять, но не исполнять |
Разделение последних двух особенно существенно: тот, кто подтверждает, и то, что исполняет, — разные субъекты, иначе запись подтверждения ничего не доказывает.
Почему пользовательский контекст не должен растекаться
Соблазн простой: передать права пользователя вниз по всей цепочке — тогда «агент делает ровно то, что мог бы сделать человек». Проблема в том, что агент делает это в объёме и со скоростью, недоступными человеку, и с контекстом, часть которого пришла из недоверенного источника.
Практическое требование: у рантайма своя машинная идентичность, у агента — своя операционная, у каждого коннектора могут быть свои учётные данные с ограниченной областью. Пользовательский контекст сужает права, но не расширяет их.
Creator, owner и authority — разные поля
Для совместных артефактов полезно разделять три факта: creator неизменно хранит происхождение, owner обозначает текущую ответственность, participants — историю участия. Ни одно из них само по себе не даёт права читать, делиться или изменять артефакт: authority проверяется отдельной политикой на каждом действии.
Это особенно важно для skills и памяти. Переназначить ответственного — не значит передать доступ; неизвестное происхождение не означает machine-owned; запись автора в Git помогает расследованию, но не заменяет ACL (Skill Change Control).
Идентичность как исполняемая граница
Идентичность становится реальной защитой только тогда, когда шлюз принимает решения не по правилу «этот инструмент разрешён», а по правилу «этот инструмент разрешён именно этому субъекту именно в этом контексте» (Tool Gateway).
Отсюда минимальный состав запроса к шлюзу: actor_id, actor_type, tenant_id, requested_capability, risk_class, approval_state. Пока в запросе нет субъекта и арендатора, управление доступом остаётся записью в таблице, а не границей.
Класс атаки, который это закрывает
Подставленный посредник: агент с широкими правами выполняет действие по указанию того, у кого этих прав нет. Защита — ограниченные по области токены, привязка субъекта к запуску, явная запись факта делегирования и проверка идентичности обеих сторон при передаче полномочий между агентами (Agent2Agent Protocol, A2A Task Lifecycle).
Без записи делегирования цепочка «кто на самом деле инициировал это действие» обрывается на первом переходе.
Два места, где идентичность перестаёт работать со временем
Всё выше описывает выдачу и проверку прав в момент действия. Два разрыва открываются позже.
Долгая сессия переживает изменение прав. Агент, работающий часами или днями, получил свои полномочия на старте. Пользователя за это время могли уволить, роль отозвать, политику ужесточить — а сессия продолжается со старой авторизацией, потому что перепроверять её никто не просил. Требование формулируется по действиям, а не по времени: на каждом привилегированном действии права запрашиваются у источника заново, а не берутся из того, что решили при запуске. Кэш прав в долгой сессии — это молчаливое расширение окна, в котором отозванный доступ ещё работает.
Цепочка передач теряет инициатора. Запись факта делегирования отвечает на вопрос «кто передал», но не удерживает связь на всём пути: агент A поручил B, B поручил C, действие выполнил C. Если каждый шаг не привязан криптографически к предыдущему, разбор инцидента упрётся в C и остановится — восстановить, по чьей воле всё началось, будет нечем, и отказаться от авторства сможет любой участник. Привязка шагов к цепочке исполнения нужна именно для неотказуемости: не чтобы обнаружить нарушение, а чтобы после обнаружения было чем доказать, кто его инициировал (Agent Audit Log).
Оба требования дорогие и оба уровня 2–3 в стандарте: их вводят, когда агент действует от имени пользователя в системе, где отзыв прав что-то значит.
Связано с
Agent Audit Log — где живёт запись цепочки передач и почему её нельзя переписать
Trust Boundary Agent — где проходят границы, которые эта модель делает исполнимыми
Tool Gateway — где идентичность превращается в решение
Agent Sandboxing — ограничение того, что доступно субъекту физически
Agent2Agent Protocol — делегирование полномочий между агентами
Multi Tenancy AI — арендатор как измерение идентичности
JIT Secret Inversion — почему учётные данные инструмента не видит модель
Agent Audit Log — что связывает субъекта с последствиями