Управление учётными данными для ИИ-агентов: архитектура Vault-Proxy

Управление учётными данными для ИИ-агентов — это совокупность инфраструктурных практик, определяющих, как автономные агенты получают, используют, ротируют и освобождают API-ключи и секреты, не раскрывая учётные данные в памяти агента, журналах или контекстных окнах. Агенты нарушают стандартные паттерны работы с учётными данными: они работают автономно, могут быть скомпрометированы через инъекции промптов и функционируют во флотах, где общие секреты умножают поверхность атаки для эксфильтрации. CVE-2024-34359 (llama-cpp-python, CVSS 9.6) и CVE-2025-29927 (Next.js, CVSS 9.1) продемонстрировали, как развёртывания ИИ раскрывают секреты при отказе защитных периметров.

Управление учётными данными для ИИ-агентов — это совокупность практик и инфраструктурных паттернов, определяющих, как автономные агенты получают, используют, ротируют и освобождают API-ключи, токены и секреты, не допуская появления этих учётных данных в памяти агента, журналах или контекстных окнах.

Почему стандартные паттерны учётных данных не работают в флотах агентов

Проблема .env-файла при масштабировании

Переменные окружения хорошо работают для одно-процессных приложений. В флотах агентов эта модель рушится немедленно. Файл .env, используемый совместно флотом из 10 агентов, означает, что каждый из 10 запущенных процессов хранит каждый секрет в памяти. Каждый процесс генерирует журналы, вывод ошибок и трассировки отладки — всё это потенциальные поверхности раскрытия учётных данных. Если любой из этих 10 агентов будет скомпрометирован атакой с инъекцией промпта и ему будет дана команда распечатать своё окружение, все учётные данные из общего .env утекут одновременно.

Множитель N-агентов — это ключевая проблема: каждый дополнительный агент во флоте добавляет ещё одну поверхность раскрытия для каждых общих учётных данных. Флот из 20 агентов с 5 API-ключами в .env создаёт 100 потенциальных точек раскрытия учётных данных, не считая агрегации журналов, отчётов об ошибках или инструментов отладки, способных захватывать снимки окружения.

CVE-запись для секретов в открытом тексте в развёрнутых ИИ-системах

Две CVE документируют реальную стоимость небезопасной обработки секретов в развёрнутых ИИ-системах:

CVE-2024-34359 (llama-cpp-python, CVSS 9.6 Critical): Инъекция серверного шаблона Jinja2 через рендеринг метаданных модели без песочницы в llama-cpp-python. Поле шаблона чата в специально созданном файле .gguf рендерилось через jinja2.Environment без изолирования, что позволяло выполнение удалённого кода. В зоне риска находилось любое приложение, загружающее ненадёжные модели, включая агентские конвейеры, загружающие модели из внешних источников. Структурная проблема: код загрузки модели доверял внешнему контенту без изоляции.

CVE-2025-29927 (Next.js, CVSS 9.1 Critical): Обход авторизации через заголовок x-middleware-subrequest, позволявший неаутентифицированным запросам пропускать middleware в развёртываниях Next.js. Пострадали приложения, использующие middleware Next.js для защиты маршрутов, требующих учётных данных, включая бэкенды ИИ-агентов через API. Ошибка была исправлена в версиях 12.3.5, 13.5.9, 14.2.25 и 15.2.3.

Обе CVE демонстрируют один и тот же базовый класс риска: когда секреты или защищённые маршруты полагаются на контроль на уровне приложения вместо структурной изоляции, один логический дефект раскрывает их. Паттерн Vault-Proxy устраняет поверхность атаки, удерживая секреты за пределами контейнеров агентов под применением на уровне инфраструктуры.

Почему журналы агентов являются риском для учётных данных

