AI-агент получил доступ к прод-среде? Как построить replayable security triage и доказуемый audit trail до первого инцидента

Я — Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany; в DennisCraft AI Studio я строю продовые AI-системы для DACH B2B на стеке Claude, Supabase, n8n, Doppler и self-hosted Postgres. Самый неприятный момент начинается не тогда, когда AI-агент пишет код, а когда он впервые получает право менять что-то в production: таблицу, workflow, секрет, ACL или внешний API-вызов с деньгами и юридическими последствиями.

Если в этот момент у вас нет replayable security triage и доказуемого audit trail, вы уже проигрываете. Не потому что инцидент точно случится сегодня, а потому что после первого спорного действия вы не сможете ответить на 4 вопроса: что агент увидел, что решил, чем это обосновал и почему система это пропустила.

Что именно нужно фиксировать до первого инцидента

Большая ошибка — логировать только итоговое действие: “agent updated record” или “workflow executed”. Для расследования этого недостаточно. Нужна воспроизводимая цепочка решения. Я обычно закладываю 5 обязательных артефактов на каждое чувствительное действие.

1. Входной контекст

Какие данные получил агент: prompt, tool input, user id, tenant id, selected records, feature flags, policy version. Без этого невозможно понять, была ли ошибка в модели, в retrieval, в orchestration или в правах.

2. Версия политики

Не просто “policy passed”, а конкретная версия правил: semgrep config commit, allowlist tool scopes, regex для детекции секретов, SQL guardrails. Через 3 недели после релиза у вас уже другая кодовая база. Без version pinning replay развалится.

3. Решение и основание

Я не храню “chain of thought”, но храню структурированное объяснение уровня decision record: requested_action, risk_class, blocked_by, allowed_by, requires_human_review. Этого достаточно для аудита и не создает лишних юридических рисков.

4. След результата

Что реально произошло: SQL query, HTTP request, rows affected, response code, rollback status, duration. Если агент инициировал n8n workflow, в логе должен быть execution id и snapshot payload.

5. Возможность replay

Replayable triage означает, что вы можете взять событие недельной давности и прогнать его через ту же policy-цепочку в sandbox. Не “примерно восстановить”, а повторить решение на тех же входах и версиях правил.

Replayable triage — это не SIEM, а дисциплина вокруг действий агента

OWASP в OWASP Top 10 for LLM Applications 2025 отдельно выделяет Excessive Agency и Insecure Output Handling как практические риски для систем, где модель не просто отвечает, а действует: https://genai.owasp.org/. Для меня это хороший якорь: проблема не в “опасном ИИ” как абстракции, а в том, что система получила возможность менять внешний мир.

Поэтому triage стоит строить как конвейер решений, а не как набор логов.

Ключевая мысль: triage должен завершаться не только статусом allow/deny, но и материалом для повторной проверки. Иначе после инцидента вы снова будете читать сырые JSON-логи и спорить, “что агент имел в виду”.

Минимальная архитектура для доказуемого audit trail

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

create table agent_audit_events (
  id uuid primary key,
  created_at timestamptz not null default now(),
  tenant_id text not null,
  actor_type text not null,
  actor_id text not null,
  action_name text not null,
  input_hash text not null,
  policy_version text not null,
  risk_class text not null,
  decision text not null,
  requires_review boolean not null default false,
  execution_ref text,
  payload jsonb not null,
  outcome jsonb
);

Почему input_hash, если payload уже есть? Потому что hash дает быстрый способ проверить неизменность события и связывать replay с исходным входом. Payload можно шифровать или редактировать, но hash должен остаться.

Пример записи события до выполнения действия

import hashlib
import json
import uuid
from datetime import datetime, timezone

def build_audit_event(tenant_id, actor_id, action_name, payload, policy_version):
    raw = json.dumps(payload, sort_keys=True).encode()
    return {
        "id": str(uuid.uuid4()),
        "created_at": datetime.now(timezone.utc).isoformat(),
        "tenant_id": tenant_id,
        "actor_type": "ai_agent",
        "actor_id": actor_id,
        "action_name": action_name,
        "input_hash": hashlib.sha256(raw).hexdigest(),
        "policy_version": policy_version,
        "risk_class": "high",
        "decision": "pending",
        "payload": payload
    }

Этот объект должен появиться до фактического вызова инструмента. Если запись события идет после исполнения, у вас уже есть окно, где агент успел что-то сделать без нормального следа.

Как я строю triage вокруг реальных рисков, а не вокруг “умного prompt”

Самая опасная иллюзия — думать, что проблему решит хороший system prompt. Prompt может снизить частоту плохих решений, но не заменяет policy enforcement. Anthropic в документации по tool use прямо рекомендует ограничивать инструменты, валидировать входы и строить human-in-the-loop для чувствительных операций: https://docs.anthropic.com/.

Ступень 1: статическая проверка артефактов

Если агент генерирует код, SQL или конфиг, я сначала прогоняю это через semgrep, bandit и gitleaks. Это не “безопасность ради галочки”, а способ поймать повторяемые ошибки до исполнения.

#!/usr/bin/env bash
set -euo pipefail

tmp_dir="${1:-./candidate}"
semgrep --config=p/owasp-top-ten "$tmp_dir"
bandit -r "$tmp_dir" -f txt
gitleaks dir "$tmp_dir" --no-banner

echo "static checks passed"

Ступень 2: policy-gated tool execution

Каждый tool call проходит через policy layer. Я разделяю read, write и external side effects. Для read-операций допустимы автоматические действия в рамках tenant scope. Для write и денежных API почти всегда нужен дополнительный review или очень узкая allowlist.

Ступень 3: post-action verification

После выполнения я проверяю инварианты: сколько строк изменено, не ушел ли запрос вне tenant scope, совпадает ли тип ресурса с разрешенным, нет ли аномального объема данных. Иногда именно здесь всплывает проблема orchestration, а не модели.

Где чаще всего ломаются команды

Я вижу 4 типовых провала в агентных системах для regulated markets.

Последний пункт недооценен. Заблокированные попытки часто полезнее успешных: они показывают, где агент системно хочет выйти за допустимую границу.

FAQ

Нужно ли хранить весь prompt целиком?

Не всегда. Если в prompt есть чувствительные данные, храните редактированную версию плюс hash оригинала и отдельно структурированные поля контекста. Для replay этого обычно хватает.

Можно ли сделать audit trail только на уровне n8n?

Частично, но этого мало. n8n даст execution history, однако policy decision, input hashing и business-level risk classification лучше держать в отдельной модели данных, обычно в Postgres.

Human review обязателен для каждого write?

Нет. Для низкорисковых операций в узком scope можно работать автоматически. Но удаление данных, изменение прав, платежные действия и cross-tenant доступ я бы не отдавал агенту без дополнительного контроля.

Чем replay отличается от обычного логирования?

Логирование отвечает на вопрос “что случилось”. Replay отвечает на вопрос “повторится ли то же решение при тех же входах и тех же правилах”. Для расследования это разница между догадкой и доказательством.

Это нужно только большим компаниям?

Нет. Маленькая команда с 1 продовым агентом страдает даже сильнее, потому что у нее меньше времени на ручное расследование и меньше права на ошибку перед первым enterprise-клиентом.

Если ваш AI-агент уже читает или меняет production, на каком этапе вы сейчас поймаете спорное действие: на статической проверке, в runtime policy layer или только после жалобы клиента? Я правда хочу это понять.
I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.