AI-агенты. AI red teaming. OFFZONE 2025.
#иб_для_ml

ℹ️21 августа 2025, 17:15
📍Москва, ГОЭЛРО, AI.Zone
➡️https://offzone.moscow/program/you-also-need-red-teaming-for-ai-agents-here-s-why/

Всем привет!
Послушать про red teaming не хотите ли? И увидеть сей процесс к AI-агентам применительно?

Тогда приходите на наш с Димой Сивковым доклад. Мы поделимся своим опытом в этой области, и кое-чем еще)

Вы узнаете:
➡️как взламывают it-системы через AI-агентов
➡️что такое "непрерывный AI red teaming"
➡️чем пользоваться, чтобы строить AI-агентов безопасно

И главное - почему по-настоящему безопасных AI-агентов без AI red teaming все- таки не сделать?

Также рекомендую послушать доклады Влада, Марины и Артема на том же треке:

Владислав Тушканов: "Могут ли агенты реверсить и какая LLM реверсит лучше?"

Марина Полянская: "Как мы анализировали безопасность код-ассистента и при чем здесь интерпретируемость"

Артем Семенов: "Ложь инкорпорейтед: эволюция эксплоитов для ИИ (2023–2025) и надвигающиеся угрозы"

Практикум для CISO
#иб #ml_для_иб

Сочетание AI c кибербезопасностью выражено в двух моментах: AI - это средство защиты, и AI - это объект защиты. Но часто оказывается, что новые подходы - это несколько изменившиеся старые, так что важно быть не только на острие современной мысли, но и быть глубоко погруженным в классический кибербез. И с этим вам может помочь Интенсив для CISO от Код ИБ. Экспертами там будут в том числе мои хорошие знакомые, так что я этому мероприятию доверяю)

Практикум будет в сентябре, и сделан как курс повышения квалификации ПРОФИ (с дипломом гос. образца) для руководителей служб кибербезопасности.
Спикеры расскажут про создание службы ИБ с нуля, про штабные киберучения, про безопасную разработку, и другие аспекты ИБ.
А также - Сергей Чекрыгин из Check Point выступит с докладом "Актуальные вопросы и тренды ИБ в ИИ в 2025".
Деловая программа рассчитана на два дня, и пройдет в Сочи на Красной Поляне, поэтому получится еще и отдохнуть от городской обстановки.

ℹ️11-14 сентября
📍Роза Хутор, отель "Эрбелия от Васта"
➡️Подробности и почасовое расписание
⚡️ Содержание практикума
➡️Учения в штабе и на киберполигоне
➡️Мастер-классы от экспертов
➡️Кулуарное общение с другими директорами и представителями вендоров по ИБ и ИТ
➡️Отдых и приключения: экскурсия на каньоны, джип-тур и сплав по реке Мзымта


👤 Экспертами практикума будут
➡️Андрей Масалович, президент Консорциума, Инфорус​
➡️Антон Карпов, директор по ИБ, VK
➡️Георгий Руденко, директор по ИБ, Райффайзенбанк
➡️Всеслав Соленик, директор по ИБ, СберТех
➡️Сергей Петренко, директор по ИБ, Цифровой оператор Сириус
➡️Сергей Чекрыгин, представитель офиса технического директора Check Point
➡️Лев Палей, основатель #ПоИБэшечки и директор по ИБ, Вебмониторэкс
➡️Антон Кокин, директор по инфраструктуре и ИБ, Трубная металлургическая компания
➡️Андрей Кузнецов, лидер продуктовой практики Standоff
➡️Артем Куличкин, и. о. директора по информационной безопасности дочерних компаний страховой группы, СОГАЗ
➡️Артем Избаенков, член правления, АРСИБ
➡️Сергей Рысин, генеральный директор, АСИЕ-Групп

Росконгресс - состояние AI-агентов для бизнеса в мире
#ai #иб_для_ml

Я неожиданно встретил и прочитал крайне содержательный отчет Росконгресса по состоянию рынка AI-агентов в мире на август 2025 года. Он изобилует цифрами и графиками, свидетельствующими о взрывном росте популярности этой технологии в бизнесе, содержит разбор основных паттернов создания, сценариев использования и рисков применения. Более того, есть даже разбор одного вектора кибератаки.

Ключевые выводы отчета
✅ Успешные внедрения AI‑агентов связаны с решением узких задач с четкими границами автономности и обязательным человеческим контролем важных решений
✅ Агентные системы создают дополнительные векторы кибератак, включая отравление памяти и захват агентов через манипулирование контекстом
✅ Статистические данные не подтверждают массового замещения рабочих мест — лишь 14% работников в США непосредственно столкнулись с сокращениями из‑за автоматизации

