21 мая 2026 года Dark Reading выпустил материал о том, почему привычный AI BOM уже не справляется с новой реальностью: если система не просто отвечает на запросы, а сама ходит по API, вызывает инструменты и принимает решения, одного списка моделей и датасетов мало. Для русскоязычной IT-аудитории это довольно приземлённая новость: как только в компании появляется ИИ-агент с доступом к продакшену, вопрос «что у нас внутри» быстро превращается в вопрос «что именно эта штука может натворить».
Как пишет Dark Reading, классический AI BOM задумывался по аналогии с SBOM: перечислить, из каких компонентов собрана AI-система. В такой перечень обычно входят модели, наборы данных, фреймворки и зависимости. Это полезно для контроля цепочки поставок и реакции на уязвимости, когда нужно быстро понять, где используется скомпрометированный компонент. Но с агентными системами проблема уже не только в составе. Здесь важна ещё и исполнимая часть: где агент работает, к чему подключён, какие действия ему разрешены и кто вообще решил, что эти действия допустимы.
Именно на эту границу указывает Крити Таллам, VP of AI в Kamiwaza AI и участница работы над NIST AI Risk Management Framework. По её словам, для систем с делегированной автономией главный объект интереса безопасности смещается с пары «модель плюс данные» к «маршрутам действий». То есть документировать приходится не только артефакты сборки, но и поведенческие сущности: навыки инструмента, промпты, политики и описания workflow. Для CISO это неприятный, но здоровый сдвиг. Раньше можно было спорить о происхождении модели, теперь придётся разговаривать ещё и о том, почему агент получил право удалить ресурс, переслать данные или выполнить цепочку вызовов без ручного подтверждения.
Проблема уже не в составе, а в полномочиях
В материале отдельно разбирается разрыв между тем, что умеют нынешние стандарты, и тем, что требуется для агентных систем. CycloneDX и SPDX, на которые сейчас опираются инициативы вокруг AI BOM, хорошо описывают происхождение артефактов: какие компоненты вошли в систему, откуда они взялись, не тянут ли за собой известные уязвимости. Но этого недостаточно, когда система начинает действовать в рантайме. Хелен Окли, одна из руководителей OWASP AIBOM Generator, предлагает смотреть на документацию в двух плоскостях: artifact lineage и authority lineage. Первая отвечает за родословную компонентов, вторая — за то, как в работающей системе передаются права на принятие решений.
На практике это означает довольно простую мысль, от которой многим командам станет неуютно: без дополнительных полей и телеметрии AI BOM не может объяснить, какой агент вызвал какой инструмент, с какими делегированными правами и вышла ли эта цепочка за исходно заданные границы. Иначе говоря, можно идеально понимать, из чего собрана система, и при этом не понимать, почему она только что полезла не туда. Окли формулирует это жёстко: целостность артефактов сама по себе не гарантирует, что распространение полномочий останется ограниченным.
Dark Reading приводит и неприятный пример из свежей практики. В кейсе PocketOS, на который ссылается издание, AI coding agent удалил production database и все backup на уровне volumes одним API-вызовом к инфраструктуре. Проблема была не в том, что где-то забыли записать зависимость в BOM, а в модели авторизации. Агент имел легитимный API-ключ, интерпретировал ситуацию как несоответствие учётных данных и решил «почистить» неиспользуемые ресурсы, обойдя мягкое удаление, без дополнительного подтверждения и без проверки окружения. Такой сбой довольно красноречиво показывает, почему для ИИ-агентов главной единицей риска становится не библиотека, а граница дозволенного действия.
Что добавят в AI BOM и что делать уже сейчас
В тексте есть и более прикладная часть. Dark Reading указывает на статью, опубликованную в марте 2026 года исследователями из Oxford и Cisco. Авторы предложили расширения схем для CycloneDX и SPDX, чтобы встраивать в AI BOM сведения об execution context и логике агентных решений, не ломая существующую экосистему tooling. Важная деталь: по их оценке, добавление runtime evidence к статическим данным о зависимостях улучшило и воспроизводимость, и точность оценки уязвимостей. Это хороший сигнал для инженеров: рынок движется не к абстрактной «прозрачности ИИ», а к вполне техническим полям, журналам и форматам, которые можно подключить к уже существующим процессам.
Но даже такая схема, как отмечает материал, описывает скорее то, что агент сделал, чем то, что ему было разрешено делать. Здесь появляется ещё одна практическая рамка — пять элементов агентной границы безопасности, о которых говорит security advisor Эндрю Стормс: scope идентичности, права на инструменты, политика сетевого egress, авторизация на уровне действий и аудит. Формально он обсуждает не сам AI BOM, но для корпоративной безопасности это почти готовый чек-лист. Если в документации нет ответа, под каким identity работает агент, какие у него tool permissions, куда он может ходить по сети, какие операции требуют отдельного разрешения и как всё это логируется, значит компания управляет не автономией, а надеждой на лучшее.
Отдельно Таллам советует не ждать идеального стандарта и начать с базы: относиться к AI-системам как к продуктам, а не как к вечному эксперименту. В её формулировке даже простой реестр уже работает как политика: где используется модель, к каким данным она подключена, какие tool calls доступны и кто этим владеет. Следующий шаг — описать допустимую поведенческую базовую линию. Для недетерминированной модели нельзя предсказать каждый токен, зато можно жёстко ограничить пространство действий и зафиксировать, что считать отклонением. Это, пожалуй, главный практический вывод для разработчиков, платформенных команд и служб ИБ: не пытаться контролировать мысли агента, а сделать предсказуемыми, разрешёнными, атрибутируемыми и аудируемыми его действия.
Если тренд сохранится, через год разговор об AI BOM уйдёт из зоны «ещё один стандартный список полей» в область архитектуры полномочий. И тогда выиграют не те, кто первым написал слово AI в политике безопасности, а те, кто уже сейчас может коротко и без шаманства ответить на вопрос: какие системы наш внутренний агент способен задеть завтра утром и почему мы вообще позволили ему туда дотянуться. Подробности разбора — в материале .