Статья Безопасность NHI в AI-агентах: attack paths, SIEM-detection и чеклист least privilege

На аудите облачной инфраструктуры финтех-компании в марте этого года нашёл сервисный аккаунт LLM-агента с правами s3:* и iam:PassRole. Токен не ротировался 9 месяцев, а агент использовал от силы два API-вызова: s3:GetObject на один бакет и bedrock:InvokeModel. Остальные 47 разрешений висели мёртвым грузом. Через memory-модуль агента (LangChain с Redis-бэкендом) этот токен был доступен любому, кто проведёт prompt injection. Разница между "AI-помощник отвечает на вопросы" и "полный доступ к продовой инфраструктуре" - одна инъекция в промпт и один overprivileged credential.

Масштаб проблемы: почему NHI в AI-агентах - слепая зона SOC​

Non-human identity (NHI) - сервисные аккаунты, API-ключи, OAuth-токены, сертификаты, pipeline-идентичности - давно перестали быть чем-то вспомогательным. В cloud-native средах соотношение NHI к человеческим идентичностям достигает 45:1 и выше (данные Entro Security, подтверждённые публикациями CSA). Между 2024 и 2025 годами популяция машинных идентичностей выросла на 44% (Entro Labs). Подробнее - в нашем руководстве по безопасность llm приложений.

AI-агенты - самая быстрорастущая категория NHI. Gartner прогнозирует: 33% корпоративных приложений будут содержать agentic AI к 2028 году (в 2024 - менее 1%). Microsoft Copilot Studio уже перевалил за миллион созданных агентов. При этом, по данным CSA, более 16% организаций вообще не отслеживают создание идентичностей, связанных с AI, а 85% не уверены в своей способности предотвратить атаку через NHI.

Для SOC-команд это конкретная головная боль: AI-агент - не детерминированный бот, который гоняет одну и ту же операцию по кругу. Он решает в runtime, какие API вызывать, в какой последовательности и с какими параметрами. Попробуй построй baseline на таком.

Характеристика	Классический NHI	NHI AI-агента
Поведение	Детерминированное	Недетерминированное, зависит от промпта
Набор API-вызовов	Фиксированный	Динамический, определяется в runtime
Baseline для SIEM	Стабильный, строится за 14-30 дней	Подвижная цель, требует категоризации
Blast radius	Ограничен scope аккаунта	Расширяется через tool-calling и sub-agents
Управление lifecycle	Через IAM-политики	Часто вне scope IAM-команды

CSA в своём whitepaper формулирует точно: AI-агенты "acquire permissions dynamically at runtime, spawn sub-agents, invoke external APIs, write and execute code, and chain together actions that can span dozens of systems""Получать разрешения динамически во время выполнения, запускать субагентов, вызывать внешние API, писать и выполнять код, а также объединять действия, которые могут охватывать десятки систем". Стандартные IAM-процессы, заточенные под человеческие аккаунты, к этому не готовы. И честно говоря, не скоро будут.

Анатомия атаки: от компрометации токена агента до lateral movement​

Attack path с маппингом на MITRE ATT&CK​

Разберём типичный вектор, который я наблюдал в вариациях на нескольких аудитах machine-to-machine аутентификации в LLM-пайплайнах.

Фаза 1 - Initial Access. Атакующий эксплуатирует Prompt Injection (LLM01:2025 по OWASP Top 10 for LLM Applications). Через пользовательский ввод или отравленный документ в RAG-пайплайне агент получает инструкцию, меняющую его логику. В контексте безопасности NHI в AI-агентах это не jailbreak ради "смешного ответа" - это использование легитимных credentials агента для нелегитимных действий. MITRE ATT&CK: T1078 (Valid Accounts). Агент действует от имени своего сервисного аккаунта, и с точки зрения IAM всё выглядит чисто.

Фаза 2 - Credential Access. Агент хранит токены для обращения к внешним сервисам. В multi-agent системах (AutoGen, CrewAI) каждый суб-агент может держать собственный набор credentials, передаваемых через shared memory или environment variables. MITRE ATT&CK: T1528 (Steal Application Access Token) - извлечение токенов из memory-модуля. Если агент запущен на EC2/GCE без ограничения IMDS - T1552.005 (Cloud Instance Metadata API) даёт временные credentials через один HTTP-запрос.