Главное по кибербезопасности
➡️23% компаний (из 1036 опрошенных IBM) сказали что новые атаки на агентов - главный мешающий фактор для масштабирования технологии
➡️новым критическим классом атак является отравление памяти
➡️80% опрошенных организаций сообщают что у них уже были инциденты, в которых их AI-агенты передавали нарушителям конфиденциальные данные

О чем вообще пишут в отчете
➡️Концепция агентного ИИ
➡️Сценарии использования AI-агентов - клиентский сервис, персональные ассистенты, создание контента, HR, транспорт, здравоохранение
➡️Вопросы масштабирования AI-агентов - надежность, кибератаки, регуляторика, чрезмерная автономность
➡️Венчурные инвестиции в ИИ - структура фондов в США, количество и объем сделок
➡️Перспективы внедрения агентного ИИ - снижение операционных расходов, экономия в секторе клиентского облуживания
➡️Прогнозы рынка агентного ИИ - экспоненциальный рост вплоть до 2034, при этом падение рынка SaaS
➡️Технические ограничения AI-агентов - накопление ошибок в многошаговых рассуждениях, высокая накапливающаяся стоимость длинных диалогов, сложности с выполнением сложных непрерывных задач
➡️Риски агентного ИИ - дают ссылку на OWASP и AgentDojo, дается пример "атаки через AI-браузер", утечки конфиденциальных данных в том или ином виде, каскадные эффекты распространения ошибок в многоагентных системах. Перечислены принципы безопасности AI-агентов от OWASP:
▪️авторизация агентов в нижестоящих системах
▪️ограничение функциональности "расширений" до минимума
▪️множество агентов с раздельными ролями вместо универсальных агентов
▪️непрерывный мониторинг аномалий поведения и механизмы отключения агентов при срабатывании защиты
➡️AI-агенты на рынке труда - более половины бизнес-лидеров признали, что увольнять людей при появлении ИИ было ошибкой, при этом статистика показывает падение количества вакансий по всем направлениям в США до 50%
➡️Сценарии будущего рынка AI-агентов
▪️пессимистичный (инциденты повлекут жесткое регулирование и это задушит рынок)
▪️базовый (агенты как узкоспециализированные инструменты для повышения эффективности, ничего сверхъестественного, рост рынка замедлится)
▪️оптимистичный (агенты достигнут надежности свыше 99% и становятся стандартным компонентом любого корпоративного ПО, рынок растет)

Вам тоже нужен red teaming AI-агентов - и вот почему
#иб_для_ml


Конференция OFFZONE наконец-то разместила в открытом доступе записи и материалы докладов!

Наш с Димой доклад тоже можно посмотреть и скачать презентацию)

Что вы узнаете в докладе
➡️ как выглядят атаки на AI-агентов: EchoLeak, MCP Slack Lethal Trifecta, и атака на Claude Computer Use, проведенная нашей командой
➡️как можно применять Модель Угроз КБ AI Сбера для AI-агентов и гайд по созданию AI-агентов для кибербезопасности
➡️что AI Red Teaming - циклический и непрерывный процесс, состоящий из 3 этапов: Threat Intelligence & Monitoring, Research & Development, Testing
➡️процесс тестирования изнутри: как происходит оценка потенциальных угроз, оценка критичности AI-агента, отбор перечня промпт-атак для проведения тестирования, и, наконец, конструирование тесета атакующих запросов.

А вопросы по докладу приглашаю задавать в комментариях)

OWASP GenAI COMPASS - руководство по AISecOps
#иб_для_ml

Команда OWASP GenAI Security Project выпустила 10 сентября
новый документ - Threat Defense COMPASS 1.0 (PDF-RunBook и Excel-калькулятор).
Документ на первый взгляд - сложный для понимания, выглядит как швейцарский нож против всего, но если вчитаться... Становится интересно. По итогам могу сказать, что глубина проработки у него намного лучше, чем была до этого у августовских.

Что же такое COMPASS?
Это фреймворк с описаниями проверок безопасности на всех этапах жизненого цикла GenAI-приложений, собранный с опорой на цикл OODA (Observe–Orient–Decide–Act). Реализован в виде таблицы-шаблон для контроля этих проверок. А PDF-ка по сути руководство пользователя.
В таблице по фреймворку COMPASS:
📝формируется «паспорт приложения» (цель, данные, концепт архитектуры, сводный статус по рискам/допущениям),
🖼формируется профиль угроз и поверхность атаки,
отмечаются актуальные уязвимости (CVE), выбираются меры безопасности,
🔫отмечаются релевантные для приложения инциденты и фиксируется базовая оценка последствий/стоимости ущерба
💧определяются требования к телеметрии для SIEM, сценарии и роли реагирования в SOAR
💳заполняются результаты ревью и редтиминга,
определяется остаточный риск с решениями по ответственным и срокам,
📈формируется дорожная карта внедрения мер безопасности.

