AI-агенты в облачной инфраструктуре: как автоматизировать расследование и устранение инцидентов в Azure без риска утечки

Я — Денис Шохирев, Enterprise AI architect из Фрайбурга, Германия. В DennisCraft AI Studio я внедряю AI-агентов для клиентов в DACH-регионе: логистика, финтех, промышленная автоматизация. Мой стек — Claude, Supabase, n8n, Doppler, self-hosted Postgres. В прошлом месяце я поймал утечку токена Azure на этапе генерации playbook'а — баг не ушёл в прод только благодаря паттерну в semgrep.

Проблема: автоматизация инцидентов в Azure и риск утечек

Масштабируемая автоматизация расследования и устранения инцидентов в Azure требует передачи агенту широких прав. В классической схеме — автоматизация через Logic Apps, runbooks или кастомные скрипты. Сейчас я массово использую AI-агентов для анализа алертов, корреляции событий и исполнения remediaton-плейбуков. Но любой агент с доступом к prod-ресурсам — потенциальная точка утечки.

Два главных риска:

• AI-агент получает избыточные права (например, Contributor на всю подписку).
• Чувствительные данные (секреты, токены, логи) могут утечь через LLM-запросы — особенно при использовании внешних API.

В 2023 году Microsoft признала, что 86% утечек в облаке связаны с неправильной настройкой identity и доступов (Microsoft Identity Threat Landscape 2023).

Архитектура: безопасная интеграция AI-агентов в Azure

Компоненты на проде

Паттерн: минимизация данных в LLM-запросах

Я не передаю сырые логи или переменные окружения напрямую в промпт Claude/LLM. Все чувствительные поля проходят маскирование через регулярные выражения на этапе препроцессинга.

import re

def mask_secrets(log: str) -> str:
    # Скрываем токены и ключи (Azure, JWT и т.д.)
    log = re.sub(r'(token|key|secret)\s*=\s*["\']?[\w-]+["\']?', r'\1=***', log, flags=re.IGNORECASE)
    # Маска для email-адресов
    log = re.sub(r'[\w\.-]+@[\w\.-]+', '[EMAIL]', log)
    return log

Этот препроцессинг встроен в каждый модуль n8n, где данные могут пойти в LLM. Статический анализ на этапе CI/CD — через semgrep и bandit.

Изоляция агентов и ограничение прав

Service Principal с минимальными правами

Каждый агент получает отдельного сервисного пользователя (Service Principal) с правами строго по принципу least privilege. Например, для автоматического перезапуска VM — только role Virtual Machine Contributor. Нет общего Contributor/Admin доступа на подписку.

az ad sp create-for-rbac --name "incident-agent" \
  --role "Virtual Machine Contributor" \
  --scopes "/subscriptions//resourceGroups//providers/Microsoft.Compute/virtualMachines"

Контроль секретов через Doppler

Все переменные окружения, токены и ключи — только через Doppler, с audit log и ротацией. Агент не хранит секреты в базе и не выводит их в логи.

Воркфлоу расследования и remediation

Инцидент-триггер

1. Azure Monitor отправляет алерт в n8n (через webhook или Event Grid). 2. n8n запускает воркфлоу: извлекает детали инцидента, вызывает агент-LLM для анализа и предложения remediation. 3. Агент отправляет masked данные на Claude для генерации пошагового remediation-плана.

// n8n custom function node
const incident = items[0].json;
const maskedLog = $evaluateExpression('={{ $json["log"] }}', { mask: mask_secrets });
return [{ json: { incidentId: incident.id, log: maskedLog } }];

Валидация remediation и аудит

Все remediation-плейбуки проходят ручную валидацию (ручная кнопка в n8n), если затрагиваются критичные ресурсы. Действия агентов логируются в отдельную таблицу Postgres для post-mortem анализа.

Автоматизация без передачи секретов

Везде, где возможно, remediation-скрипты используют временные токены (Azure Managed Identity), которые не идут в LLM-контекст. Для чувствительных операций — только ручное подтверждение.

Верификация безопасности: статический и динамический анализ

semgrep + bandit + gitleaks

Я интегрировал semgrep и bandit в пайплайн CI/CD для поиска паттернов утечек, CWE-уязвимостей и ошибок в логике авторизации. gitleaks — для контроля репозиториев на случайное попадание секретов в Git.

semgrep --config=auto src/
bandit -r src/
gitleaks detect --source .

Cloud security posture management

Проверяю конфигурацию агентов и сервисных пользователей через Azure Security Center и регулярные policy compliance-сканы (например, Azure Policy).

FAQ

Какой уровень доступа у ваших AI-агентов?

Только минимальный набор прав на конкретный ресурс или группу ресурсов. Нет общих ролей Owner/Contributor.

Передаёте ли вы логи в LLM как есть?

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

Как контролируется ротация секретов?

Через Doppler с автоматической ротацией и оповещениями. Доступны audit logs для всех операций с секретами.

Какой стек анализа кода используете?

semgrep для поиска паттернов, bandit для анализа Python, gitleaks для поиска утечек в репозиториях.

Агент может сам исправлять баги в инфраструктуре?

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

На каком этапе у вас чаще всего всплывают проблемы с безопасностью при запуске AI-агентов: статический анализ, runtime sandbox или ревью человеком? Я провожу бесплатный 30-мин аудит стека для основателей из DACH, кто строит AI в регулируемых отраслях. Пишите в LinkedIn или @ger_dennis_ai.