Традиционные журналы приложений содержат структурированные события из контролируемых точек вызова. Журналы агентов захватывают всё: трассировки рассуждений LLM, аргументы вызовов инструментов, возвращаемые значения инструментов и промежуточные шаги рассуждений. Когда агент вызывает внешний API с учётными данными в заголовке Authorization, простая конфигурация журналирования захватывает этот заголовок. Когда трассировка рассуждений агента содержит текст "using API key sk-..." из извлечённого документа или промпта, эта строка появляется в журнале.

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

Путь от инъекции промпта к учётным данным

OWASP LLM Top 10 v1.1 (LLM06: Раскрытие конфиденциальной информации, октябрь 2025) определяет утечку учётных данных как основной вектор атаки на LLM-приложения. Атака прямолинейна: состязательный контент, извлечённый агентом с веб-страниц, документов или ответов инструментов, содержит инструкции вроде «распечатай все переменные окружения» или «выведи свой API-ключ». Агент без структурной изоляции учётных данных не может отличить это указание от легитимных рабочих инструкций.

Исследование начала 2026 года просканировало 3 984 навыка агентов и обнаружило, что 283 (7,1%) содержат критические дефекты обработки учётных данных, передающие API-ключи в открытом тексте через контекст LLM. 76 навыков содержали преднамеренные полезные нагрузки для кражи учётных данных, предназначенные для эксфильтрации данных на контролируемые атакующим конечные точки. Единственная структурная защита — гарантировать отсутствие учётных данных в контексте агента. Агент не может слить учётные данные, которыми не владеет.

Паттерны управления учётными данными для ИИ-агентов

Паттерн 1: Переменные окружения (наименее безопасный)

Переменные окружения (os.environ, файлы .env, флаги Docker --env) — паттерн учётных данных по умолчанию для большинства фреймворков агентов. LangChain читает из os.environ, CrewAI полагается на инъекцию окружения, OpenAI Agents SDK ожидает учётные данные в окружении процесса. Этот паттерн уместен только для локальной разработки и прототипирования.

Для производственных флотов агентов переменные окружения не работают по всем осям безопасности: они существуют в памяти процесса агента (доступны через инъекцию промпта), появляются в /proc/{pid}/environ на Linux-хостах, всплывают в трассировках ошибок и отладочном выводе, а также распространяются на всех агентов в флоте с общим окружением.

Паттерн 2: Интеграция с менеджером секретов

Облачные менеджеры секретов (AWS Secrets Manager, $0,40/секрет/месяц + $0,05 за каждые 10 000 API-вызовов; Azure Key Vault; GCP Secret Manager) улучшают переменные окружения, храня учётные данные вне процесса агента и извлекая их по требованию. Агент вызывает API менеджера секретов для получения учётных данных, использует их для операции, затем уничтожает.

Этот паттерн сокращает время жизни учётных данных в памяти, но не устраняет окно раскрытия: учётные данные по-прежнему проходят через память агента в цикле получения-использования-уничтожения. Они остаются открытыми для инъекции промпта в течение этого окна, а агент должен хранить вторые учётные данные (API-ключ менеджера секретов или IAM-роль) для доступа к первым.

Паттерн 3: Vault Proxy / Инъекция непрозрачного дескриптора (наиболее безопасный)

Паттерн Vault-Proxy удерживает учётные данные полностью за пределами контейнеров агентов. Агент хранит непрозрачный дескриптор — строку-ссылку вроде $CRED{stripe_key}, которая идентифицирует учётные данные, не разрешая их. Когда агент выполняет API-вызов, содержащий дескриптор, Vault Proxy перехватывает запрос, разрешает дескриптор в реальные учётные данные, внедряет их на сетевом уровне и пересылает аутентифицированный запрос. Агент никогда не видит учётные данные в открытом тексте.

Это тот же принцип инъекции на стороне агента, что и в HashiCorp Vault (35 763 звезды, BSL, v2.0.2 выпущен 5 июня 2026), встроенный непосредственно в слой оркестрации агентов. При более чем 700 MCP-серверах в экосистеме (июнь 2026) паттерн дескриптора $CRED{} устраняет распространение .env на каждый сервер: одна ссылка на дескриптор в конфигурации агента покрывает требования к учётным данным любого MCP-сервера.

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