В документе также есть и конкретные полезные артефакты:
➡️Лист "3a Orient Known AI Vulnerabilities" таблицы содержит 31 уязвимость (CVE) связанную с промпт-атаками или supplychain-атаками на GenAI.
➡️Лист "3b Orient Known AI Incidents" таблицы содержит 20 инцидентов по GenAI со ссылками и оценкой денежного ущерба, а также приведен перечень лучших источников инцидентов по теме
➡️Лист "3d Orient Red Team Security Review questions" содержит вопросы к команде разработчиков перед проведением редтиминга - своеобразный чеклист.
➡️Листы "6 Reference: Defenses & Mitigations", "6a Reference: Defenses & Mitigations", "6b Reference: Incident Monitoring" таблицы содержат очень подробное описание практик детектирования и реагирования на инциденты КБ GenAI

С ИИ всё стало умным, в том числе и… малварь — история появления GenAI-полиморфных вирусов #опытэкспертов

GenAI сегодня становится не просто ассистентом для скрипткидди, но и элементом киллчейна, выполняя задачи по генерации вредоносного кода "на лету", уже внутри контролируемого контура — это полноценный новый вектор атаки.

За два года вокруг "расцензуренных" LLM вырос целый подпласт киберугроз. Но если WormGPT/FraudGPT это уже банальные подсказки для фишинга и помощник для скрипт-кидди, то куда интереснее случаи, где модель встраивается в сам цикл атаки и генерирует действия/код "на лету".

Борис Захир, независимый эксперт и автор блога "Борис_ь с ml", выделил в статье четыре интересных кейса, от PoC до боевого инцидента, и сделал вывод — GenAI уже не просто декорация, а значимый элемент киллчейна.

➡️ Читать статью на Хабре

В материале упоминаются и довольно известные инциденты — EchoLeak и Lethal Trifecta, приведены их схемы реализации. И на их фоне становится понятно, чем кардинально отличаются другие, уже менее популярные атаки — BlackMamba, PromptLock, s1ngularity. И рассмотрен также пример раздутой хайпом ситуации, на самом деле не имеющей пока серьезной значимости — это SkyNet.

Главное отличие EchoLeak от BlackMamba и прочих из этой тройки, которые эксперт предлагает называть GenAI-полиморфными вирусами — это не прямая реализация вредоносного действия с помощью тула агента, а использование GenAI для создания конкретных кусочков малвари: кода дискаверинга секретов, шифрования файлов, написание рансом-сообщения жертве.

В самой же статье вы найдете подробную схему реализации (с тактиками/техниками) каждого инцидента, ответы на вопросы об эффективности таких методов атаки и о том, почему же все-таки это работает и обходит защиту, а также взгляд эксперта на перспективы развития таких вирусов.

✏️ Статью написал Борис Захир, независимый эксперт и автор блога  "Борис_ь с ml"

A2AS - как в первый раз
#иб_для_ml

По безопасности AI-агентов 29 сентября был представлен документ «A2AS: Agentic AI Runtime Security Self-Defense» за авторством группы компаний: OWASP, AWS, Google, JPMorgan Chase, Cisco, Meta, ByteDance, Elastic, SalesForce и Wallarm.

Этот анонс уже многие видели. Но так как набор имен в авторах серьезный, я тоже решил поподробнее разобраться. Есть ли тут революция?..

Основной фокус публикации – концептуальные меры защиты рантайма AI-агентов (модель BASIC) и их реализация в виде фреймворка A2AS. Важная часть концепта и реализации в том, что меры имеют легковесный характер и не требуют изменений в архитектуре моделей, их дообучения, и не вносят заметные задержки.

Впечатление после прочтения - революционно новых подходов я тут не вижу, и ниже раскрою, почему. Предлагаемый базис (BASIC же) - действительно таковым и является, по факту же A2AS - это лучшие практики, с которых можно начать, не реализуя гардрейлы. Стоит ли это делать - да, особенно если в вашей организации в целом ИБ только устанавливается. Для организаций же со зрелым подразделением по ИБ новостей тут будет мало. Однако в любом случае пропускайте предлагаемые меры через сито своих реалий и особенностей, я бы не назвал их применимыми в прямом виде. Например, от слов a2as в тэгах промптов можно избавиться...

Суть A2AS
Предлагается пятиуровневая система мер - BASIC - с детальным описанием реализации. Уровни следующие:

1⃣B (Behavior Certificates) - разграничение доступа агента (доступ через инструменты файлам, API и т.д.).

Классическая мера безопасности (RBAC/ABAC/...) с новым объектом применения - тулы агента.

