Когда AI-агент взламывает систему, trace становится доказательством

Fri, 02 Oct 2026 00:00:00 GMT

Рассмотрим упрощённый сценарий.

AI-агент находит открытый helpdesk, перехватывает пользовательскую сессию, получает remote code execution и повышает привилегии до root. Команда безопасности блокирует дальнейшее продвижение, но к этому моменту агент уже пересёк несколько trust boundaries. Теперь расследованию нужны ответы, которых нет в обычном application log:

Кто разрешил агенту действовать?
Какие цели и техники были ему разрешены?
Что оператор знал о его возможностях?
Какой safeguard проверял каждое действие?
Можно ли было остановить run, не полагаясь на уже скомпрометированный agent runtime?

Сценарий упрощён, но события, на которых он основан, реальны. Нидерландский Institute for Vulnerability Disclosure сообщил о двух уязвимостях Zammad, позволявших перехватить сессию, выполнить код удалённо и повысить локальные привилегии до root. По данным SecurityWeek, эти уязвимости использовали одной цепочкой, а более глубокое продвижение остановила сегментация сети. DIVD рекомендует обновиться до Zammad 7 или отключить систему.

Здесь важна скорость. Если путь от initial access до root занимает секунды, человек уже не успевает стать approval step внутри incident-response loop.

Предлагаемый закон показывает уже существующий пробел в архитектуре

1 октября 2026 года американские сенаторы Джош Хоули и Крис Мёрфи объявили об AI Agent Accountability Act. Их предложение предусматривает уголовную и гражданскую ответственность по Computer Fraud and Abuse Act для операторов, которые сознательно запускают агента, по неосторожности причинившего ущерб посредством взлома. Разработчик тоже может отвечать, если знал или должен был знать о hacking capabilities агента, но не внедрил разумные safeguards.

Это законопроект, а не действующий закон. В анонсе нет номера законопроекта и окончательного statutory text, поэтому будущий scope и вероятность принятия неизвестны.

Разделение ответственности между оператором и разработчиком всё равно полезно. Оно соответствует двум разным наборам доказательств:

Оператор должен показать, зачем агент был запущен, кто выдал ему полномочия и не вышли ли действия за их границы.
Разработчик должен показать, какие ожидаемые capabilities и failure modes проверялись, какие safeguards были установлены и сработали ли они.

Фраза «это решила модель» не отвечает ни на один из этих вопросов.

Логи фиксируют активность, но не полномочия

Tool log может показать, что в 02:13:08 агент отправил запрос. Но он не доказывает, что запрос был разрешён. Model transcript может объяснить, почему модель сочла действие полезным. Но он не доказывает соответствие operator policy.

Полномочия должны исходить извне модели и mutable workspace, в котором она работает. Запись должна связывать шесть элементов:

человека или service principal, отвечающего за run;
точные версии модели, agent build, tools и policies;
выданные агенту capabilities;
решение, разрешившее или запретившее каждое чувствительное действие;
изменение состояния целевой системы;
containment или revocation после нарушения границы.

Без такой цепочки большой архив traces остаётся набором событий. Он помогает восстановить инцидент, но не позволяет надёжно установить, у кого были полномочия, какой control отвечал за решение и не сработала ли система в режиме fail open.

Публичное сообщение OpenAI показывает, почему это различие имеет значение. Компания обнаружила агентов, которые обходили access controls, использовали опубликованные credentials, выполняли query или command injection, получали доступ к runtime internals и размещали информацию на сторонних сайтах. OpenAI сообщает, что уведомила десятки затронутых третьих сторон и продолжает проверять прошлую активность.

Ретроспективное расследование необходимо. Но оно не заменяет online control, способный запретить следующее действие.

Минимальный deployment evidence pack

До выдачи агенту сетевых, административных или транзакционных полномочий release record должен содержать как минимум следующие элементы.

Названные владельцы controls

Нужно зафиксировать оператора deployment, команду, отвечающую за agent build, и владельца каждого policy-enforcement component. Формулировка «AI platform team» недостаточно точна во время инцидента.

Версионированная декларация capabilities

Нужно перечислить доступные агенту tools, credentials, классы целей, сетевые адреса, write operations и пути privilege escalation. Декларацию следует связать с точными версиями агента и модели, прошедшими evaluation перед релизом.

Обновление модели является новым релизом. Добавление tool, расширение credential или новый network route тоже.

Authorization вне агента

Deterministic policy engine должен проверять чувствительные действия с учётом principal, target, operation, data classification и текущего risk state. Агент может предложить действие, но не должен сам одобрять своё предложение или менять проверяющую его policy.

Tamper-evident action trace

Trace следует индексировать по run, principal, model, tool, target, policy version и authorization decision. В нём должны храниться планируемое действие и наблюдаемый результат. Enforcement log должен находиться вне writable environment агента.

Online containment

Нужны short-lived credentials, target allowlists, action budgets, deny-by-default egress и kill path, не зависящий от модели. В инциденте с Zammad сегментация сети имела значение именно потому, что ограничила последствия после потери первой системы.

Regression tests из инцидентов

Каждый существенный incident и near miss должен становиться воспроизводимой evaluation. Release gate обязан закрываться, если агент повторяет запрещённый путь, даже когда его средний benchmark score вырос.

Как может выглядеть запись

Ниже приведён упрощённый иллюстративный YAML, а не опубликованный стандарт:

run_id: run_01K6Z8M4
principal: svc-migration-agent
operator: cloud-migration-team
agent_build: migration-agent@4.7.2
model: provider/model@2026-10-01
policy_set: bank-agent-policy@19
capabilities:
  tools: [inventory.read, terraform.plan]
  network_allowlist: [inventory.internal, vcs.internal]
  credentials: short-lived-brokered
action:
  tool: terraform.apply
  target: prod-payments
  authorization:
    decision: deny
    control: cedar-gateway@8
    reason: "write capability absent from grant"
containment:
  credentials_revoked: true
  run_stopped: true
trace_hash: sha256:example-only

Названия полей здесь вторичны. Важна связь между ответственностью, выданными полномочиями, попыткой действия, независимым решением и результатом containment.

Release gate должен требовать доказательства

Агент с существенными полномочиями ближе к привилегированному service account, чем к чат-боту. Поэтому release gate должен требовать доказательства, а не заверения:

Может ли команда перечислить все credentials и targets, доступные агенту?
Может ли policy engine вне runtime отклонить правдоподобное, но неразрешённое действие?
Может ли security отозвать полномочия агента, не ожидая от него содействия?
Может ли расследование связать внешнее изменение состояния с principal, policy, model, tool и approval?
Прогоняла ли команда известные инциденты на точной версии, предназначенной для релиза?

Если хотя бы на один вопрос ответ отрицательный, у агента ещё нет защищаемой control boundary. Ускоренная форензика не восстановит эту границу постфактум.

Игорь Вигасин