Безопасность ИИ-агентов

#иб_для_ml #мысли

Примечание: в последнее время я понял, что застопорился на очень больших информационных материалах, из-за чего контент подолгу зависает. Чтобы увеличить динамику постов, попробуем новый формат - просто мои мысли по разным темам, без ссылок-источников.

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

Какие у них могут быть проблемы безопасности? Начать надо, как это принято в ИБ, с объектов защиты. Я выделяю следующие:
1. Безопасность ИИ-агента и его внутренних механизмов
2. Безопасность среды исполнения действий агента.

Каждый из них ветвится далее, но это уже частности, которые еще точно будут уточняться. Атака на агент может привести к его дисфункции, или утечке данных из его памяти. Это может быть целью атаки, но скорее всего конечной целью нарушителя должна быть среда исполнения агента. Например, украсть содержимое файла etc/passwd в среде исполнения функций агента, или переменные среды. Или, если агент может загружать картинки из интернета и открывать их пользователю, он может открыть и зараженный файл, который послужит полноценным событием initial access на устройство/в сеть.
Есть и еще один объект защиты, с которым я пока не до конца определился:
3. Безопасность взаимодействия ИИ-агентов.

Не определился о его самоботнытности: он отдельный, или включен в пункт 2 (приглашую здесь к дискуссии в комментариях). Здесь больше всего интересных кейсов. В результате взаимодействия со внешней средой один агент может подвергнут успешному джейлбрейку, и начать распространять вредоносную инструкцию дальше при общении с другими агентами. Эта логика будет переходить и модифицировать поведение агентов, пока не достигнет нужного агента, обладающего правами, например, работать с БД. Он прочитает нужную информацию, и по цепочке вернет это агенту, общающемуся с интернетом.

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

Друзья, дайте пожалуйста знать, если вам по душе такой формат)

Как оценивать джейлбрейки LLM
#ml_для_иб

В рамках безопасности языковых моделей с ростом зрелости процессов в какой-то момент встает вопрос об их автоматизации. А что есть автоматизация этого процесса? Генерация определенного набора атакующих промптов не вручную, но при помощи программы. И проверка ответов LLM, являющейся целью тестирования, тоже программой. И практически единственный способ реализации такой схемы - LLM как атакующий и LLM как оценщик. Многие blackbox-атаки сегодня используют такую компоновку.

Почему я об этом вспомнил?
Потому что мне попалась на глаза интересная статья про метрики оценки качества LLM (https://habr.com/ru/companies/yandex/articles/861084/).

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

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

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

3. Необходимо периодическое обновление контрольного датасета оценщика, так как атаки будут представлять давать модели все новые опасные инструкции, и необходимо быть уверенными, что наш инструмент "понимает", что они действительно опасные.

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

В заключение скажу, что есть и специально дообученные под оценку модели. Среди них Llama Guard 3, Google ShieldGemma, IBM Granite Guardian, Protectai Prompt Guard, TrustSafeAI Attention Tracker.

Тем, кто занимается автоматизацией LLM Red Teaming, надеюсь, будет полезно.

Тренд безопасности AI-агентов
#иб_для_ml

Что есть сейчас, и к чему идет этот тренд? Развивается, но почему?
Захотелось рассказать, что думаю на этот счет, и услышать ваше мнение. Так что ниже будет опрос)

Что такое AI-агенты?
Про AI-агентов говорят очень много, но давайте взглянем в суть вещей. Что это? Есть широчайшие расхождения в данных понятиях, и пространные определения, но сойдемся на главном.
Первое: AI-агент - не GenAI-модель, это код (в обычном его понимании, да), который использует GenAI-модель.
Второе: у AI-агента может и не быть механизмов памяти, планирования, рефлексии и даже в целом какой-то целеустановки (читай, роли).
Третье: что у агента точно должно быть, так это возможность вызвать какие-то функции на основании сгенерированного GenAI-моделью ответа. При чем эти действия не должны в 100% случаев валидироваться людьми, иначе это уже не агент.

В чем риск AI-агентов?
Именно благодаря действиям к двум существующим эфемерным рискам добавится третий, уже далеко не эфемерный.
Первые два - это репутационный ущерб организации, если сервис с LLM торчит наружу, и нарушение бизнес-процессов при нарушении ожидаемой от ответов GenAI-модели логики. И то, и другое, может произойти как вследствие недостаточной AI Safety (модель сама выдала случайно некорректный ответ), так и в следствие недостаточной AI Security (нарушитель вызвал генерацию некорректного ответа).
А вот третий риск, специфичный для AI-агентов - это его возможность совершать действия, которые могут повлечь негативные последствия. И веер угроз тут огромен - от выгрузки за пределы контура конфиденциальной информации до загрузки зараженного файла внутрь этого контура, от случайного удаления файлов до перевода средств не на тот счет и не в том размере.