A2AS приводит пример реализации в виде JSON-схемы, с id агента и описанием доступных агенту тулов и ресурсов. Но пример частный, а как выглядела бы универсальная схема, не описано. Таким образом, воплощается же эта мера как некий middleware между AI-агентом и инструментом (или MCP-сервером), применяющим политики доступа агента к ресурсам.

2⃣A (Authenticated Prompts) - проверка целостности и подлинности запросов через хеширование/подписи.

Классическая мера безопасности (HMAC для контроля целостности запросов) с новым объектом применения (промпты).

В исходном примере зачем-то предлагается вводить прям в промпт подпись запроса в виде хэша. Зачем это знать GenAI-модели, я не понимаю, но идею с подписями можно развить. Например, есть дерево Меркла, отлично подойдет для диалогов.
Но чем в целом эта мера для меня странная, так это тем, что митигируемая ею угроза далеко не самая актуальная сейчас.

3⃣S (Security Boundaries) - явное разделение доверенных и недоверенных данных в контексте с помощью тегов.

Способ повысить внимание LLM к безопасности генерируемого текста в ответ на входной промпт.

Суть в указании для GenAI-модели в промпте явно, где результаты работы недоверенных инструментов, а где доверенных. В примере предлагается также передавать что-то вроде подписи доверенного тула, но не ясно, как ее создавать.

4⃣I (In-Context Defenses) - дополнительные инструкции безопасности в контексте, «вызывающие» выравнивание модели.

Способ повысить внимание LLM к безопасности генерируемого текста в ответ на входной промпт.

Просто инструкции "делай хорошо и не делай плохо", даже без четких формулировок. На эту тему, кстати, рекомендую почитать 1, 2, 3, 4, 5.

5⃣C (Codified Policies) - правила доступа к ресурсам добавляются в контекст в кодоподобном виде.

В основе - является классической мерой безопасности с новым объектом применения. По сути предлагается существующие политики доступа дублировать в промпте LLM текстом. Поэтому также является и способом повысить внимание LLM к безопасности генерируемого текста в ответ на входной промпт.

Польза документа (безусловная)
Можно это легко не заметить, но в начале рассматривается большое количество современных концепций защитных механизмов - от способов составления системного промпта до гардрейлов и агентов-безопасников. Я выписал названия статей и дал ссылки на эти статьи в отдельной заметке.

Багбаунти для ИИ - какие могут быть сложности
#иб_для_ml

Довелось недавно поразмыслить на тему реализуемости этичного хакерства применительно к системам, использующим ИИ. Преимущественно тут конечно можно говорить о GenAI (и не о стандартном машинном обучении), но можно и обобщить.
Данная область в России пока что в целом еще не имеет полноценной регуляторной проработки, и тем более в области систем с ИИ.
Меня кстати спрашивали об этом на докладе на Offzone в этом году, так что с другой стороны нельзя и утверждать, что тема совсем никому не интересна.

1⃣В контексте безопасности GenAI (или PredAI) пока нет устоявшегося определения «уязвимость AI-модели». Наиболее близкой к этому понятию сущностью являются методы промпт-атак, отображающие различные способы нарушения выравнивания модели для получения небезопасных ответов (генераций для GenAI). Если рассматривать системы с использованием GenAI, как более масштабный объект защиты, ситуация лишь усложняется. Поэтому, чтобы учитывать контекст систем с GenAI в багбаунти, надо разобраться с определением уязвимостей таких систем.

2⃣Второй важной темой отмечу сложность проверки найденных «уязвимостей» в системах с GenAI. В силу вероятностной природы объекта проверки, их воспроизведение (проверка, триаж) отличается от обычного подхода. Тут необходимо определять пороги и другие критерии, при которых найденная уязвимость считается валидной (например, метрика Attack Success Rate, ASR), а при каких нет.

3⃣Третье – механизм учета и устранения «уязвимостей» в системах с GenAI. Несмотря на то, что для закрытия некоторых из них подходят и классические меры кибербезопасности, некоторые проблемы требуют специфичных мер – например, дообучения модели. А это тоже совсем другой коленкор, так как при каждом новом релизе дообучения модели, в виду вероятностной природы модели, могут проявиться и те уязвимости, что были закрыты этим способом раннее. Это приводит к необходимости регулярной проверки (например, с помощью редтиминга) всего перечня релевантных для данного типа модели «уязвимостей» (т.е. промпт-атак). И, возможно, проверке надо будет подвергать и системы/приложения на основе данной модели, но уже на специфичные данным системам сценарии атак.

Тема дискуссионная, давайте обмениваться мнениями в комментах)

А картина Рериха для привлечения внимания)

Взгляд изнутри
На безопасность ИИ