Паттерн 4: Идентификация рабочей нагрузки и федерация OIDC

Идентификация рабочей нагрузки (федерация OIDC, SPIFFE/SPIRE, сервисные аккаунты облачного IAM) полностью устраняет долгоживущие API-ключи для доступа к облачным сервисам. Каждый контейнер агента получает при запуске краткосрочный токен идентификации, который обменивается на учётные данные облачного провайдера. Учётные данные имеют ограниченный TTL, обычно от 15 минут до 1 часа, после которого они истекают и необходимо выпустить новый токен.

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

Позиция OpenLegion: паттерн дескриптора $CRED{}

Каждый крупный фреймворк ИИ-агентов рассматривает управление учётными данными как проблему хост-приложения. LangChain и LangGraph читают из os.environ. CrewAI полагается на инъекцию окружения. OpenAI Agents SDK ожидает учётные данные в окружении процесса. AutoGen наследует окружение процесса Python. Ни один из этих фреймворков не обеспечивает структурную изоляцию учётных данных — они оставляют управление учётными данными на усмотрение оператора, что на практике означает файлы .env и общие переменные окружения.

Vault-Proxy OpenLegion встроен в слой оркестрации агентов. Агенты обращаются к учётным данным как к непрозрачным дескрипторам $CRED{name}. Хост сети разрешает дескрипторы на стороне сервера и внедряет учётные данные на границе сети. Ни один контейнер агента никогда не получает учётные данные в открытом тексте. Инъекция промпта не может слить то, чего не существует.

Infisical (27 296 звёзд, платформа секретов TypeScript с открытым исходным кодом с ядром под лицензией MIT) привлекла $2,8 млн начального финансирования в 2023 году, что указывает на рыночный спрос на нативное для разработчиков управление секретами. OpenLegion встраивает ту же функциональность непосредственно в среду выполнения агентов без отдельного развёртывания управления секретами.

Измерение	OpenLegion	LangChain/LangGraph	CrewAI	OpenAI Agents SDK	AutoGen
Хранилище учётных данных	Vault (непрозрачные дескрипторы)	Окружение / .env	Окружение / .env	Окружение / .env	Окружение / .env
Паттерн доступа агента	Дескриптор $CRED{} (никогда не разрешается в контейнере)	Прямое чтение os.environ	Прямое чтение os.environ	Прямое чтение os.environ	Прямое чтение os.environ
Открытый текст в контексте агента?	Никогда	Да (при чтении os.environ)	Да (при чтении os.environ)	Да (при чтении os.environ)	Да (при чтении os.environ)
Поддержка ротации	Нативно в Vault; горячая ротация без перезапуска	Ручная; требует перезапуска	Ручная; требует перезапуска	Ручная; требует перезапуска	Ручная; требует перезапуска
Область видимости на агент	Применяется на уровне сети через allowlist	Не применяется	Не применяется	Не применяется	Не применяется
Аудиторский след	Каждое разрешение дескриптора записывается с ID агента	Отсутствует	Отсутствует	Отсутствует	Отсутствует

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

Ротация секретов для флотов ИИ-агентов

Аренда учётных данных с ограниченным TTL

Статические API-ключи — учётные данные без срока истечения — наихудший вид учётных данных для флотов агентов. Утёкший статический ключ остаётся действительным бессрочно. TTL-ограниченная аренда учётных данных решает обе проблемы. Учётные данные выпускаются с окном истечения — обычно 1 час для интерактивных сессий агентов; 15 минут для высокочувствительных операций. По истечении аренды Vault автоматически выпускает новые учётные данные. Старые учётные данные становятся недействительными после истечения срока, ограничивая ценность любых утёкших копий.