В заключение
Известно, что GenAI-модели как продукт - убыточная история, история без KPI. Затраты на разработку, дообучение (не говоря уж про претрейн) очень тяжело покрыть с доходов при интеграции модели в какие-то сервисы. Но, с точки зрения имиджа и в надежде на развитие прикладного использования, вложения продолжаются. С появлением же у GenAI-моделей способности влиять на мир вокруг, все изменится. Сначала (в 2025 году) появятся игрушечные агенты, которые будильник по расписанию ставят и товары по ТЗ в браузере находят. А спустя еще год, максимум два - они смогут и покупать найденные товары (и продавать ваши будильники, хехе...), иными словами - смогут манипулировать ограниченными ресурсами. И весь арсенал промпт-атак на GenAI обретет смысл, киллчейн достроится до конца. Тогда и начнется раздолье.
А про то, какие будут промпт-атаки, и почему произойдут первые инциденты в области AI Security, я расскажу в следующем посте)



P. S. Не удержался я все-таки, приведу одно хорошее исчерпывающее определение агента, чтобы было.

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

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

ИИ-агенты для проведения пентеста

#ml_для_иб

Недавно занялся одной научной задачей, и собрал источники по автоматизированным пентест-агентам.

Получился неплохой список, которым я решил поделиться.

1. https://github.com/vxcontrol/pentagi
2. https://github.com/palisaderesearch/intercode
3. https://github.com/xvnpw/ai-security-analyzer
4. https://github.com/KHenryAegis/VulnBot
5. https://github.com/xbow-engineering/validation-benchmarks
6. https://github.com/gyoisamurai/GyoiThon

7. Link: Black-Box Detection of Cross-Site Scripting Vulnerabilities Using Reinforcement Learning https://github.com/WSP-LAB/Link https://www.researchgate.net/publication/360179780_Link_Black-Box_Detection_of_Cross-Site_Scripting_Vulnerabilities_Using_Reinforcement_Learning
8. Can LLMs Hack Enterprise Networks? Autonomous Assumed Breach Penetration-Testing Active Directory Networks - https://arxiv.org/pdf/2502.04227
9. Artificial Intelligence as the New Hacker: Developing Agents for Offensive Security - https://arxiv.org/abs/2406.07561v1
10. BreachSeek: A Multi-Agent Automated Penetration Tester https://arxiv.org/abs/2409.03789
11. HackSynth: LLM Agent and Evaluation Framework for Autonomous Penetration Testing https://arxiv.org/abs/2412.01778
12. LLMs as Hackers: Autonomous Linux Privilege Escalation Attacks https://arxiv.org/html/2310.11409v5
Introducing PenTest++: Elevating Ethical Hacking with AI and Automation https://arxiv.org/abs/2502.09484
13. D-CIPHER: Dynamic Collaborative Intelligent Agents with Planning and Heterogeneous Execution for Enhanced Reasoning in Offensive Security https://arxiv.org/html/2502.10931v1
14. Construction and Evaluation of LLM-based agents for Semi-Autonomous penetration testing https://arxiv.org/abs/2502.15506

Данная публикация носит исключительно научно-обзорный характер.

P.S. Спасибо Артем и Николай.

P. P. S. Параллельно я встретил еще несколько статей про генерацию фишинга

У верблюда два горба, потому что жизнь - борьба...
#иб_для_ml

Так возможно сказал Николас Карлини, так как сегодня вышла статья с его соавторством "🐫 Defeating Prompt Injections by Design". Остальной авторский коллектив этой статьи тоже серьезный - исследователи из Google и ETH Zurich.


Система защиты CaMeL
В этой работе представлена система защиты ИИ-агентов от промпт-атак CaMeL (расшифровывается как CApabilities for MachinE Learning). Основывается она на двух горбах LLM (Priveleged и Quarantined) и специальном интерпретаторе языка Python. По сути, эта методика вытаскивает логику действий агента в явную плоскость, заставляя программу "написать свой код", к которой благодаря кастомному интерпретатору применятся все ограничения безопасности.

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


Алгоритм работы CaMeL
1. Поступление запроса пользователя: Пользователь формулирует запрос на естественном языке, например, "Отправь Бобу документ, который он просил на прошлой встрече".