#иб_для_ml

Работая в любой сфере, нельзя не задаваться вопросом, а что ждет меня завтра, как специалиста в таком-то деле.
В нашей зарождающейся отрасли, как и в любой, наверное, молодой сфере знаний, бытует мнение, что поезд только набирает ход, и надо в такую актуальную тему погружаться.

Но важно понимать, что безопасность ИИ не существует в вакууме. Ее развитие взаимосвязано с развитием, в первую очередь, самого ИИ, и IT-отрасли в целом. И эта взаимосвязь порождает как развивающую силу, так и тормозящую.

Факторы торможения
▶️ 80% уязвимостей возможны только для GenAI, и PredAI практически не порождает у бизнеса запрос в безопасности ИИ
▶️ Качество моделей (и систем) GenAI нестабильно и недостаточно, чтобы меры безопасности воспринимались спокойно: ИИ-гонка идет в жестких условиях, права на отставание нет
▶️ Отсутствие критичных применений ИИ-систем в бизнесе, имеющих реальные уязвимости и угрозы
▶️ Отсутствие инцидентов-пугалок со значимым ущербом, которые бы служили наглядным примером необходимости делать AI Sec (основываясь например на AIID)

Как можно заметить, каждая причина торможения вытекает из предыдущей: для AI Sec важен только GenAI, GenAI пока внедряется плохо, из-за этого поверхность атаки минимальная, из-за этого и инцидентов нет.

Так что же, все плохо? Ведь все как по классике информационной безопасности, "самый безопасный канал передачи информации - тот, которого не существует".
Например, AI-агенты, главная суть которых - совершать действия в реальном мире, в дорогих и критичных процессах ничего не делают, 80% это просто суммаризация, а оставшиеся 20% - используют исключительно инструменты получения информации. А ведь сколько различных угроз, сценариев и прочего придумано для AI-агентов...

Кажется, что безопасность ИИ обгоняет свое время. Очень странная ситуация. Однако в истории такое бывало.

Исторические примеры
— Здравоохранение. В 1847 году Игнац Земмельвейс ввёл обязательную дезинфекцию рук врачей, что сочли избыточной и оскорбительной мерой, но резкое падение смертности и последующее признание антисептики доказали её абсолютную правоту.
— Безопасность в автомобилях. В 1959 году трёхточечные ремни безопасности Volvo поначалу воспринимались как неудобная и лишняя перестраховка, но последующая статистика спасённых жизней сделала их и другие решения пассивной безопасности отраслевым стандартом.
— И таких примеров много: безопасность ядерной энергетики, защита от стихийных бедствий.

Какие же позитивные факторы остаются у безопасности ИИ, с точки зрения ее роста?

Факторы роста
⚡️ Появляются новые, более перспективные архитектуры, чем LLM. Я считаю, что в развитии AI есть четыре перспективных направления сейчас:
— совмещение диффузионных и трансформерных архитектур (1, 2, 3),
— построение моделей без разделения на обучение и инференс (спайковые нейросети - 1, 2, или например Google NL), что намного более похоже на естественный интеллект.
— кардинальное уменьшение размеров моделей. Пример - SLM, (1, 2, 3, 4)
— переход от предсказания токенов к предсказанию смысла ответа (модели семейства JEPA от группы Ле Куна)
⚡️ Применение ИИ явно будет требовать развития его влияния на реальный мир: роботы, биоинженерные системы (нейроинтерфейсы и пр.), космические аппараты, и многие другие направления. Утверждать, что ИИ так и останется "читателем" статей, вряд ли кто-то готов.
⚡️ Стране необходим суверенный ИИ. Об этом и Президент заявил на AI Journey в ноябре 2025, и это отражается в позиции регулятора: приказ ФСТЭК №117, разработка ГОСТов совместно с ИСП РАН, деятельность форума ТДИИ.

Вывод
Исторические примеры показывают нам, что безопасность может обгонять бизнес, и далеко не всегда это ошибочная перестраховка. Я верю, что AI Sec в будущем будет точно так же спасать жизни, как в свое время гигиена и автомобильные ремни. Тем более что этому сопутствуют несколько значительных факторов роста технологий.


P.S. Тема возникла из последних разговоров с друзьями, и из опыта за год работы в сфере. Накопилось. Артем тоже высказался по этой теме, рекомендую ознакомиться.

🛜 Всем привет с черно-зеленой конференции)

Коннектимся в комментариях)

Что такое инструмент AI-агента (тул)?
#ai

Как известно, AI-агент - это код. Код может дергать API. Является ли любое обращение агента к API вызовом тула? Очевидно, что нет, и с этим кажется надо разбираться.

