#иб_для_ml
Прочитал большой отчет OWASP по безопасности и управлению агентными ИИ-системами, который вышел 2 дня назад. Отвлечемся немного от сложных концепций и посмотрим на индустрию с позиции хеликоптер-хеликоптер, пара кофер - пара кофер...
Главная мысль: агентная ИИ-система — это композиция из модели, агента, памяти, источников контекста, инструментов, протоколов взаимодействия, учетных данных, цепочек делегирования и среды исполнения. Поэтому защищать нужно всю эту композицию, включая действия агента во время выполнения.
Самое ценное в документе для меня:
Агентная идентичность
Авторы хорошо отделяют обычные машинные учетные записи от идентичности агента. Вопрос уже не только в том, валиден ли ключ или токен. Важно понимать, кто поручил агенту действие, в каком контексте он действует, какие права унаследовал, какой инструмент вызывает и как быстро эти права можно отозвать.
Управление во время выполнения
Предварительная проверка системы быстро устаревает: агент получает новый контекст, выбирает инструменты, пишет в память, вызывает другие сервисы и может менять траекторию выполнения. Отсюда требования к наблюдаемости, журналированию действий, выявлению отклонений от ожидаемого маршрута и аварийной остановке.
MCP/A2A/ACP как границы доверия
MCP полезно рассматривать как канал выполнения действий через инструменты. A2A и ACP — как каналы делегирования между агентами. Для них нужны проверяемая идентичность, ограничения делегирования, контроль описаний инструментов, сквозная трассировка и быстрый отзыв доступа.
Кодинговые агенты
Это один из самых сильных разделов. Кодинговые ассистенты получают доступ к файлам, shell, git, CI/CD, облачной инфраструктуре и учетным данным разработчика. Документ хорошо показывает, почему песочницы и списки разрешенных команд, рассчитанные на человека, ломаются при агентном исполнителе. Особенно важны проверки секретов, независимый контроль репозитория, обязательное ревью критичных изменений и изоляция среды исполнения.
Финансовые агенты
Через FinBot CTF авторы показывают практическую поверхность атаки: поставщики, счета, платежи, проверка мошенничества, коммуникации, MCP-инструменты. Для таких систем нужен не просто контроль доступа, а авторизация с учетом последствий: сумма, контрагент, тип операции, возможность отката, регуляторный эффект.
Мультиагентные и промышленные системы
Для многоагентных систем ключевые риски — подмена агента, транзитивное доверие, циклы делегирования, каскадные отказы и несогласованность политик между агентами. Для OT/ICS добавляются ограничения промышленных контуров: уровни Purdue, физические исполнительные механизмы, доступность и независимые защитные ограничения.
Фанфакт по объему: примерно треть документа занимает регуляторика, около 15% — угрозы и инциденты, еще около 15% — зрелость управления и будущие требования, около 10-12% — таксономия агентов; остальное распределено между идентичностью, цепочкой поставки, прозрачностью, FinBot, проектами и приложениями.
Что можно забрать себе в работу:
🔘вести реестр всех агентных систем, включая неучтенное использование ИИ;
🔘классифицировать агентов по уровню автономности и границам доверия;
🔘выдавать агентам отдельные короткоживущие права;
🔘проверять каждый вызов инструмента до выполнения;
🔘журналировать всю траекторию исполнения: входной контекст, вызовы, параметры, ответы, изменения памяти, решения политик;
🔘тестировать отравление контекста, инструментов, памяти, навыков и межагентных сообщений;
🔘выносить механизмы безопасности за пределы контура, который сам агент может изменить.
Отчет показывает, что индустрия стала тяжелеть. В отчете, например, приводится RCE с CVSS 9.6, касающуяся mcp-remote (CVE-2025-6514). Или что еще круто - появляется страхование AI exclusions - то, о чем когда-то писал Женя (кстати, один из авторов документа). В общем, работы на веку ai security специалиста прибавится... И попкорн становится определенно не лишним)