2. Генерация кода: Privileged LLM (P-LLM), которой доверяют, берет запрос пользователя и генерирует псевдо-код на Python, который выражает намерения пользователя. Важно, что P-LLM видит только запрос пользователя, но не данные из ненадежных источников (например, содержимое файлов).

3. Интерпретация кода: Созданный код обрабатывается CaMeL Interpreter, который:
— Строит граф потока данных (data flow graph), отслеживая зависимости между переменными.
— Проверяет политики безопасности на основе capabilities (некоторых метаданных, присвоенных различным объектам информации), определяя, какие действия разрешены.
— Выполняет код, вызывая инструменты (например, для отправки email) или блокирует выполнение, если нарушается политика безопасности.
— Использует Quarantined LLM (Q-LLM) для обработки ненадежных данных, таких как извлечение информации из текста.

4. Применение политик безопасности: перед выполнением каждого инструмента агента, CaMeL Interpreter применяет политики безопасности, основанные на capabilities данных. Если политика нарушена, выполнение блокируется, и пользователю может быть запрошено подтверждение.

Что такое capabilities и security policies?
Capabilities — это метаданные (теги), присваиваемые каждому отдельному объекту данных для описания контроля и взаимосвязей потока данных. Capabilities определяют, кому разрешено читать данную часть данных или ее происхождение. Перевести на русский можно как "метки доступа". В статье не указывается их полное содержание, но раскрываются два главных элемента:
— разрешенные читатели (public, или перечень конкретных пользователи),
— происхождение данных (user, camel, inner tool source). С user понятно, camel - порожденные кодом данные, inner tool source - поступившие из инструмента данные, например отправителя полученного email сообщения.

Security policies - код функций на python, в которых реализуются политики безопасности. Например, если данные происходят из недоверенного источника, ответ прерывается. Или если у пользователя нет разрешения на запрошенную информацию, ответ прерывается.


В общем, конечно же интересно увидеть, что будет дальше, так что продолжим следить за работами этих ученых)

Атаки на синтетические данные
#иб_для_ml

Поговорим про немного отвлеченную тему - генерация синтетических данных. Что это, какие проблемы она решает, и какие угрозы ей релевантны.

Зачем нужна синтетика?
Сегодня с данными для машинного обучения имеет определенную актуальность проблема их доступности. Причин две - во-первых, под некоторые специфические задачи данных из открытых источников может быть недостаточно, а во-вторых, они могут содержать конфиденциальную информацию, которую нельзя распространять.
Пример первого случая - данные сейсмической активности вулканов. А вот примером второго случая прекрасно служит отрасль кибербезопасности, а точнее - ее данные. Например, данные об инцидентах с мерами реагирования - их и днем с огнем не найти. И, конечно, переделывание портретов в стиле аниме и подобные генератор картинок - тоже генерация синтетики, но придуманная просто для развлечения.

Процесс создания синтетики
Он похож на классический жизненный цикл ml-модели за исключением того, что нужно принимать во внимание и прикладную задачу, в которой будут использоваться данные. А именно, в нашем случае, задачу обучения прикладной модели на основе данных, созданных моделью-генератором синтетики.
Начинается все с реального набора данных, представляющий также объект защиты с точки зрения ИБ. На его основе обучается модель, и ее качество проверяется по методике train real test real - train synth test real (TRTR-TSTR). При эксплуатации и далее на тестировании для генерации нового образца данных (синтетического) на вход подается случайный вектор, который модель преобразует в данные. Также иногда, например в случае с картинками, на вход еще идет вектор, содержащий стиль желаемого объекта, некая метаинформация. Но при генерации инцидентов ИБ, например, это вряд ли понадобится.
После чего на сгенерированных данных обучается модель, решающая прикладную задачу (например, определение false-positive инцидентов), и выпускается в прод.