⚡️ А зачем, кстати, можете вы подумать? На самом деле необходимость явная - среди обилия приложений с LLM очень сложно отделить обычное workflow-приложение (по классификации Anthropic) и реального AI-агента. Между тем мы явно знаем, что если тулы реально есть, это новая серьезная поверхность атаки. То есть новые агентные угрозы (например, Ag03-Ag06 по МУ КБ AI Сбера).

💧 Раз определение все-таки нужно, пойдем за мировым опытом. И тут оказывается, что определения именно дают очень немногие вендоры. Я нашел всего лишь два прямых определения:
IBM - внешний по отношению к GenAI-модели ресурс, интерфейс (например, API) или система, которые используются для выполнения конкретных задач и расширения базовых возможностей модели.
Pillar - внешние возможности или вызываемые сервисы, которые модель ИИ, в частности AI-агент, может использовать для выполнения конкретных действий или получения информации за пределами своих внутренних знаний.

Есть определения ненапрямую, а посредством самого термина "агент", от OpenAI и от Anthropic. У OpenAI интересно, что они выделяют виды тулов (по типу реализации: hosted, python function, agent-as-tool).

❓ Что же в них не хватает? Формальности и реальной применимости в случаях, когда необходимо явно доказать, что рассматриваемое приложение с использованием GenAI AI-агент или им не является.
Что IBM, что Pillar, пишут про некоторые complex tasks и specific actions, но что это такое?
Пример: "AI-агент" как приложение при старте диалога с пользователем по идентификатору сессии запрашивает у системы с данными пользователя (например по программе лояльности) его историю списания/начисления баллов. Таким образом суммаризирует эту справку и консультирует-предлагает что-то новое. Вызов внешнего API есть, "конкретное действие" есть, базовые возможности и внутренние знания расширены. Является ли это тулом? Очевидно нет.

Есть два момента, которым явно должен отвечать реальный тул на самом деле. Они конечно понятны всем, кто хоть раз писал агента самостоятельно, и читал один-другой мануал, но, как мы знаем, безопасность начинается там, где заканчиваются домыслы.

📷 Обязательные свойства тула

1⃣ Недетерминированная природа вызова.
Инструмент AI-агента (тул) вызывается LLMкой. Это происходит, если мы сообщили в системном промпте ей перечень тулов с их описаниями. В таком случае она может намеренно написать соответствующее название в ответе, иначе - это случайная, неуправляемая генерация. Важно тут понимать, что аргументы тула LLM может и не генерировать, главное - что факт вызова определен именно ответом модели.

2⃣ Двухсоставная реализация
Тул - не просто внешняя система, это на самом деле только вторая его часть. Без первой части, кода вызова API со стороны AI-агента внутри его дистрибутива, тул невозможен. Этот код мало того, что парсит ответ на наличие названия, аргументов и их значений, но и на основе них формирует вызов реального API (или даже нескольких). Что в определениях также отражено слабо.

Так, я пришел к собственному определению.

🪄 Инструмент AI-агента (тул) - программный компонент AI-агента, реализующий функциональность или предоставляющий интерфейс доступа к ней посредством API, факт вызова которого определяется решением GenAI-модели, содержащимся в ее ответе.

Также интересно развить и тему разных типов тулов, в разрезе, важном для безопасности. Тема отдельного поста, конечно, но кратко я бы сказал так: тулы только с чтением, тулы с изменением информации, тулы с изменением ресурсов, тулы с физическим воплощением. И также по времени действия: тулы с мгновенным результатом и с отложенным результатом.

И еще одной отдельной темой, кстати, является вызов других AI-агентов, который технически тоже выглядит как тул. Но лично мне кажется, что межагентское взаимодействие надо выделять еще более обособлено, так как опять же угрозы там еще более обширные, чем в обычных тулах.

OWASьP Top 10 для AI-агентов - finally
#иб_для_ml


Новая таксономия угроз AI-агентов в начале декабря вышла от коллекттива OWASP - Top 10 For Agentic Applications 2026.
Обзоров уже по ней достаточно, поэтому описание будет кратким, я хочу поделиться именно своими находками и мнением.

Описание
Документ представляет 10 категорий угроз, актуальных для AI-агентов и мультиагентных систем. Для каждой категории представлены причины ее возникновения, возможные последствия, варианты реализации, и меры митигации. Отдельно выражаю почтение авторам, которые приняли во внимание все многогранное творчество всего коллектива OWASP GenAI за 2025 год, и обеспечили полную взаимосвязность с другими своими проектами и документами. А также документ содержит приятный бонус - описание 25 инцидентов по КБ AI-агентов 2025 года (с раскладкой на представленный топ 10).

Мое впечатление по прочтению

▶️ Это лучший документ OWASP по AI Security на данный момент.

