Должен ли агент когда-либо видеть секрет?

Обычно ответ должен быть отрицательным. Агент может быть уполномочен вызвать эффект, но ему не следует доверять переносимый секрет, способный вызвать множество эффектов за пределами управляемого контура.

Это не означает, что системы могут обходиться без учётных данных. Базе данных, SaaS API или облачному сервису всё равно нужен аутентифицированный вызывающий субъект. Архитектурный вопрос в другом: где находится это полномочие, когда оно выдаётся и может ли оно попасть в промпты, описания инструментов, конфигурацию, память или общие трассировки. Для автономной организации это не защищённые границы, а рабочие поверхности: их копируют между процессами, суммируют, журналируют, проверяют и иногда смешивают с недоверенным вводом.

Более сильная схема рассматривает учётные данные как артефакты исполнения. Модель запрашивает организационный эффект. Управляемая среда решает, допустим ли он. И только затем изолированный исполнитель получает узко ограниченное полномочие, необходимое для выполнения действия.

Право действовать — не владение секретом

Агент может сформулировать намерение: обновить карточку клиента в соответствии с одобренным изменением адреса. Это не то же самое, что иметь пароль к базе, долгоживущий ключ доступа к облаку или API-токен с широкими правами. Первое — запрос, который можно оценить в контексте. Второе — переносимое полномочие: после копирования оно может работать вне среды агента, после завершения задачи и для операций, которые исходное решение никогда не рассматривало.

Различие важно именно потому, что рассуждение агента намеренно гибко. Он выбирает инструменты, комбинирует сведения и меняет план. Но он не должен становиться контейнером секретов. Prompt injection, меняющая план, уже является проблемой управления. Prompt injection, извлекающая многоразовые учётные данные, превращает её в проблему доступа с потенциально гораздо более долгим сроком действия.

“Модель должна выражать нужный ей эффект. Среда исполнения должна хранить и ограничивать полномочие, способное этот эффект произвести.

Архитектура нулевого доверия поддерживает это разделение. NIST SP 800-207 отвергает неявное доверие, основанное только на сетевом расположении или владении активом. Исполнитель во внутренней подсети не должен наследовать разрешение лишь потому, что находится рядом с защищённой системой. Каждое защищённое взаимодействие требует аутентификации и авторизации, соответствующих самому взаимодействию.

Практическая граница для учётных данных

Управляемая среда может закрепить эту границу последовательностью, которая намеренно устроена строже, чем обычный вызов инструмента:

1. Агент → управляемый запрос эффекта. Агент запрашивает определённый бизнес-эффект, указывая субъект или контекст делегирования, цель, объект и предполагаемую операцию.
2. Политическое решение. Плоскость управления проверяет, разрешён ли эффект действующей организационной политикой, и фиксирует решение.
3. Аттестация рабочей нагрузки. Среда аутентифицирует конкретного исполнителя. SPIFFE полезен здесь: его SVID — криптографически проверяемые документы идентичности рабочей нагрузки, а Workload API идентифицирует локальные нагрузки без внедрения секретов аутентификации в приложения.
4. Обмен учётными данными или управляемый шлюз. Среда либо выполняет операцию через управляемый шлюз, либо выдаёт изолированному исполнителю грант, привязанный к конкретному исполнению.
5. Изолированное исполнение и запись жизненного цикла. Исполнитель обращается к защищённой системе; среда фиксирует использование и результат, не сохраняя тело учётных данных.

Такая схема даёт модели право запрашивать, а не право носить секрет. Она делает содержательным и отказ: отклонённый запрос не оставляет в контексте агента токен с широкими возможностями, ожидающий следующего плана.

Формируйте грант для конкретного адресата и момента

OAuth 2.0 Token Exchange из RFC 8693 даёт полезную семантику для такой модели. Он различает делегирование и имперсонацию, а запрос может указать целевой ресурс или audience и scope. Поэтому брокер способен обменять аутентифицированное полномочие среды на токен, сформированный для одного адресата и разрешённого набора операций, а не выдать исполнителю универсальную учётную запись.

Грант должен быть короткоживущим, ограниченным аудиторией и настолько узким, насколько позволяет целевая система. Временные учётные данные — устоявшийся операционный паттерн: AWS рекомендует IAM-роли и временные данные вместо встроенных долгоживущих ключей, а AWS STS динамически создаёт данные с заданным сроком истечения. Vault может по запросу выдавать уникальные учётные данные для баз данных и назначать им аренду с TTL, которую можно отозвать по отдельности или по префиксу.