Конкретный сценарий: LangChain-агент с доступом к Vault через AppRole. Если secret_id захардкожен в переменных окружения (а по данным GitGuardian State of Secrets Sprawl 2025, в 2024 году на public GitHub утекли 23.77 миллиона секретов), prompt injection позволяет агенту запросить произвольный секрет из Vault. Vault тут ни при чём - уязвимы избыточные права NHI агента.

Фаза 3 - Lateral Movement и Persistence. Полученные токены используются для доступа к смежным сервисам: T1550.001 (Application Access Token). Если токен AI-агента содержит права iam:AttachRolePolicy или аналоги в Azure/GCP - атакующий закрепляет persistence через T1098.003 (Additional Cloud Roles). В одном из кейсов AI-агент с правами на Terraform state file мог модифицировать IAM-политики через IaC-пайплайн - persistence без прямого обращения к IAM API. Элегантно, если бы не было так страшно.

Insider threat: когда легитимный агент становится инсайдером​

Компрометация сервисных аккаунтов LLM - это по сути insider threat. Скомпрометированный AI-агент действует от своего валидного NHI, с валидными credentials, из ожидаемой подсети. Для SIEM он выглядит как легитимный процесс. В отличие от внешнего злоумышленника с украденным паролем, здесь нет anomalous login, нет impossible travel, нет bruteforce - только необычный набор API-вызовов. А если baseline агента и так нестабилен из-за недетерминированной природы - аномалия тонет в шуме.

По данным Verizon DBIR, украденные credentials - самый распространённый вектор initial access: 22% всех инцидентов. SpyCloud (Annual Identity Exposure Report) фиксирует миллионы утёкших API-ключей и токенов ежегодно. Для AI-related secrets (ключи к AI API, конфигурационные токены агентов) рост составил 81% за год - самый быстрый среди всех категорий credentials, по данным GitGuardian.

Токены с избыточными правами в LLM-пайплайнах​

Overprivileged access - проблема номер два после утечки секретов по OWASP NHI Top 10. Для AI-агентов она ещё острее: разработчик даёт агенту максимальные права при прототипировании, а сужение scope откладывается. Навсегда.

Один токен на все tool-calls. LLM-агент через MCP (Model Context Protocol) или function calling обращается к 5-7 сервисам. Вместо отдельных credentials на каждый - один сервисный аккаунт с union всех разрешений. Если один tool скомпрометирован - blast radius покрывает все остальные.

Long-lived credentials без ротации. NHI AI-агентов, по определению, "don't log out, can't use MFA, and are rarely retired""не выходят из системы, не могут использовать многофакторную аутентификацию и редко выходят" (Veeam). На одном из аудитов я обнаружил AWS access key для SageMaker-агента, не менявшийся 14 месяцев - при рекомендованной ротации в 90 дней. Четырнадцать месяцев. Для прода.

Orphaned identities. Data science команда тестирует 10 вариантов агентов, каждому создаёт сервисный аккаунт. 8 агентов отбрасываются, аккаунты остаются активными без владельца. Привилегированный доступ машинных идентификаторов к продовым ресурсам - без человека, ответственного за их lifecycle.

Вот минимальная IAM policy, ограничивающая scope LLM-агента для RAG:

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": ["s3:GetObject"],
     "Resource": "arn:aws:s3:::rag-docs-prod/*"},
    {"Effect": "Allow", "Action": ["bedrock:InvokeModel"],
     "Resource": "arn:aws:bedrock:us-east-1:*:model/anthropic.claude-*"}
  ]
}

По документам разработчик пишет "scope будет минимальным". На практике в большинстве проверенных мной конфигураций стоит "Action": "s3:[I]" или "Action": "[/I]". Угадайте, какой вариант встречается чаще.

Detection-чеклист: правила корреляции для NHI в SIEM​

Что мониторить: конкретные алерты​

Для SOC-команд, работающих с безопасностью API токенов в AI системах, ниже - чеклист корреляционных правил. Каждое правило привязано к конкретному TTP.