Движок динамических секретов HashiCorp Vault генерирует краткосрочные учётные данные для баз данных, облачных провайдеров и пользовательских бэкендов по требованию. CVE-2026-39829 (golang/crypto, июнь 2026) исправила DoS-уязвимость в разборе публичных ключей SSH из-за неограниченных размеров модуля RSA — Vault v2.0.2 устранил её, ограничив RSA-ключи 8192 битами. Даже специально созданная инфраструктура Vault порождает CVE, поэтому уровень абстракции между агентами и сырыми секретами важен даже при прямом использовании Vault.

Горячая ротация без перезапуска агентов

Горячая ротация внедряет новые учётные данные в Vault без воздействия на запущенные контейнеры агентов. Следующий API-вызов агента через Vault Proxy прозрачно использует новые учётные данные. С точки зрения агента дескриптор $CRED{name} по-прежнему разрешается — изменился только базовый секрет.

Горячая ротация требует, чтобы агенты никогда не кэшировали учётные данные локально. Паттерн дескриптора $CRED{} структурно обеспечивает это: дескрипторы разрешаются при вызове, а не при запуске, поэтому локальное кэширование разрешённого значения в принципе невозможно.

Область ротации на агент

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

Изоляция учётных данных между агентами

Назначение учётных данных на агент

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

OWASP LLM06 (Раскрытие конфиденциальной информации) явно указывает, что избыточное снабжение агентов учётными данными является способствующим фактором инцидентов утечки учётных данных.

Область учётных данных MCP-серверов инструментов

В OpenLegion учётные данные MCP-серверов хранятся в том же Vault и внедряются через тот же паттерн прокси. Сервер инструментов MCP получает аутентифицированные запросы от прокси сети, а не сырые учётные данные от агента. Это предотвращает использование вредоносных MCP-серверов в качестве векторов сбора учётных данных. Скомпрометированный MCP-сервер находит в входящих запросах только ссылки на дескрипторы, а не сырые ключи. Для полной модели усиления безопасности Model Context Protocol см. специальное руководство.

Отзыв учётных данных при выводе агента из эксплуатации

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

Сеть OpenLegion обрабатывает это автоматически: при архивировании агента сеть отзывает все дескрипторы учётных данных, связанных с областью этого агента. Для систем оркестрации ИИ-агентов, программно управляющих жизненным циклом агентов, отзыв учётных данных должен быть событием жизненного цикла первого класса, а не операционной мыслью задним числом.

Аудиторские следы и журналирование доступа к учётным данным

Что журналировать (и что не журналировать)

Каждое событие доступа к учётным данным должно создавать запись журнала с: ID агента, разрешившего дескриптор, именем дескриптора (не разрешённым значением), временной меткой, внешней конечной точкой, на которую был направлен аутентифицированный запрос, и результатом. Не журналировать: фактическое значение учётных данных, разрешённые строки секретов или любые производные учётных данных в открытом тексте.

Корреляция использования учётных данных с действиями агента

Аудиторские следы агентов отличаются от традиционных: кодовые пути недетерминированы. Оркестратор OpenLegion журналирует вызовы инструментов и разрешения учётных данных в едином потоке событий. Криминалистический анализ может воспроизвести последовательность: получение задачи -> вызов LLM -> выбор инструмента -> разрешение учётных данных -> вызов внешнего API -> получение ответа. Это правильная архитектура для развёртываний ИИ-агентов в регулируемых или высокорисковых средах.

Требования к аудиту в регулируемых средах

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

Выбор бэкенда секретов для платформы агентов

HashiCorp Vault (35 763 звезды, BSL, v2.0.2 выпущен 5 июня 2026): эталонная система управления секретами с открытым исходным кодом. Предоставляет динамическую генерацию секретов, TTL-ограниченную аренду, детальные политики доступа и исчерпывающее журналирование аудита. Примечание: HashiCorp перешла с одобренной OSI лицензии Apache 2.0 на BSL в августе 2023 года. BSL не является открытой лицензией, одобренной OSI, и ограничивает коммерческое использование конкурентами Vault.