Короткий срок полезен, но не магичен. Украденный секрет всё ещё можно использовать, пока он действителен. И истечение срока не подтверждает, что учётная запись в целевой системе инвалидирована. Документация Vault отмечает: отзыв динамического секрета может не сработать, если Vault не может связаться с целевой системой. Среда должна отдельно фиксировать запрос на отзыв и подтверждённую инвалидацию, а затем сверять незавершённые случаи.

Привязывайте использование к исполнителю, если это поддерживает цель

Обычный bearer-токен полезен любому, кто им владеет. Токены с ограничением отправителя уменьшают эту переносимость. RFC 9449 определяет DPoP: токен привязывается к открытому ключу, а при использовании требуется доказательство владения. RFC 8705 описывает access-токены, привязанные к клиентскому сертификату mutual TLS. Эти механизмы не исключают любой повтор или злоупотребление делегированием: по-прежнему нужны корректная проверка доказательств, ограничение audience, привязка к запросу, защита ключей и короткий срок. Но скопированный токен становится менее полезным, чем обычный bearer-токен.

Исполнитель — правильное место для закрытого ключа или клиентского сертификата: его можно изолировать и аттестовать. Контекст, видимый языковой модели, — неправильное. Короткоживущие, автоматически ротируемые материалы идентичности SPIFFE могут стать основой аутентификации нагрузки, но SPIFFE не является системой авторизации. Проверка бизнес-цели, полномочий субъекта и политики на уровне операции остаётся задачей среды исполнения.

Аудит должен описывать полномочие, а не дублировать его

Автономной организации нужно объяснять не только то, что запрос дошёл до сервиса, но и почему он был разрешён и какое полномочие реально использовалось. Запись об исполнительном гранте должна содержать идентификатор гранта, идентификатор политического решения, идентичность рабочей нагрузки, цепочку делегирования, цель, целевой ресурс, одобренную операцию, ограничения, время выдачи и истечения, события использования, а также исходы запроса на отзыв и его подтверждения.

В ней не должно быть исходных учётных данных, закрытых ключей или полных тел токенов. Это не доказательства, а новые копии того, что архитектура пытается удержать в границах. Если нужна корреляция, её поддержат идентификаторы и уместные хеши, не превращая аудит в ещё одно хранилище секретов.

Kubernetes даёт близкий операционный урок. Он рекомендует projected service-account tokens и отмечает, что связанные токены могут быть инвалидированы при удалении объектов, таких как Pod или ServiceAccount. Жизненный цикл идентичности и учётных данных должен следовать жизненному циклу рабочей нагрузки и самой работы, а не сроку развёртывания приложения или памяти агента.

Что меняется в операционной модели

Эта архитектура переносит трудное решение из проектирования промпта в путь исполнения. Описания инструментов должны задавать доступные эффекты и необходимые входные данные, а не содержать API-ключи. Память может хранить одобренный контекст, ссылки и записи решений, но не долговременный материал доступа. Брокер учётных данных становится компонентом принуждения к политике, связанным с идентичностью нагрузки, изоляцией исполнителя и сверкой жизненного цикла, а не просто обёрткой над менеджером секретов.

Для некоторых эффектов учётные данные вообще не нужны. Если шлюз сам может проверить запрос и выполнить ограниченную операцию, это часто более чистая граница. Грант нужен, когда исполнитель должен напрямую взаимодействовать с целевым сервисом; его не следует по умолчанию выдавать каждому инструменту.

Компоненты стандартов уже существуют, хотя их соединение — инженерская дисциплина, а не готовый универсальный продукт. SPIFFE даёт идентичность рабочей нагрузки. OAuth token exchange задаёт лексику делегирования. DPoP и mutual TLS могут ограничивать использование токена. STS и Vault показывают временные и арендованные учётные данные. Активные черновики IETF WIMSE указывают на продолжающуюся работу над межсистемной аутентификацией нагрузок, но это Internet-Drafts, а не окончательные стандарты.

Правило управления просто: агенты могут участвовать в решениях об авторизации, представляя намерение и контекст, но многоразовые учётные данные должны оставаться вне их долговременного и видимого модели состояния. Автономная организация становится управляемее, когда полномочие выдаётся в последний ответственный момент, конкретной рабочей нагрузке, способной им воспользоваться, и для минимального эффекта, который организация одобрила.