Agentic SAMM: аудит ИИ-агентов в разработке и что проверить на этой неделе
Сергей Гордейчик, известный специалист по безопасности промышленных систем и автор ряда открытых фреймворков, представил на конференции ISC.AI 2026 в Пекине расширенную версию доклада, которая вышла на Habr. Ключевая мысль: тридцать лет вся безопасность разработки строилась на допущении, что действующее лицо — человек. Это допущение больше не работает. В продакшене появляются агенты, которые пишут код, тестируют его, модифицируют собственную архитектуру и даже ставят себе следующие задачи. Для бизнеса это означает, что привычные методы контроля безопасной разработки — code review, статический анализ, регламенты — перестают покрывать реальные риски. Решение, которое предлагает автор, — открытый фреймворк Agentic SAMM и инструмент аудита агентов. В этой статье — что конкретно меняется, какие границы контроля нужно перерисовать и что можно сделать уже на этой неделе.
Что произошло: открытый фреймворк для новой реальности
Сергей Гордейчик опубликовал на Habr расширенную версию своего доклада с ISC.AI 2026. В ней он формулирует проблему, которая уже не гипотетическая: агентные системы начинают выполнять работу разработчика, и существующие механизмы безопасности на это не рассчитаны. Вместе с докладом автор выложил два открытых репозитория на GitHub:
- ASAMM Framework — фреймворк для оценки и управления безопасностью разработки в условиях, когда часть работы выполняют ИИ-агенты.
- Agent-Audit Tool — инструмент для аудита поведения агентов, который фиксирует их действия, решения и изменения.
Оба репозитория открыты. Автор прямо приглашает: «берите, ломайте и присылайте мне, что найдёте». Это не академическая публикация и не коммерческий продукт — это рабочий инструмент, который можно начать использовать уже сейчас.
Главная идея фреймворка — не в том, чтобы добавить ещё один слой проверок. Она в том, чтобы пересмотреть саму границу, на которой контроль даёт сбой. Гордейчик формулирует это так: «Контроль отказывает на границе, которую вы забыли смоделировать. Не на границе, которую плохо защитили. На границе, которую вообще не нарисовали».
Почему это меняет стоимость и риски разработки
Для бизнеса последствия прямые. Если раньше безопасность разработки строилась на предположении, что код пишет человек, который может ошибиться, но действует в рамках заданных правил, то теперь часть работы выполняет агент, который может менять собственный код, инструменты и даже цели. Это создаёт три конкретных бизнес-риска:
- Непредсказуемое поведение агента. Агент, который улучшает себя, может принять решение, которое не предусмотрено ни одним регламентом. Например, изменить способ обработки данных или подключить внешний инструмент без согласования. Стоимость такого инцидента — не только утечка данных, но и потеря контроля над процессом разработки.
- Слепые зоны в аудите. Стандартные средства аудита фиксируют, что было изменено в коде, но не фиксируют, почему агент принял такое решение. Гордейчик в своём эксперименте обнаружил, что самым ценным артефактом стала не программа, а поведенческая трасса: что агент видел, что решил, что вызвал, что изменил и что тихо сохранил. Без такой трассы восстановить цепочку решений невозможно.
- Размытие ответственности. Если код написан агентом, кто отвечает за его безопасность? Разработчик, который запустил агента? Команда, которая настроила его? Или сам агент? Юридически этот вопрос пока не решён, но бизнесу нужно готовиться к тому, что привычные модели ответственности перестанут работать.
В таблице ниже — основные изменения и что с ними делать.
| Что меняется | Почему важно бизнесу | Что проверить |
|---|---|---|
| Агент может модифицировать собственный код и инструменты | Потеря контроля над процессом разработки, непредсказуемые изменения | Внедрить обязательную фиксацию поведенческой трассы агента |
| Стандартные средства аудита не фиксируют решения агента | Невозможность расследовать инциденты и восстановить цепочку событий | Использовать Agent-Audit Tool или аналоги для сбора трасс |
| Размытие ответственности между человеком и агентом | Юридические риски, сложности с комплаенсом | Пересмотреть политики безопасности и распределение ответственности |
| Агент может самостоятельно ставить себе задачи | Риск выполнения действий, не предусмотренных бизнес-процессом | Ограничить область действий агента и настроить мониторинг отклонений |
Что проверить в своей компании до внедрения агентов
Прежде чем запускать агентные системы в разработку, нужно убедиться, что базовые механизмы контроля настроены на новую реальность. Вот пять проверок, которые можно провести уже на этой неделе.
Чек-лист для не-IT-руководителя:
- Есть ли у вас политика использования ИИ-агентов в разработке? Если нет — начните с неё. В политике должно быть чётко указано, какие действия агента разрешены, а какие требуют согласования с человеком.
- Фиксируете ли вы поведенческую трассу агента? Если вы используете агентов, но не знаете, какие решения они принимали и почему, — вы в зоне риска. Убедитесь, что у вас есть инструмент для сбора и анализа таких трасс.
- Кто отвечает за действия агента? Определите, кто из команды несёт ответственность за настройку, мониторинг и результаты работы агента. Без этого любой инцидент станет предметом спора.
- Есть ли у вас механизм отката изменений, внесённых агентом? Агент может изменить код, конфигурацию или инфраструктуру. Убедитесь, что вы можете быстро вернуть систему в предыдущее состояние.
- Проверяли ли вы границы, которые считаете изолированными? Гордейчик подчёркивает: контроль ломается на границе, которую вы забыли смоделировать. Проверьте, не считаете ли вы какой-то ввод или действие доверенным без оснований.
Что может пойти не так: неочевидные риски
Даже если вы внедрите все рекомендованные меры, остаются риски, которые сложно предвидеть. Гордейчик в своём докладе упоминает несколько проектов, которые показывают, как далеко могут зайти самоулучшающиеся агенты:
- STOP — самообучающиеся оптимизаторы, которые могут менять способ решения задач.
- ADAS — агенты, проектирующие другие агентные системы.
- Darwin-Gödel Machine — открытые системы, которые со временем переписывают собственный код, память и цели.
Автор называет их «уроборос-подобными» — они замыкают петлю: агент модифицирует себя, тестирует, откатывает неудачное, сохраняет удачное и сам пишет себе следующую задачу. И повторяет. Снова и снова.
Для бизнеса это означает, что даже если вы настроили контроль на старте, агент может изменить своё поведение так, что контроль перестанет работать. Это не гипотетический сценарий — это уже происходит в экспериментальных проектах. Пока такие системы сыры и не встречаются повсеместно, но граница между «инструментом» и «разработчиком» уже размывается.
Ещё один неочевидный риск — поведенческая трасса как артефакт. Гордейчик в своём эксперименте обнаружил, что самым ценным был не код, а журнал решений агента. Но методы анализа и верификации таких трасс пока не стандартизированы. Если вы начнёте собирать трассы сегодня, вы сможете расследовать инциденты, но не сможете гарантировать, что трасса полна и не была изменена самим агентом.
Что делать на этой неделе: практические шаги
На основе доклада Гордейчика и открытых репозиториев можно составить план действий, который не требует глубоких технических знаний.
Шаг 1. Ознакомьтесь с фреймворком ASAMM. Перейдите в репозиторий на GitHub и прочитайте описание. Фреймворк не требует установки — это набор принципов и метрик для оценки безопасности разработки с участием агентов. Даже если вы не планируете внедрять его полностью, понимание логики поможет пересмотреть свои политики.
Шаг 2. Проверьте, используете ли вы агентов, которые могут модифицировать себя. Если ваши разработчики используют ИИ-инструменты, которые пишут код, уточните, могут ли эти инструменты менять собственную конфигурацию или подключать внешние ресурсы. Если да — это уже зона риска.
Шаг 3. Настройте сбор поведенческих трасс. Инструмент Agent-Audit Tool от Гордейчика — открытый и готов к использованию. Даже если вы не будете внедрять его в production, запустите тестовый эксперимент: дайте агенту задачу, соберите трассу и посмотрите, какие решения он принимал. Это даст понимание, какие данные вам нужно фиксировать.
Шаг 4. Пересмотрите политики безопасности. Добавьте в них раздел об ИИ-агентах: какие действия разрешены, какие требуют согласования, кто несёт ответственность. Убедитесь, что политики учитывают возможность самоизменения агента.
Шаг 5. Обсудите с командой границы контроля. Проведите встречу, на которой вы вместе нарисуете карту: где в вашем процессе разработки появляются агенты, какие границы они пересекают, какие вводы считаются доверенными. Это поможет выявить слепые зоны до того, как они приведут к инциденту.
