Суть
Частая последовательность: команда сначала делает умного агента, потом задумывается, кто он с точки зрения управления доступом. К этому моменту все вызовы уже идут от одного технического пользователя, и после инцидента расследование упирается в пустоту — каждое действие выглядит так, будто его совершил один и тот же всемогущий субъект.
Правильный вопрос ставится раньше и звучит иначе: от чьего имени идёт это конкретное действие.
Четыре субъекта
| Субъект | Что представляет | Какие права |
|---|---|---|
user_principal |
Конкретный пользователь | Права текущего пользователя, не шире |
agent_runtime_principal |
Сам рантайм | Оркестрация и чтение метаданных |
tool_principal |
Конкретный инструмент или коннектор | Учётные данные с ограниченной областью |
approval_actor |
Человек или группа, подтверждающие операции | Право одобрять, но не исполнять |
Разделение последних двух особенно существенно: тот, кто подтверждает, и то, что исполняет, — разные субъекты, иначе запись подтверждения ничего не доказывает.
Почему пользовательский контекст не должен растекаться
Соблазн простой: передать права пользователя вниз по всей цепочке — тогда «агент делает ровно то, что мог бы сделать человек». Проблема в том, что агент делает это в объёме и со скоростью, недоступными человеку, и с контекстом, часть которого пришла из недоверенного источника.
Практическое требование: у рантайма своя машинная идентичность, у агента — своя операционная, у каждого коннектора могут быть свои учётные данные с ограниченной областью. Пользовательский контекст сужает права, но не расширяет их.
Канал как субъект: полезная модель с опасной развилкой
В многопользовательском интерфейсе агент может действовать не от имени одного человека, а от имени компартмента — workspace или приватного канала. У него собственные service accounts, журнал и набор коннекторов, а профиль канала определяет доступную область. Это снимает неразрешимый вопрос «чьи права наследовать, если агента одновременно направляют несколько участников?» и упрощает отзыв доступа одной машинной идентичности.
Но модель допускает два разных правила, и смешивать их нельзя:
- безопасный default: эффективные права = пересечение профиля агента, области канала и прав инициатора;
- workspace-delegation: участник может попросить агента прочитать то, к чему сам не имеет доступа, если это разрешено профилю канала.
Anthropic использует вторую возможность в Claude Tag и предлагает ограничивать профиль правами наименее привилегированного участника. Для чувствительных данных этого недостаточно как универсальной гарантии: новый участник или ошибочно широкий канал превращает агента в confused deputy. Поэтому наша базовая формула «пользовательский контекст только сужает» сохраняется; исключение требует отдельного решения владельца данных, аудита состава канала и запрета выноса результата за границу компартмента.
Авторизация до контекста, а не только до действия
Инструментальный gateway защищает побочный эффект, но не закрывает чтение данных, уже попавших в prompt или общую память. Для многопользовательского агента permission check должен стоять раньше: при выборе conversation history, memory entries, файлов, keychain view и результатов поиска.
QM разделяет эти поверхности по человеку и комнате. Переносимый вывод: безопасный объём контекста ограничен качеством permission system. Если модель уже увидела привилегированную запись, поздний запрет send не возвращает конфиденциальность — остаются ответы, tool arguments, subagent handoff и долговечные сводки (Memory Boundaries, Prompt Injection).
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 — что связывает субъекта с последствиями