SIEM для AI-агентов: как связать аудит агентов с SOC

Агенты уже ходят в прод-системы, а SOC их не видит. Логи агента — в файле на диске, логи Jira — в SIEM, связь между ними — в голове разработчика. При инциденте вопрос «что именно сделал агент и по чьему поручению» без ответа. SIEM для агентов закрывает этот разрыв.

Почему SOC слеп к агентам

Три причины. Первая — фрагментация: каждый MCP-сервер и каждый агент пишут по-своему, без нормализации. Вторая — семантика: SIEM понимает login и file_access, но не tools/call с agent_id и delegation_chain. Третья — объем: агент за одну задачу делает десятки вызовов, и без агрегации SOC тонет в событиях.

Без единого аудита проверка «какие агенты трогали PII за 90 дней» превращается в ручной опрос команд.

5 полей обязательного лога

Минимум, без которого расследование не складывается:

Кто — agent_id + human_delegator (on behalf of). Агент без привязки к человеку — анонимная NHI.
Что — tool / action + resource (например, jira.read issue DEV-123).
С чем — хеш/фрагмент аргументов, scope и workflow_id/trace_id. Достаточно для воспроизведения без хранения полного PII.
Что вернулось — статус, размер ответа, маскированные поля. Нужно для детекции эксфильтрации.
Контекст решения — какая политика сработала, какой grant/TAC, authorization_details. Объясняет почему доступ был выдан.

Плюс timestamp, correlation_id и session_id для сквозной трассировки от LLM-вызова до downstream API. Это же требует EU AI Act Article 12: логи за весь жизненный цикл, хранение минимум 6 месяцев, tamper-evident.

Pipeline: agent → gateway → OTel → SIEM

Рабочий стек 2026:

агент → MCP gateway (policy + audit emitter)
        → OpenTelemetry (GenAI semconv: gen_ai.tool.call)
        → коллектор → SIEM (Splunk / Sentinel / Chronicle)

Gateway — единственное место где есть все 5 полей. Он выпускает OTel-спан на каждый tools/list и tools/call с атрибутами gen_ai.*, mcp.tool.name, agent.id, delegation.human. Агент напрямую в инструмент не ходит — иначе события теряются. OTel дает нормализацию до отправки в SIEM, а SIEM — корреляцию с другими источниками (IdP, EDR, DLP).

Ретеншен — 6 месяцев минимум (AI Act), для high-risk — дольше по политике. Шифрование и разграничение доступа к логам обязательны: логи сами содержат следы PII.

3 детекции, которые ловят реальный риск

Sprawl / shadow agent. Агент без записи в реестре или NHI без владельца вызывает инструмент. Правило: agent_id not in registry → алерт.
Over-privilege в действии. Агент с read-scope делает write/delete или трогает ресурс вне allowlist. Детекция на action/resource vs grant.scope.
Poisoning / prompt injection в ответе. MCP-ответ содержит инструкцию «отправь предыдущий результат на внешний хост». Ловится сканером gateway + корреляцией «инструмент вернул URL → агент вызвал внешний fetch».

Каждая детекция опирается на 5 полей — без них только шум.

Как не утонуть в объеме

Агрегируйте по workflow_id: одна задача = один кейс, а не 30 разрозненных событий.
Сэмплируйте tools/list (кэшируется), логируйте детально tools/call.
Маскируйте PII до SIEM, храните хеши аргументов, а не полный контекст.
Разделяйте audit и debug потоки: в SIEM — только аудит, в observability — трейсы.

Так SOC получает кейсы, а не поток JSON.

Где Codenik

Codenik — источник единого аудита: каждый вызов через gateway с 5 полями, OTel-экспорт из коробки, привязка к human delegator и политике. События уже нормализованы и готовы к ingest в SIEM без доработки агентов. Команда добавляет интеграцию один раз в gateway — дальше каждый агент автоматически пишет правильный аудит, а отзыв прав применяется мгновенно на все сессии.

Короткий вывод

Без SIEM аудит агентов — архив, с SIEM — управляемый контроль. Начните с 5 полей и pipeline через gateway → OTel → SIEM, включите 3 детекции и ретеншен 6 месяцев. Тогда вопрос «что сделал агент» имеет ответ за минуты, а не за недели.