Практикующим специалистам очень рекомендую к прочтению. Для погружения с нуля может быть сложновато, но если все же засядете, то результат того точно стоит.

Топ-3 находок для меня
▪️проверка безопасности вызовов тулов
Я часто сталкивался с тем, что необходимо рассказывать свои идеи и подсвечивать их очень детально, хотя казалось бы (мне), что они очевидны. Одна из таких - мера митигации semantic firewall на запросы на выполнение действия с помощью инструмента в категории «ASI02. злонамеренное использование инструментов». Главное - с помощью этого механизма можно предотвратить утечки данных от AI-агента. И так как память и межагентное взаимодействие - это подвиды тулинга, то предотвращение закрепления и распространения промпт-атак в памяти и других агентах можно реализовать именно таким semantic firewall.

▪️конфиденциальность информации и intent-signed tokens
Категория угроз «ASI03. Нарушение идентификации и превышение привилегий» всегда мне казалась нерелевантной, относящейся к классической КБ, проблемам настройки IAM. Но почитав внимательно, я осознал, что тут есть GenAI-специфика. Дело в том, что если агент имеет доступ к информации определенного уровня конфиденциальности, то далее нельзя без специальных средств определить, исходит ли от него конф. инф., или нет. И из-за этого в МАС возможна такая угроза, как передача конф. инф. от агента одного категории конфиденциальности к агенту более низкой категории конфиденциальности.
И в той же категории указана замечательная и интересная мера митигации - использование intent-signed tokens. Предлагается обеспечивать активный доступ агентов к информации на основании выделенного "намерения" агента или пользователя. И в сочетании с JIT-access control на базе JWT можно построить достаточно надежную систему контроля доступов.

▪️цифровой двойник
В категории угроз «ASI08 Каскадные нарушения» описывается распространение и усиление одной «ошибки» (опасного ответа или галлюцинации в ответе агента) при взаимодействии AI-агентов в рамках мультиагентной системы. По мере распространения атака или галлюцинация начинает влиять на все большее количество агентов, на их память, ресурсные системы через инструменты, на их пользователей. И одна из необычных мер митигации для этой угрозы - это цифровой двойник МАС. С его помощью можно проверять именно такие каскадные сбои, воспроизводя записанные действия агентов на проме в изолированной копии пром-среды. И это супер идея, как по мне. Хоть и довольно дорогая, особенно в корпоративных условиях. Помимо этого, для митигации ASI08 можно применять и несколько простых требований - ввод time-to-live у сообщений, travel distance.


В документе много свежих идей и в остальных угрозах. Но воспринимать меры митигации может быть сложно, так как не хватает целостного подхода в их подаче - как соотносятся эти меры друг с другом, в каком порядке их ставить, какими мерами можно минимально покрыть весь топ 10 - на эти вопросы авторы ответ не дают.

И уносит меня, и уносит меня...
#праздное #ml_для_иб #иб_для_ml

Минул удивительный и насыщенный 2025 год. Удалось много сделать, и я понимаю, что сильно изменился за это время. Много знакомств приобрел благодаря своей публичной деятельности, и ощущаю еще большую ответственность за свой контент. Это очень сильный драйвер.
Надеюсь, вам комфортно и интересно читать и слушать информацию от меня)

В этом году канал круто вырос: почти трехкратный рост подписчиков (+1100), суммарно 100к просмотров на 60 постов. Спасибо вам большое!)

В 2026 я буду продолжать писать и выступать, делиться накапливаемыми знаниями. Готовить полезные материалы, чтобы помогать вам и нашей стране в развитии безопасности ИИ и в целом ИИ для информационной безопасности.
Per aspera ad astra, как написано на стенах моей альма матер.

А сейчас, дабы поддержать традицию - представляю вам основные материалы, что я сделал или к которым приложил руку в этом году.

Дайджест 2025
🔵Статья Habr "Что такое интерпретируемость машинного обучения?"
🔵Статья Habr "Системы оценки критичности уязвимостей в AI Security"
🔵Статья "Риски кибербезопасности информационных систем с ИИ и подходы к их митигации", журнал "Информационная безопасность"
🟡Открытый подкаст "Новые векторы атак и уязвимости, которые открывают ИИ-агенты"
🟢Вышла Модель Угроз Кибербезопасности AI от Сбера
🟡Вебинар "AI в Кибербезе & Кибербез в AI"
🟡Выступление на III Форуме "Технологии Доверенного ИИ" с докладом "Протоколы MCP и A2A - безопасность для мультиагентных систем или новые угрозы?"
🟢Вышел Гайд по AI-агентам с мерами митигации угроз кибербезопасности от Сбера
🔵Статья Habr "AI-агенты и мультиагентные системы, MCP и A2A. Основные угрозы и подходы к обеспечению безопасности"
🟣Опубликована Карта потоков данных GenAI-модели для оценки угроз и мер безопасности
🟡Выступление на OFFZONE с докладом "Вам тоже нужен red teaming AI-агентов - и вот почему"
🔵Статья Habr "С ИИ всё стало умным, в том числе и... малварь"
🟣Опубликованы 7 правил безопасности системных промптов
🟢Вышел отчет "AI Security в Финтехе" от АФТ