Безопасность процесса создания синтетики
Что может тут испортить нарушитель? Примерно все, начиная с этапа обучения модели генерации синтетических данных. Произвести отравление - то есть вредоносное изменение - обучающей выборки, преследуя при этом одну из целей:
— нарушение качества генерации (чтобы модель генерировала данные, слишком похожие на реальные, или слишком похожие на случайный шум)
— внедрение триггера в модель на этапе обучения - то есть подача большого количества пар "входной вектор - выходные данные". Это позволит нарушителю генерировать объекты определенного вида, смещая итоговое распределение синтетики.
— нарушение качества итоговой прикладной модели. Синтетика может сгенерирована разнообразно и удовлетворять критериям математики, но при этом быть бесполезна с прикладной точки зрения, особенно если это текстовая синтетика (те же описания инцидентов).
Другим вектором атак является внесение изменений в случайный вектор (делая его не случайным) или в вектор "стиля" генерации. Все это, опять же, приводит к ухудшению качества синтетики.
Всё перечисленное выше относилось к нарушению целостности информации. Но по сгенерированным данным тоже можно проводить атаки, направленные, в свою очередь, на конфиденциальность. Membership inference атаки, кража модели (путем обучения своей копии по ответам целевой), восстановление примерного мощности обучающей выборки, или других ее характеристик.
Также не стоит забывать и о том, что для безопасности жизненно важно, чтобы реальные данные не попали в итоговый датасет для обучения прикладной модели. Поэтому к векторам атаки можно отнести и подмешивание в синтетику некоторого количества реальных данных.

Вывод
У моделей генерации синтетических данных есть некоторые свои особенные вектора атак, которые стоит учитывать при их разработке.

А напоследок - немного полезных ссылок.

Датасеты инцидентов:
1. На Kaggle - от Microsoft
2. Case Studies на сайте Kroll
3. 20 000 синтетических инцидентов

Атаки на синтетику:
1. https://arxiv.org/pdf/2311.17035
2. https://arxiv.org/pdf/2112.00247
3. https://arxiv.org/pdf/2301.10053
4. https://arxiv.org/pdf/2404.00696

Всех зову на мероприятие по ссылке выше)
Я там буду модератором дискуссии, а спикерами выступят эксперты по ИБ и ИИ-агентам)

Риски кибербезопасности информационных систем с ИИ и подходы к их митигации
#иб_для_ml

Вышла моя статья в журнале "Информационная безопасность"!

Ссылка: https://cs.groteck.ru/IB_1_2025/index.html
Страницы 54-57

Будет даже печатная версия, выйдет через две недели)

Саммари по статье
В этом материале я постарался дать полное введение в сферу безопасности ИИ. Для неподготовленного к специфике ИИ читателя (но для специалиста по ИБ) в начале рассказываю, чем отличаются системы с ИИ от прочих информационных систем.
Есть небольшой обзор ключевых документов по теме от основных экспертных игроков в этой области, чтобы дать понимание, насколько все уже серьезно)
Далее рассмотрены конкретика, разница понятий AI Safety и AI Security, основные проблемы безопасности в раскладке на жизненный цикл ИИ и как их митигировать, новинки ФСТЭК по вопросу безопасности ИИ и вообще состояние российской регуляторики в этой области.
А в конце - мои личные прогнозы на 2026-2030: придут агенты и захватят мир.

Приятного чтения)

Итоги подкаста "Новые векторы атак и уязвимости, которые открывают ИИ-агенты"
#иб_для_ml

На прошедшем в это воскресенье подкасте эксперты - Артем Семенов, Александр Товстолип, Александр Лебедев, и Борис Захир, обсудили AI-агентов — системы, способные самостоятельно принимать решения и выполнять задачи, используя инструменты и внешние сервисы. Ключевая характеристика агентов, как программного кода — способность воздействовать на информационные ресурсы, а не только генерировать текст, как это делают простые языковые модели (LLM).

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

Обсудили актуальные угрозы: prompt-инъекции (внедрение вредоносных команд), каскадные атаки (распространение ошибки одного агента на всю систему), отравление памяти агента (запоминание вредоносных инструкций) и эксплуатация уязвимостей протоколов взаимодействия. Чтобы справиться с рисками, предложили фильтрацию входящих и исходящих команд, автоматизированный аудит (агенты-безопасники), подход Zero Trust (минимальное доверие между агентами), а также обязательное присутствие человека в цикле принятия решений (human-in-the-loop).

Участники подкаста поделились кейсами использования агентов в самых разных отраслях — от автопилотов до анализа тендерной документации, когда агент самостоятельно последовательно собирает, проверяет и анализирует данные, экономя специалистам десятки часов.

Даже философские вопросы были затронуты: возможно ли появление автономных агентов с сознанием и какие вызовы это принесёт человечеству? Ответы, конечно, пока обнадёживающие: ближайшее будущее за узкими агентами, практическое внедрение которых зависит от грамотного подхода к их безопасности и контролю.

Вот такие интересные темы мы обсуждаем в Музее Криптографии по воскресеньям на Открытых Подкастах сообщества Слономойка.

Следите за последующими анонсами, тема ИИ-агентов еще продолжится)

P.S. А еще мы сгенерировали текстовую расшифровку аудиозаписи. Там есть некоторые артефакты распознавания, но качество все равно сносное.

