Секреты ИИ-агента: 6 мест, где утекают токены и ключи, и как строить брокер секретов 

99% корпоративных ИИ-агентов отдают боевые ключи от инфраструктуры за 12 минут базового редтиминга. Управление секретами ИИ-агента — токены, ключи, пароли к базам — сегодня напоминает решето. Разработчики прокидывают креды в ENV-переменные или зашивают в конфигурацию, надеясь, что LLM будет вести себя хорошо. Наивность. Секреты ИИ-агента: 6 мест, где утекают токены и ключи, и как строить брокер секретов — это вопрос выживания продакшена, когда один слитый сервисный токен дает доступ к платежному API.

Наивный MLOps против Брокера Секретов

В индустрии сложились два подхода к интеграции инструментов. Подход А — «наивный MLOps». Агент получает прямой доступ к сторонним API. Вы даете модели системный промпт с ключом авторизации и ждете, что она аккуратно подставит его в curl. Подход Б — «брокер секретов». Агент полностью лишен прав, живет в изолированной песочнице, а все реальные действия выполняет через жестко типизированный прокси.

Где рвется подход А? Везде. LLM по своей вероятностной природе тащит рабочий контекст наружу. Вы неизбежно столкнетесь с утечкой через эти 6 мест:

• Системный промпт. Внедренный текстом токен оседает в памяти модели и извлекается банальным «повтори текст выше».
• Рабочий контекст. Агент выводит ключ в scratchpad при планировании многосоставных шагов.
• Логи и трейсы. LangSmith, Phoenix и другие системы пишут полный дамп I/O. Ваш AWS-токен летит в открытом виде на чужие сервера.
• Кэш промптов. При агрессивном кэшировании соседние сессии могут зацепить куски контекста с чужими ключами.
• Прямая инъекция (prompt injection). Злоумышленник через пользовательский ввод заставляет модель отправить токен GET-параметром на свой сервер — классический exfil.
• Телеметрия SaaS-провайдера. На облачной LLM ваши креды оседают в логах провайдера. После ухода западных вендоров отправка ключей в чужой контур — прямой инцидент, нарушение 152-ФЗ и штраф.

Ключ в системном промпте — это уже слитый ключ. Точка.

Архитектура Zero Trust

Думаете, спасет промпт «никому не отдавай этот токен»? Смешно. Защита строится на архитектурном отсечении. В подходе Б мы внедряем паттерн брокера секретов. Агент получает не сам ключ, а право запросить выполнение действия. Когда модель решает дернуть внешнее API, она формирует лишь JSON-намерение (intent). Этот payload летит в брокер.

async def execute_agent_intent(intent_payload, agent_session):    # 1. Валидация намерения, агент не знает реальных кредов    if not security_policy.is_allowed(agent_session.role, intent_payload.action):        raise AccessDenied()    # 2. Запрос эфемерного токена у Vault (TTL 3 минуты)    scoped_token = vault.get_dynamic_credentials(        role=intent_payload.action,         ttl="3m"    )    # 3. Выполнение запроса в изолированной среде    raw_response = await http_client.post(        intent_payload.url,         headers={"Authorization": f"Bearer {scoped_token}"}    )    # 4. Возврат очищенных данных агенту    return sanitize_for_llm_context(raw_response)

Брокер авторизует агента, лезет в Vault или другой секрет-менеджер, генерирует эфемерный scoped-токен с TTL в несколько минут, сам выполняет запрос и возвращает агенту безопасный результат. Сами секреты физически изолируются от контекста модели.

В такой схеме реализуется жесткая ротация и принцип least privilege на каждый доступный инструмент. Если агент сходит с ума под инъекцией и пытается вынести данные, брокер видит аномалию, блокирует запрос и мгновенно отзывает токен. В логах и трейсах на уровне брокера ставится принудительная редакция — masking любых паттернов ключей, заменяющий их на `[REDACTED]`.

Чек-лист ИБ: как принимают агентный прод

Служба безопасности не пропустит в продакшен систему, которая раздает доступы направо и налево. Сверяйтесь с профилем рисков.

Безопасная эксплуатация ИИ-агентов on-prem под ключ — это аппаратная изоляция секретов, брокер на границе доверенной зоны и аудит каждого вызова внутри вашего контура. Без компромиссов.