1. Anomalous API call pattern - агент вызывает API вне baseline (например, iam:CreateUser при обычном s3:GetObject). Индикатор prompt injection через NHI. Связан с T1078.
2. Credential usage from unexpected source IP - токен агента используется из IP, не совпадающего с VPC/подсетью развёртывания. T1550.001.
3. Token usage outside execution window - для агентов с cron-расписанием любая активность вне окна выполнения - алерт.
4. Spike in API calls volume - резкий рост числа вызовов указывает на data exfiltration или перебор ресурсов. T1528.
5. Access to secrets stores - обращение агента к Vault, Secrets Manager или Parameter Store за секретами вне baseline. T1552.005.
6. Cross-account access - NHI агента обращается к ресурсам в чужом аккаунте/проекте. T1550.001.
7. Anomalous role assumption - агент принимает роль (AssumeRole), которую раньше не использовал. T1548.005 (Temporary Elevated Cloud Access).

Пример Sigma-подобного правила для detection аномального AssumeRole:

title: AI Agent NHI - Anomalous Role Assumption
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName: AssumeRole
    userIdentity.type: AssumedRole
    userAgent|contains: 'langchain'
  filter:
    requestParameters.roleArn|endswith:
      - 'rag-reader-role'
  condition: selection and not filter
level: high

Построение baseline для недетерминированных агентов​

Для детерминированного сервисного аккаунта baseline строится за 14-30 дней по фиксированному набору API-вызовов. С AI-агентами этот подход ломается - их поведение зависит от пользовательских промптов, и два одинаковых запроса могут породить совершенно разные цепочки вызовов.

Рабочая схема, которую я обкатал на нескольких проектах:

• Ограничить набор доступных tools на уровне конфигурации агента (MCP server config, function calling schema) - это верхняя граница baseline
• Логировать каждый tool-call с метаданными: какой tool, параметры, инициирован пользователем или автоматически
• Строить baseline по категориям: read / write / admin, а не по конкретным вызовам
• Любое действие категории admin от NHI агента - алерт без исключений. Без вариантов.

Least privilege для автономных систем - практический чеклист​

Требования к окружению​

Чеклист применим к AI-агентам в:

• AWS: IAM + Bedrock/SageMaker, STS для short-lived tokens
• Azure: Managed Identities + OpenAI Service
• GCP: Service Accounts + Vertex AI, Workload Identity Federation
• On-premise: HashiCorp Vault 1.15+ для секретов, SPIFFE/SPIRE 1.9+ для machine identity
• Гибрид: cloud LLM + on-prem data sources через VPC peering

Десять правил управления секретами AI агентов​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Регуляторы уже догоняют: SOC 2 и ISO 27001 всё чаще требуют документированного governance machine identities, а не только человеческих. При инциденте с NHI AI-агента отсутствие audit trail и процесса ротации - отягчающий фактор и для регулятора, и для страховой.

Большинство организаций, внедряющих AI-агентов, находятся в стадии "лишь бы работало". Сервисные аккаунты создаются data-инженерами без оглядки на identity и access management для AI - и это не их вина, это отсутствие процесса. Из всех аудитов NHI за последние полтора года я вынес одно наблюдение: проблема не в технологии. Vault ротирует секреты, STS выдаёт short-lived tokens, SPIFFE/SPIRE решают inter-agent auth. Инструменты есть и работают. Проблема - NHI AI-агентов вообще не попадают в scope review. IAM-команда управляет человеческими аккаунтами, DevOps - пайплайнами, а кто управляет идентичностями LLM-агентов - не знает никто. По данным CSA, только 15% организаций уверены в своей защите от NHI-атак. Через два года, когда по прогнозу Gartner треть корпоративных приложений будет содержать agentic AI, этот вопрос из академического станет операционным - отвечать на него придётся SOC-командам, которые сегодня даже не видят эти идентичности в своих дашбордах. Тем, кто начинает строить detection-pipeline под AI-инфраструктуру, имеет смысл заглянуть в тред на codeby.net по инвентаризации NHI и настройке алертов на аномальное поведение машинных идентичностей - там коллеги обсуждают конкретные подходы под разные SIEM-стеки.