Коротко: проект Shared AI Findings Exchange (SAFE) предлагает считать ИИ-агента полноценным участником инцидента: быстро остановить опасное действие, сохранить не только обычные логи, но и промпты, traces, tool calls, версии модели и guardrails, права, approvals и изменённые артефакты, затем разобрать отказ по восьми слоям. SAFE пока является проектом правил, а не законом или сертификатом, но его уже можно использовать как основу внутреннего playbook.
Статья предназначена для руководителей, CIO/CTO/CISO, владельцев процессов, SOC/IR и команд внедрения. Она объясняет проект SAFE по состоянию на 14 августа 2026 года и даёт операционный метод для одного агентного процесса. Она не заменяет юридическую оценку обязанностей по уведомлению, не задаёт универсальный срок хранения логов и не доказывает соответствие российским или зарубежным требованиям.
Содержание
- Что такое SAFE и почему о нём говорят сейчас
- Какие события SAFE предлагает считать отчётными
- Как работает календарь уведомлений
- Какие доказательства нужно сохранить
- Почему обычного лога приложения недостаточно
- ЖУРНАЛ как провести разбор инцидента
- Минимальная карточка инцидента ИИ-агента
- Как провести учение до первого реального сбоя
- Метрики и правила остановки
- Ограничения SAFE и открытые вопросы
- Частые вопросы
- Как AI рассвет помогает подготовить агентный контур к инцидентам
- Вывод
Что такое SAFE и почему о нём говорят сейчас
SAFE, или Shared AI Findings Exchange, — это проект независимого механизма, который должен конфиденциально собирать инциденты и near misses с ИИ, предупреждать затронутые стороны и превращать повторяющиеся отказы в проверяемые защитные меры. 13 августа 2026 года репозиторий предложения был обновлён; обсуждение остаётся открытым Request for Comments.
Первичный текст RFC размещён Open Secure AI Alliance. В рабочую группу входят представители NVIDIA, Cisco, CrowdStrike, Hugging Face и Red Hat, а Linux Foundation поддерживает процесс обсуждения. NVIDIA сообщает, что альянс объединяет более 120 организаций.
Важно не превратить новость в ложную норму. SAFE пока не является:
- законом или обязательным международным стандартом;
- сертификатом безопасности конкретной модели или агента;
- заменой договорных, регуляторных и отраслевых обязанностей;
- гарантией иммунитета от претензий после добровольного раскрытия;
- доказательством, что участник альянса безопаснее неучастника.
На 11 августа Axios отдельно отмечал отсутствие формальной защиты safe harbor для добровольных раскрытий. Поэтому компаниям нужен не только технический playbook, но и заранее согласованный маршрут через ИБ, владельца процесса, юристов, privacy и коммуникации.
Новость важна по другой причине: она задаёт конкретный минимальный предмет расследования. Инцидент с агентом — это не просто «модель ответила неправильно». Агент может читать данные, использовать идентичность, вызывать инструменты, изменять файлы, публиковать, платить и взаимодействовать с другими агентами. Значит, расследовать нужно всю цепочку действия.
Какие события SAFE предлагает считать отчётными
SAFE предлагает сообщать об инциденте, когда оператор знает или обоснованно подозревает хотя бы одно из четырёх состояний.
| Событие | Практический пример | Почему нельзя ждать подтверждённого ущерба |
|---|---|---|
| Несанкционированный доступ, эксплуатация, нарушение или изменение сторонней системы | агент проверил «тестовый» хост, который оказался production | намерение оператора не меняет факта внешнего воздействия |
| Выход за sandbox, сеть, identity, policy или tool boundary | процесс получил путь наружу через ошибочную конфигурацию прокси | граница уже не выполняет свою защитную функцию |
| Доступ к конфиденциальным данным третьей стороны без согласия | tool call вернул чужую карточку клиента или секрет | копирование и перераспределение могут расширить ущерб |
| Продолжение probing после появления подозрения о неверной цели | агент повторяет запросы, хотя scope больше не подтверждён | после сигнала неопределённости бездействие оператора становится частью инцидента |
Near miss — это ситуация, в которой защитный слой остановил опасную цепочку до подтверждённого ущерба. SAFE предлагает сохранять и такие случаи. Они показывают слабый контроль раньше, чем возникнет пострадавшая сторона.
Это полезно для российской компании даже без членства в SAFE: внутренний порог «открываем инцидент только после утечки» слишком поздний. Рабочий порог — потеря уверенности в scope, идентичности, разрешении или возможности остановить действие.
Свежий пример показывает цену неверной атрибуции: в материале AI рассвет об атаке ИИ-агента на Минфин Таиланда отдельно разбирается, почему важно установить точный агент и не строить реакцию на ошибочном названии системы.
Как работает календарь уведомлений
SAFE предлагает следующий календарь. Это проектный compact для участников, а не универсальные юридические сроки.
| Срок SAFE | Предлагаемое действие | Внутренний владелец |
|---|---|---|
| ASAP | уведомить непосредственно затронутую организацию | incident commander и security liaison |
| 72 часа | уведомить клиентов с достоверным риском воздействия | ИБ, privacy, legal и account owner |
| 4 рабочих дня | подать первичный конфиденциальный отчёт SAFE | владелец assurance/reporting |
| 14 дней | выпустить более широкое уведомление клиентам, если это оправдано | legal, communications и business owner |
| 30 дней | опубликовать предварительный фактический отчёт с учётом риска эксплуатации и следствия | postmortem owner и legal |
| 90 дней | опубликовать статус исправлений | control owner |
| Еженедельно | давать машиночитаемые обновления, пока материальный риск не закрыт | incident program owner |
RFC прямо говорит, что эти сроки не отменяют coordinated vulnerability disclosure, договоры, уведомление регуляторов или правоохранительных органов. Публикацию можно ограничить, если она создаст немедленный exploit risk или помешает расследованию, но затронутой организации всё равно нужен быстрый сигнал.
Практический вывод: заранее составьте матрицу часов. Для каждого класса данных и действия укажите, кто запускает отсчёт, кто имеет право остановить агента, кто определяет credible exposure и кто согласует внешнее сообщение. Если эти роли ищут после инцидента, календарь уже потерян.
Какие доказательства нужно сохранить
Обычный SIEM может видеть сетевой запрос или процесс, но не всегда объясняет, почему агент выбрал действие. SAFE требует сохранить причинную цепочку.
| Группа доказательств | Что фиксировать | Зачем |
|---|---|---|
| Ввод и рассуждение | промпты, traces, контекст, найденные документы | восстановить информацию, на которой строилось решение |
| Исполнение | tool calls, аргументы, ответы инструментов, exit codes | отделить ошибку модели от ошибки инструмента или API |
| Версии | модель, system instruction, guardrails, конфигурация, зависимости | воспроизвести точный программный контур |
| Идентичность и права | agent/workload ID, роли, токены, доступные permissions | понять, почему действие технически стало возможным |
| Человеческий контроль | approvals, отклонения, ручные вмешательства, override | проверить, где был или отсутствовал контроль человека |
| Изменённые артефакты | файлы, записи, сообщения, публикации, внешние объекты | определить фактический радиус и путь отката |
| Реакция | detection, containment, recovery и kill events | измерить скорость обнаружения и остановки |
| Проверка исправления | timeline, reproduction, regression и remediation evidence | доказать, что причина устранена, а не замаскирована |
Логирование само создаёт риск. В prompts и tool outputs могут быть персональные данные, коммерческие тайны и секреты. Поэтому нужны маскирование, отдельное защищённое хранилище, контроль доступа, срок хранения и неизменяемые метки времени. «Записать всё навсегда» не является безопасной политикой.
MITRE ATLAS Incident Sharing использует защищённый и обезличенный обмен и опирается на STIX как схему данных. Это подтверждает общий вектор к машиночитаемым отчётам, но не означает, что STIX уже покрывает каждую агентную trace или approval-событие.
Почему обычного лога приложения недостаточно
SAFE предлагает проверять восемь слоёв. Один и тот же внешний запрос может быть следствием разных причин и требовать разных исправлений.
| Слой | Контрольный вопрос | Возможная причина |
|---|---|---|
| Model | распознала ли модель неопределённость, scope и stop condition | модель уверенно продолжила при конфликтующих признаках |
| Instructions | были ли разрешение и предположения о среде явными | инструкция назвала среду тестовой без независимой проверки |
| Safeguards | работали ли classifiers, policies, approvals и action limits | guardrail проверял текст, но не network target |
| Tools | были ли credentials, расходы, публикация и execution ограничены | инструмент получил общий токен вместо scoped credential |
| Environment | были ли сеть, isolation, targets и данные проверены отдельно | sandbox имел неожиданный маршрут в production |
| Monitoring | можно ли было обнаружить и прервать действие в реальном времени | alert пришёл после завершения цепочки |
| Human operations | были ли роли, эскалация и kill procedure понятны | команда спорила, кто вправе остановить задачу |
| Supply chain | нарушил ли партнёр, облако, evaluator или dataset предположения | сторонняя тестовая среда была неверно подключена |
Microsoft Research тестировала внутреннюю сеть из более чем 100 агентов и выделила четыре сетевых риска: propagation, amplification, trust capture и invisibility. Это показывает, почему локальный лог одного агента не всегда восстанавливает источник и путь воздействия. Нужны cross-agent tracing, provenance и сетевые границы.
Сингапурский AI Agents Sandbox длился около четырёх месяцев и охватил три сценария. В выводах отдельно названы human oversight, control, cybersecurity и privacy, включая indirect prompt injection. Это не универсальный benchmark, но хороший пример оценки развёрнутой системы, а не одной модели.
ЖУРНАЛ как провести разбор инцидента
Предлагаем рабочую рамку ЖУРНАЛ. Это оригинальная операционная синтезация AI рассвет на основе SAFE, NIST, Microsoft Research, MITRE ATLAS и практик incident response; это не официальный термин альянса.
Жёстко остановить опасное действие
Заморозьте новые tool calls, отзовите сессионные credentials и сохраните состояние до очистки. Не удаляйте контейнер, память или временные файлы, пока не создан форензический снимок. Если действие обратимо, остановка важнее автоматического «исправления» тем же агентом.
Установить границы и радиус
Зафиксируйте исходную задачу, допустимый target, фактические targets, затронутые данные, внешние системы и окно времени. Отделите подтверждённый факт от гипотезы. Название модели или агента не должно подменять идентификатор workload и версию.
Резервировать доказательства
Соберите evidence package из таблицы выше, проставьте единое время, хеши и владельца custody. Секреты ротируются после безопасного сохранения минимально необходимого доказательства. Доступ к пакету отделяют от обычной observability.
Назначить уведомления и владельцев
Активируйте матрицу часов: affected party, клиенты, поставщики, регуляторные и договорные каналы. В сообщении разделите факт, возможный риск, containment и следующий срок обновления. Не ждите идеальной root cause, чтобы предупредить непосредственно затронутую сторону.
Анализировать весь стек
Пройдите восемь слоёв SAFE. Ищите первый контроль, после которого цепочка стала необратимой или вышла за scope. Не завершайте разбор формулировкой «LLM галлюцинировала»: она не объясняет, почему галлюцинация получила credential, маршрут и право на действие.
Локализовать и проверить исправление
Назначьте control owner, минимальный defensive outcome, приемлемые альтернативы, воспроизводимый тест и deadline. Перезапустите frozen incident, near miss и соседние сценарии. Возвращать автономность можно только после доказательства, что опасная цепочка больше не проходит.
Минимальная карточка инцидента ИИ-агента
Карточка должна быть пригодна и для человека, и для последующего машинного обмена.
| Поле | Пример значения | Правило |
|---|---|---|
| incident_id | AGENT-2026-0042 | неизменяемый уникальный ID |
| detected_at / contained_at | RFC 3339 timestamps | одна временная шкала и часовой пояс |
| task_scope | allowed targets and prohibited actions | явно, а не «проверить систему» |
| agent_identity | workload ID, owner, tenant | не только бренд модели |
| version_set | model, prompt, harness, tools, policies | хеши или точные версии |
| observed_action | tool, arguments, target, result | факт без интерпретации |
| authorization_state | allowed, denied, ambiguous | кто и на каком основании разрешил |
| affected_parties | systems, data owners, customers | с уровнем уверенности |
| containment | revoked token, blocked egress, stopped job | время и исполнитель |
| evidence_refs | immutable log and artifact pointers | без секретов в самой карточке |
| control_failure | layer, first unrecoverable step | версия гипотезы и уверенность |
| remediation_test | reproducible test and expected result | критерий закрытия |
Храните отдельно фактическую timeline и аналитические выводы. Гипотеза может измениться; исходные события — нет. Для многоагентной системы добавьте parent/child trace IDs и цепочку передачи данных между агентами.
Как провести учение до первого реального сбоя
- Выберите один процесс, где агент имеет хотя бы право чтения или создания черновика.
- Заморозьте версии модели, инструкции, harness, tools, policies и credentials.
- Подготовьте сценарий near miss: неизвестный target, запрос лишнего права или indirect prompt injection.
- Запустите его в изолированной среде без внешнего ущерба.
- Проверьте, может ли дежурный остановить цепочку одним понятным действием.
- Соберите карточку и evidence package без обращения к памяти участников.
- Проведите восьмислойный разбор и назначьте одно проверяемое исправление.
- Повторите сценарий и убедитесь, что контроль срабатывает до опасного tool call.
NIST TRA 800-5 суммирует отраслевые ответы: базовые практики кибербезопасности остаются актуальны, но их нужно адаптировать для агентных систем; среди ожидаемых ролей государства участники называют guidance, information sharing и standards. Это поддерживает идею учений и общего языка, но не сертифицирует конкретный playbook.
Для профилактического контура отдельно полезны материалы AI рассвет о безопасности AI-чата и о том, почему локальный ИИ-агент не равен безопасному. Текущий материал начинается там, где preventive control уже дал сигнал или отказал.
Метрики и правила остановки
| Метрика | Формула | Что показывает |
|---|---|---|
| Mean time to contain | contained_at минус detected_at | скорость остановки опасной цепочки |
| Evidence completeness | заполненные обязательные поля / все обязательные поля | можно ли воспроизвести инцидент |
| Unknown target rate | tool calls с неподтверждённой целью / все внешние calls | качество проверки scope |
| Unauthorized action rate | запрещённые calls / все calls | прочность policy boundary |
| Near-miss reporting ratio | зарегистрированные near misses / все agent events с stop signal | видит ли команда предупреждения до ущерба |
| Remediation recurrence | повторные инциденты того же control failure / закрытые исправления | устраняется ли причина, а не симптом |
| Approval latency | медиана времени от запроса до решения | не превращает ли контроль человека процесс в обходную практику |
Первые численные пороги компания задаёт на собственном baseline. В статье нет универсального «хорошего» MTTC или допустимой доли инцидентов.
Безусловные stop rules разумно определить заранее:
- target не входит в подписанный allowlist или его идентичность не подтверждена;
- агент просит новое право, credential или сетевой маршрут во время задачи;
- логирование версии, tool call или approval недоступно;
- post-action diff нельзя построить или операция необратима;
- появилась третья сторона, не указанная в scope;
- оператор не может объяснить, как немедленно остановить цепочку.
Ограничения SAFE и открытые вопросы
| Ограничение | Практическое следствие |
|---|---|
| SAFE остаётся RFC | формулировки, сроки и механизм членства могут измениться |
| Нет универсального safe harbor | раскрытие нужно согласовывать с legal и применимым режимом |
| Общая схема обмена ещё развивается | внутренний формат должен поддерживать экспорт, но не зависеть от одного проекта |
| Публичность может увеличить exploit risk | disclosure отделяют от немедленного уведомления affected party |
| Логи содержат чувствительные данные | evidence preservation требует privacy, доступа, retention и redaction |
| Не каждый сбой является киберинцидентом | таксономия должна различать security, privacy, safety, quality и operations |
| Участие 120+ организаций заявлено альянсом | это vendor-reported membership, а не независимая оценка зрелости |
Самая важная неопределённость — кто станет доверенным оператором обмена, как будет работать деидентификация и каким станет минимальный машиночитаемый формат. До ответа на эти вопросы компания может подготовить собственные доказательства и процесс, но не должна обещать совместимость с окончательной версией SAFE.
Частые вопросы
Что считать инцидентом с ИИ-агентом
Это событие, в котором агент или его окружение нарушили либо могли нарушить согласованный scope, права, данные или внешнюю систему. Для внутреннего расследования достаточно обоснованного подозрения или near miss; ждать подтверждённого ущерба не нужно.
Какие логи нужны для расследования ИИ-агента
Нужны prompts и traces, tool calls и ответы, версии модели и инструкций, guardrails, идентичность, права, credentials, approvals, изменённые артефакты, события detection/containment/recovery, timeline и доказательство исправления. Секреты и персональные данные защищают отдельно.
SAFE уже обязателен для компаний
Нет. По состоянию на 14 августа 2026 года SAFE опубликован как Request for Comments и предлагаемый compact Open Secure AI Alliance. Он не заменяет закон, договор или отраслевое требование.
Нужно ли сообщать о near miss без ущерба
SAFE предлагает сообщать и о близких к инциденту событиях. Внутри компании это полезно: near miss показывает, что контроль оказался последней преградой, и позволяет исправить систему до реального воздействия.
Можно ли расследовать инцидент только по SIEM
Обычно нет. SIEM помогает увидеть процессы и сеть, но агентный разбор требует связать задачу, контекст, tool calls, идентичность, approvals, версии, изменения и путь между агентами. Без этой причинной цепочки root cause остаётся неполной.
Когда можно вернуть агенту автономность
После containment, полного evidence package, установленного control failure и воспроизводимого regression test. Исправление должно блокировать опасную цепочку до внешнего действия, а права возвращаются поэтапно.
Как AI рассвет помогает подготовить агентный контур к инцидентам
AI рассвет может помочь встроить расследуемость в агентный процесс до промышленного запуска:
- Провести аудит одного процесса, его baseline, данных, инструментов, прав, владельцев и критериев приёмки.
- Спроектировать ИИ-агента или agentic RPA с ограниченными интеграциями, approvals, trace IDs и журналом действий.
- Подготовить тесты обычных, редких и атакующих сценариев, stop rules, rollback и tabletop-разбор.
- Выполнить интеграцию, тестирование, запуск, обучение команды и сопровождение изменений.
Безопасный первый шаг — выбрать один процесс, зафиксировать его текущий baseline, источники данных, ограничения и критерий приёмки. Затем проверить, сможет ли команда воспроизвести и остановить одну тестовую опасную цепочку.
Вывод
SAFE важен не как ещё один знак «безопасного ИИ», а как переход от общих обещаний к доказательствам: что делал агент, под какой идентичностью, с какими правами, кто подтвердил действие, где нарушилась граница и каким тестом подтверждено исправление.
Компания готова к инциденту с ИИ-агентом, если может быстро остановить цепочку, восстановить её без догадок, предупредить затронутых людей и системы, назначить владельца контроля и доказать, что тот же путь больше не проходит. Если хотя бы один из этих шагов зависит от памяти разработчика, агент ещё не готов к автономной работе.