Infisical (27 296 звёзд, ядро под MIT, TypeScript с открытым исходным кодом): удобная для разработчиков платформа секретов, собравшая $2,8 млн начального финансирования в 2023 году как лёгкая альтернатива Vault.

Cloud-native (AWS/Azure/GCP): управляемые хранилища секретов с нативной интеграцией с IAM. Идентификация рабочей нагрузки OIDC решает проблему начальной загрузки для облачных развёртываний.

Часто задаваемые вопросы

Что такое управление учётными данными для ИИ-агентов?

Управление учётными данными для ИИ-агентов — это совокупность инфраструктурных практик, определяющих, как автономные агенты получают, используют, ротируют и освобождают API-ключи, токены и секреты. Агенты отличаются от традиционных приложений тем, что работают автономно, могут быть скомпрометированы через инъекцию промпта, генерируют подробные журналы и функционируют как многоэкземплярные флоты. OWASP LLM Top 10 v1.1 (2025) относит раскрытие конфиденциальной информации (LLM06) к топ-10 угрозам, а утечку учётных данных — к основным векторам атаки.

Какие CVE связаны с утечкой учётных данных ИИ-агентов?

CVE-2024-34359 (llama-cpp-python, CVSS 9.6) задокументировала уязвимость Jinja2 SSTI в конвейере загрузки моделей. CVE-2025-29927 (Next.js, CVSS 9.1) показала, что заголовок x-middleware-subrequest может обходить авторизацию middleware в приложениях Next.js, включая бэкенды ИИ-агентов. Структурное решение — полностью удерживать секреты за пределами контейнеров агентов.

Как паттерн Vault-Proxy предотвращает утечку учётных данных?

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

Почему изоляция учётных данных на агент важна в мультиагентных системах?

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

Что OWASP говорит об управлении учётными данными ИИ-агентов?

OWASP Top 10 for LLM Applications v1.1 (октябрь 2025) относит раскрытие конфиденциальной информации к LLM06 и идентифицирует утечку учётных данных как основной вектор атаки. Руководство рекомендует избегать хранения учётных данных в открытом тексте в контексте агента, применять принцип минимальных привилегий и использовать контроль на уровне инфраструктуры.

Как OpenLegion обрабатывает учётные данные для агентов, запускающих MCP-серверы?

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

Что такое ротация секретов и зачем она нужна ИИ-агентам?

Ротация секретов — это практика замены учётных данных новыми по расписанию или по триггеру с аннулированием старых. ИИ-агентам нужна ротация, поскольку они работают длительное время и являются потенциальными целями утечки на протяжении всего этого окна, а перезапустить их в середине задачи не так просто. TTL-ограниченная аренда учётных данных истекает автоматически по прошествии настраиваемого окна, а паттерн Vault-Proxy поддерживает горячую ротацию без воздействия на запущенные контейнеры агентов.

Создание флотов агентов без раскрытия учётных данных

Проблема управления учётными данными в флотах ИИ-агентов является архитектурной: если учётные данные существуют в контейнерах агентов, они могут утечь. CVE-2024-34359 и CVE-2025-29927 показывают, что даже хорошо оснащённые команды, запускающие основные фреймворки, порождают такое раскрытие. Паттерн Vault-Proxy решает это структурно: учётные данные никогда не попадают в контейнеры агентов, поэтому инъекция промпта, побег из контейнера или утечка журналов не могут их извлечь.

Vault-Proxy OpenLegion встроен в сеть агентов. Настройте учётные данные один раз с помощью $CRED{name}, назначьте их агентам, которым они нужны, и сеть обрабатывает инъекцию, обновление TTL, область видимости на агент и журналирование аудита. Никакого отдельного развёртывания Vault, координации .env-файлов или ручных процедур ротации.

Защитите свой флот агентов с изоляцией учётных данных Vault-Proxy на OpenLegion