Итоги 2024 года

GenAI-powered атаки: о чем (и как) мечтают электрохакеры, и как их ловить
#ai #иб_для_ml

Про GenAI-powered атаки часто говорят так, будто использование ИИ в проведении атаки всегда происходит каким-то одним очевидным образом. Чаще всего речь идет об ассистентах вроде недавно вышедшего DIG AI. Намного реже речь идет про вирусы со свойством полиморфности, обеспечивающимся во время проведения атаки с помощью GenAI модели.

Я решил привнести немного системности в эту тему, ведь без нее не перейти к ответу на главный вопрос - какие меры защиты можно определить от таких угроз? Классификация позволит как минимум корректно определить поверхность атаки и понять, что именно должно детектироваться (артефакты ВПО, сетевые вызовы, поведение).


🎭Варианты использования GenAI нарушителем
1⃣Модель исполняется внутри контура легитимно, злоумышленник использует GenAI-сервис вашей организации как средство подготовки/поддержки атаки.
2⃣Модель исполняется вне контура (внешние сервисы/модели) и тоже используется для подготовки атаки.
3⃣Нарушителем используется легитимно развернутая в защищаемом контуре модель/сервис через внутренние интерфейсы как средство автоматизации действий атакующего.
4⃣Модель доставлена в контур и запускается как часть ВПО. Например (компактные LLM/SLM, примерно до 4B), чтобы работать автономно и не зависеть от внешнего API. Может быть также предварительно расцензурирована.
5⃣ВПО обращается к внешнему GenAI-провайдеру по API изнутри контура, но результаты используются для действий внутри контура (создание тех же вредоносных скриптов).

Более системно и наглядно я отразил эти варианты на схеме.

🎯Цели применения GenAI злоумышленником
Что может улучшить и автоматизировать атакующий благодаря GenAI? Вопрос непростой, если учитывать, что есть и обычная автоматизация, которая может быстро перебирать порты, искать версии и цепочки уязвимостей, массово запускать различные эксплоиты.
Я вижу для нарушителя два класса полезных эффектов.

- Класс 1: автопланирование, ускорение и уплотнение kill chain, быстрая адаптация после блокировок, доработка и оптимизация ВПО — здесь GenAI выступает как инструмент повышения разнообразия используемых процедур нарушителя.
- Класс 2: автоматизация конкретных стадий kill chain внутри среды: разведка целей (поиск секретов/ключей), построение плана под ограничения среды, синтез и адаптация пейлоадов ВПО (шифрование, эксфильтрация, разрушение файла, персонализированное сообщение ransom).

📝Какие задачи решает GenAI в кибератаках, которые не способны закрыть детерминированные средства автоматизации?
- Определение целей и стратегии кибератаки
- Рост вариативности артефактов (одноразовые скрипты/домены, быстрые пересборки) и снижение повторяемости.
- Персонализация коммуникаций под контекст жертвы.
- Усиление мимикрии под легитимные действия и быстрая адаптация под правила/политики среды.

💎Меры митигации по классификации вариантов
▪️Детектирование:
▪️▪️Для вариантов 3 и 4: поиск “GenAI-следа” в артефактах, то есть промптов, импортов vllm/pytorch, файлов моделей, характерных для инференса GenAI профилей нагрузки.
▪️▪️Для 5: анализ исходящих обращений к внешним GenAI-сервисам и их семантики на предмет запросов, направленных на содействие киберпреступлениям (код, обход защит, эксплуатация, эксфильтрация).
▪️▪️Статический/поведенческий анализ кода ВПО на признаки “подгонки под инфраструктуру” (высокая вероятность автоматизации стадий kill chain через GenAI).
▪️Реагирование:
▪️▪️При зафиксированном использовании GenAI как множителя атаки режим реагирования должен меняться: снижение порогов корреляции по связанным действиям, повышение силы мер сдерживания.
▪️▪️Также высокую эффективность может показать использование мультиагентной системы на стороне SOC для повышения гибкости детекта и триажа действий нарушителя.



Про GenAI-полиморфные вирусы я, кстати, уже писал. В статье разложил несколько кейсов подробно по схемам и этапам атаки. Из дополнительного чтива могу еще порекомендовать изучить атаки MalTerminal (1, 2, 3) и CamoLeak.