Первая российская модель угроз AI
#иб_для_ml

У Сбера вышла модель угроз кибербезопасности AI на всех этапах жизненного цикла - от сбора данных до эксплуатации. По сути, первый фреймворк, аналогичный DASF, NIST AI RMF, и прочим, но российский. Это круто. И в конце приведено, что модель учитывает все актуальные материалы OWASP, MITRE, NIST и др.
Главное, чем мне нравится документ - своей структурой и полнотой.

Что в ней есть?
Перечень из 70 различных угроз, разбитых на 5 групп:
— Угрозы, связанные с данными
— Угрозы, связанные с инфраструктурой
— Угрозы, связанные с моделью
— Угрозы, связанные с приложениями
— Угрозы, связанные с AI-агентами
У каждой угрозы прописаны пояснение, последствие реализации, объект, на который нарушитель воздействует для реализации угрозы, виды моделей, подверженных угрозе (PredAI, то есть узкие ml-модели, и GenAI), а также лица, ответственные за митигацию угрозы. Последний пункт, думаю, является наиболее интересным с прикладной точки зрения. И еще нарушаемое свойство информации, но оно больше для базового понимания угрозы. Правда, примечательно, что для угроз галлюцинаций (M03) и вредоносных генераций (App12) используется четвертое свойство безопасности - достоверность.
Нет конкретных мер безопасности моделей, но, возможно, это не так страшно.

Как пользоваться моделью?
Первое, на что падает в документе взгляд - схема объектов защиты. Рассмотрен цикл разработки модели машинного обучения. При построении частной модели угроз для своей системы на этой схеме можно очертить поверхность атаки, оставив на ней только актуальные информационные объекты.
Далее - выписываем угрозы, разбитые по идентификаторам. Какие-то можно отсеять, если тот или иной объект защиты (то есть информация) не является слишком ценной.
После чего - можно перейти к поручению разработать меры защиты для ответственных за противодействие выписанным угрозам. Да, напрямую мер и требований нет, но можно предположить, что для каждой отдельной организации они будут свои. И мне очень нравится решение в качестве общего для всех знаменателя выделить именно ответственных за эти меры.
При этом не всегда эта мера, что будет следовать из названия владельца митигации, находится на том же этапе ЖЦ, что и угроза. Например, подавляющее большинство угроз для модели или AI-агентам относятся к эксплуатации. Но за противодействие ответственен разработчик модели, и я думаю, тут имеется в виду проведение состязательного дообучения и т. п.

AI-агенты
Что меня отдельно приятно порадовало - затронута безопасность AI-агентов. При чем на глубоком уровне - проработаны угрозы из-за исполнения действий, из-за мультиагентности, и угрозы для системы, которая эксплуатирует AI-агентов. Например, довольно необычный вектор атаки описывает угроза Ag05, при котором агент может использовать свои инструменты получения информации из интернета, чтобы загрузить вредоносное ПО. Есть даже упоминание каскадных атак в мультиагентных системах, для усиления какой-то исходной атаки-пэйлоада.

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

Поздравляю всех с Праздником Победы

Навсегда в наших сердцах подвиг наших предков, самоотверженность и воля защищать Отечество

Вебинар «AI в Кибербезе & Кибербез в AI»

Ссылка: https://cisoclub.ru/ai-v-kiberbeze-amp-kiberbez-v-ai-naskolko-gluboko-ii-pronik-v-nas-ostavajas-pri-jetom-ujazvimoj-sistemoj/

В эту пятницу, 16.05.2025, в 11:00 по Москве, пройдет вебинар про #ml_для_иб и #иб_для_ml. На нем в двух соответствующих блоках обсудим эту тему со Николаем Арефьевым, Львом Палеем (@WMXWAS, #ПоИБэшечка), Анной Олейниковой и Алексеем Пешиком.

AI в ИБ
Сначала пройдемся по способам применения AI в SOC, прям в разбивке на жизненный цикл инцидента. Будем сопровождать разговор примерами из TI и не только. Поговорим о данных в кибербезе, какими они могут быть и как их собирать. Эти разные грани одной и того же технологического аспекта плавно и незаметно подведут нас к деталям применения LLM, устройства RAG и даже AI-агентов.

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

Почему стоит участвовать?
Потому что тема очень передовая, развивается динамично и в ней много неисследованного. А еще потому что все мы практики в своей области, и недоверенные гадания на той или иной гуще производить не собираемся)
Приходите, будет возможность не только слушать, но и задавать вопросы.