Проблема фразы «это сделал агент»
Агент не является единым субъектом. Запрос инициирует человек или система, решение планирует модель, код выполняет worker, а внешний API видит credential. Если все используют один service account, невозможно доказать, кто разрешил действие и для какого tenant.
Надёжная модель отвечает на четыре вопроса: кто поручил, кто действует, какой workload исполняет и почему конкретный ресурс разрешён сейчас.
Subject, actor и workload
Subject — сторона, от имени которой совершается действие: обычно пользователь или организация. Actor — агент или сервис, которому делегировано выполнение. Workload identity — криптографически подтверждённый экземпляр приложения.
RFC 8693 описывает token exchange с обязательным subject_token и необязательным actor_token. Такое разделение позволяет downstream увидеть не только пользователя, но и действующую сторону.
Три режима авторизации
| Режим | Когда | Главный риск |
|---|---|---|
| Machine | Плановый индексатор, системная синхронизация | Слишком широкая общая роль |
| Delegated | Агент работает в пределах прав пользователя | Потеря actor и consent |
| Impersonation | Редкая административная операция | Неразличимость пользователя и посредника |
Не маскируйте machine job под пользователя ради удобства. И не используйте пользовательский token для фоновой задачи после окончания его сессии без явного долгоживущего grant.
Workload identity вместо ключа в environment
Worker должен доказывать платформе, кем он является, без общего статического API key. SPIFFE задаёт SPIFFE ID и SVID — короткоживущий X.509 или JWT-документ, подписанный trust domain. Workload API выдаёт и регулярно обновляет identity без предварительно встроенного секрета.
Среды с разными правилами безопасности полезно помещать в разные trust domains. Компрометация staging не должна автоматически давать доверие production.
Делегирование через token exchange
Agent runtime предъявляет authorization server пользовательский subject token и собственный actor token, запрашивая новый ограниченный token для target resource. Exchange не означает, что исходные tokens автоматически отзываются или продлеваются вместе с новым — lifecycle проектируется отдельно.
Выпущенный token должен отражать разрешённую цепочку делегирования, а не превращать агента в неограниченного двойника пользователя.
Audience ограничивает перенос украденного token
Token для CRM не должен приниматься платёжным API. RFC 8707 вводит resource indicator; audience-restricted token нельзя легитимно переиспользовать на другом resource.
Проверяйте iss, aud, срок, signature, scopes и tenant на каждой границе. Простое наличие валидного JWT ещё не даёт доступ текущему API.
Scopes описывают возможности, но не объекты
Scope invoice:write не отвечает, какую именно invoice можно менять. Tool server после аутентификации выполняет object-level authorization: принадлежность tenant, ownership, состояние объекта и business policy.
Идентификаторы tenant, role и owner берутся из проверенного контекста, а не из свободного текста или аргумента, предложенного моделью.
Least privilege для tool, а не для всего агента
Не выдавайте worker суммарную роль всех возможных tools. Credential broker получает конкретное намерение, проверяет policy и выдаёт capability только для одной операции, ресурса и короткого TTL — либо сам выполняет вызов.
Read и write разделяйте; массовая операция не должна следовать из права изменить один объект. Amount, recipients и allowed fields могут входить в constraint grant.
Consent и approval — разные вещи
OAuth consent разрешает приложению класс доступа. Approval подтверждает конкретное рискованное действие: объект, сумму, адресата и версию предложения. Старый consent не означает согласие на каждую будущую операцию агента.
Перед side effect повторно проверьте, что approval не истёк, proposal hash совпадает, а объект не изменился.
Zero trust: решение для каждого tool call
NIST Zero Trust Architecture не предполагает доверие только из-за сетевого расположения. Policy decision учитывает субъект, ресурс, запрашиваемое действие и контекст конкретного запроса; enforcement point применяет результат.
Модель может предложить действие, но не является policy engine. Prompt instruction «не трогай чужие данные» не заменяет серверную авторизацию.
Confused deputy и token passthrough
Привилегированный агент становится confused deputy, если пользователь заставляет его применить собственные права к чужому ресурсу. Защита — явный subject, проверка tenant и resource-bound credential.
Не пересылайте входной bearer token произвольному downstream. Обменивайте его на token нужного audience либо используйте собственную workload identity для системного вызова.
Фоновые задачи и истечение пользовательской сессии
Workflow может продолжаться дольше access token. Не сохраняйте исходный bearer в checkpoint. Храните ссылку на grant и при каждом возобновлении получайте новый короткоживущий token, повторно применяя актуальную policy.
Отзыв пользователя или роли должен остановить новые effects. Уже начатую операцию переводят в явное состояние и сверяют, а не продолжают по старым правам.
Аудит цепочки действий
Audit event содержит subject ID, actor/agent ID, workload ID, tenant, tool, resource, scope, token issuer и audience, policy decision ID, approval ID, effect ID и outcome. Секрет или полный bearer не записывается.
Для расследования должна восстанавливаться цепочка: пользовательское намерение → предложение агента → решение policy → credential issuance → tool effect.
Тесты модели идентичности
Проверьте чужой tenant, подменённый object ID, неверный audience, истёкший token, отозванную роль, повтор approval, потерянный actor claim и restart workflow после отзыва grant. Downstream должен fail closed.
Отдельный тест доказывает, что модель никогда не получает credential через prompt, tool result, trace или текст ошибки.
Чек-лист IAM для ИИ-агента
- Subject, actor и workload представлены раздельно.
- Machine и delegated flows не смешиваются.
- Workload получает короткоживущую удостоверяемую identity.
- Token ограничен audience, scope, tenant и TTL.
- Исходный bearer не передаётся downstream.
- Каждый tool проверяет object-level authorization.
- Approval связан с точным proposal.
- Отзыв применяется к новым effects.
- Audit сохраняет decision и effect IDs.
- Cross-tenant и confused-deputy тесты входят в CI.