В последнее время часто вижу термин Internet Of Agents(IoA). Мы уже с вами прекрасно понимаем ландшафт угроз для обычных агентных систем. Но в чём особенность именно агентного интернета ?
Под IoA сейчас понимают инфраструктуру центричность которой поставлена на агентах, взаимодействие с ними вне рамках обычных сетей организаций а также чтобы они могли координированно выполнять задачи.
Для коммуникации между агентами в такой сети реализовано большое множество протоколов – самый известный MCP, но как правило – не единственный (подробнее на рис.1).
Мы должны понимать самое важное что в такой сети может использоваться множество LLM как ядра определённых систем, следовательно – они могут наследовать проблемы самих моделей. Важный фактор что такие системы пока что могут быть децентрализованными(рано или поздно будут регуляторы, реестры и т.д). И хоть кажется что реализация такой сети будет иметь большие преимущества(безусловно это так). Но риски ИБ тут никто не отменял.
В статье Security of Internet of Agents: Attacks and Countermeasures рассматривается некая модель угроз для такой площадки. IoA переваривает множество персональной информации, коммерческих данных и из-за этого вопрос безопасности аутентификации между агентными системами – является критически значимым.
В статье определяют несколько угроз:
⁉️ Подделка идентичности - злоумышленники создают поддельные идентификаторы агентов.
⁉️ Имперсонификация - злоумышленники выдают себя за легитимных агентов
⁉️ Атаки типа Sybil -когда создаётся множество фиктивных идентичностей для манипуляции системой
⁉️ Каскадные атаки - неточные или противоречивые выходные данные LLM могут распространяться и усиливаться через последующие взаимодействия агентов в самой системе
⁉️ А также … Скрытый сговор – агенты могут начать сотрудничать для достижения целей, которые будут противоречить интересам пользователя.
Несоменно в своё видение угроз авторы добавили RAG, достаточно очевидно и можно согласиться.
Авторы также предложили пока что теоретические варианты митигаций:
Внедрять механизмы (пока что не агентов), которые бы смотрели наличие сговора.
Системы репутации и реестры на основе блокчейна, а также контроль доступа, зависимый от контекста самой агентой системы.
Да, пока что это выглядит слишком концептуально, да и честно сказать с трудом вериться в то, что LLM будет активно оценивать результаты других агентов. Но проблема становиться виднее.
Под IoA сейчас понимают инфраструктуру центричность которой поставлена на агентах, взаимодействие с ними вне рамках обычных сетей организаций а также чтобы они могли координированно выполнять задачи.
Для коммуникации между агентами в такой сети реализовано большое множество протоколов – самый известный MCP, но как правило – не единственный (подробнее на рис.1).
Мы должны понимать самое важное что в такой сети может использоваться множество LLM как ядра определённых систем, следовательно – они могут наследовать проблемы самих моделей. Важный фактор что такие системы пока что могут быть децентрализованными(рано или поздно будут регуляторы, реестры и т.д). И хоть кажется что реализация такой сети будет иметь большие преимущества(безусловно это так). Но риски ИБ тут никто не отменял.
В статье Security of Internet of Agents: Attacks and Countermeasures рассматривается некая модель угроз для такой площадки. IoA переваривает множество персональной информации, коммерческих данных и из-за этого вопрос безопасности аутентификации между агентными системами – является критически значимым.
В статье определяют несколько угроз:
Несоменно в своё видение угроз авторы добавили RAG, достаточно очевидно и можно согласиться.
Авторы также предложили пока что теоретические варианты митигаций:
Внедрять механизмы (пока что не агентов), которые бы смотрели наличие сговора.
Системы репутации и реестры на основе блокчейна, а также контроль доступа, зависимый от контекста самой агентой системы.
Да, пока что это выглядит слишком концептуально, да и честно сказать с трудом вериться в то, что LLM будет активно оценивать результаты других агентов. Но проблема становиться виднее.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Хотел написать пост об отчёте Pangea, но пришлось писать публикацию на хабр. Конкурс интересный, а количество участников - поражает.
https://habr.com/ru/articles/910334/
https://habr.com/ru/articles/910334/
Хабр
Комната Наверху и другие истории обхода LLM
В марте 2025, компания Pangea провела конкурс – в нём поучаствовали более 800 участников из разных стран. Суть в том, что было несколько комнат – лабораторных, где участникам необходимо было...
Forwarded from Борис_ь с ml
Итак, доклад по безопасности AI-агентов, MCP и A2A, который я прочитал с коллегой на Форуме "Технологии Доверенного ИИ"
#иб_для_ml
Файл вы найдете ниже под постом
Более того, я собираюсь сделать небольшую серию постов, согласно оглавлению доклада.
О чем же он был?
Во введении мы рассказали про понятие AI-агентов как таковых, немного раскрыли их отличие от просто чат-ботов или RAG. Привели определение мультиагентной системы и представили схему объектов защиты на основе модели угроз AI, представленной Сбербанком.
Далее раскрыли суть понятия MCP, конечно же со схемкой, и дали описание одной из возможных атак на этот протокол: Tool Poisoning Attack.
После чего - аналогично с A2A и атакой Privilege Escalation.
Главный интересный раздел - безопасность систем на стыке этих протоколов, пример атаки, эксплуатирующей их несогласованность, и главное - модель угроз для систем на протоколах MCP+A2A.
В качестве завершения - возможные меры защиты, мои выводы и пучок полезных ссылок по поводу)
Остаемся на связи, скоро расскажу про все подробнее.
#иб_для_ml
Файл вы найдете ниже под постом
Более того, я собираюсь сделать небольшую серию постов, согласно оглавлению доклада.
О чем же он был?
Во введении мы рассказали про понятие AI-агентов как таковых, немного раскрыли их отличие от просто чат-ботов или RAG. Привели определение мультиагентной системы и представили схему объектов защиты на основе модели угроз AI, представленной Сбербанком.
Далее раскрыли суть понятия MCP, конечно же со схемкой, и дали описание одной из возможных атак на этот протокол: Tool Poisoning Attack.
После чего - аналогично с A2A и атакой Privilege Escalation.
Главный интересный раздел - безопасность систем на стыке этих протоколов, пример атаки, эксплуатирующей их несогласованность, и главное - модель угроз для систем на протоколах MCP+A2A.
В качестве завершения - возможные меры защиты, мои выводы и пучок полезных ссылок по поводу)
Остаемся на связи, скоро расскажу про все подробнее.
Forwarded from OSINT mindset
Уже скоро OSINT mindset conference #7! А значит мы готовы представить наших спикеров: 🔥
sled_tut — Ваша мама в сетке: раскрываем неочевидные связи между телеграм-каналами
nicksinus — Портрет закладки
Adk — Gaming OSINT
crytech7 — Messages Sent to the Void: Tracking Transactions to Ethereum Null Address
Riaria — Как интернет, технологии и социальные сети портят жизнь тем, кто ворует искусство
Помимо докладов мы, как обычно, готовим для вас стенды LockPick и OSINT Village!🔍
Ждём всех 31 мая в 13:00 (UTC+3) в Благосфере, м. Динамо, 1-й Боткинский проезд, д. 7c1. Мероприятие полностью бесплатное, без регистрации и возрастного ограничения✨
Также если вы представитель СМИ или блогер и планируете посетить конференцию, чтобы в дальнейшем написать про неё, просим заполнить анкету.
🌐 Site | 💬 Forum | 🔍 Family |▶ YT
sled_tut — Ваша мама в сетке: раскрываем неочевидные связи между телеграм-каналами
nicksinus — Портрет закладки
Adk — Gaming OSINT
crytech7 — Messages Sent to the Void: Tracking Transactions to Ethereum Null Address
Riaria — Как интернет, технологии и социальные сети портят жизнь тем, кто ворует искусство
Помимо докладов мы, как обычно, готовим для вас стенды LockPick и OSINT Village!
Ждём всех 31 мая в 13:00 (UTC+3) в Благосфере, м. Динамо, 1-й Боткинский проезд, д. 7c1. Мероприятие полностью бесплатное, без регистрации и возрастного ограничения
Также если вы представитель СМИ или блогер и планируете посетить конференцию, чтобы в дальнейшем написать про неё, просим заполнить анкету.
Please open Telegram to view this post
VIEW IN TELEGRAM
ChatGPT – В С Ё.😁😁😁 Буквально позавчера Anthropic выпустили Claude 4, Sonnet & Opus. Новая модель. Лучше в агентах, лучше в рассуждениях. Но как дела с безопасностью?
Хотел бы начать с анализа системной карты. Но нет, чуть позже. Anthropic выпустили свой стандарт ASL(AI Safety Level-3). Стандарт основывается на двух ключевых компонентах – Методы развёртывания и методы безопасности. Практики, применяемые к ним, и формируют уровни. Anthropic присвоили своей модели 3й уровень, что говорит о высоком уровне защищённости. Хотя уже вчера в аккаунте Plini появилась информация о том, что можно всё-таки джейлбрейкнуть, он отмечает о том, что это стало сложнее – но метод 2024 года смог сработать.
Anthropic отмечают – что стандарт не является полностью сформированным. И даже говорят, что это предупредительная и временная мера.
Компания еще не определила окончательно, превысил ли Claude Opus 4 порог возможностей, требующий защиты ASL-3. Однако из-за продолжающегося улучшения знаний и возможностей, связанных с генерацией ответов на запросы про бомбу, Anthropic решила, что невозможно однозначно исключить риски ASL-3 для Claude Opus 4 так, как это было возможно для предыдущих моделей.
Стандарт интересный, описывают и интеграцию багбаунти и меры защиты в виде контроля Endpoint, жизненного цикла и мониторинга. Про ASL-3 можно написать один большой пост. Но я рекомендую вам ознакомиться с ним самостоятельно. Кстати, Claude 3.5 они оценивают на ASL-2. 2-й уровень включает базовую защиту от попыток кражи весов и подразумевается, что модель обучена говорить «нет» на опасные запросы.
Что было сделано в 4-й модели?
По сути, как они пишут – была доработана концепция Constitutional Classifiers — системы, где классификаторы в реальном времени, обученные на синтетических данных, отслеживают вредоносные запросы и отклоняют их. Модель проверяли на бенчмарке StrongREJECT, в качестве атакующей модели использовали Claude Sonnet 3.5, без alignment. Она генерировала джейлбрейки и, ожидаемо, показатели модели с точки зрения безопасности при таком подходе оценки – стали выше. Anthropic реализовали механизм быстрого устранение джейлбрейков. Модель генерирует синтетику на основе подозрительного ввода и на основании этого происходит дообучение классификаторов.
В системную карту также включили подробную оценку того как работает элаймент. Разные категории рисков: предвзятость, соответствие вредоносным инструкциям, скрытые намерения, и плохие рассуждения – всё это учитывается при элайменте.
Ну а в заключении хочется сказать про агентов. Anthropic говорят что они усилили безопасность модели с точки зрения применения как ядра агентной системы: Например реализовали механизмы оценки злонамеренного использования компьютера, классификатор доработали для защиты от инъекций – также при ComputerUseAgent mode. И конечно же постарались сделать безопасным вайб-кодинг. В плане того, что усилили механизм предотвращения вредоносной генерации кода агентами.
Хотел бы начать с анализа системной карты. Но нет, чуть позже. Anthropic выпустили свой стандарт ASL(AI Safety Level-3). Стандарт основывается на двух ключевых компонентах – Методы развёртывания и методы безопасности. Практики, применяемые к ним, и формируют уровни. Anthropic присвоили своей модели 3й уровень, что говорит о высоком уровне защищённости. Хотя уже вчера в аккаунте Plini появилась информация о том, что можно всё-таки джейлбрейкнуть, он отмечает о том, что это стало сложнее – но метод 2024 года смог сработать.
Anthropic отмечают – что стандарт не является полностью сформированным. И даже говорят, что это предупредительная и временная мера.
Компания еще не определила окончательно, превысил ли Claude Opus 4 порог возможностей, требующий защиты ASL-3. Однако из-за продолжающегося улучшения знаний и возможностей, связанных с генерацией ответов на запросы про бомбу, Anthropic решила, что невозможно однозначно исключить риски ASL-3 для Claude Opus 4 так, как это было возможно для предыдущих моделей.
Стандарт интересный, описывают и интеграцию багбаунти и меры защиты в виде контроля Endpoint, жизненного цикла и мониторинга. Про ASL-3 можно написать один большой пост. Но я рекомендую вам ознакомиться с ним самостоятельно. Кстати, Claude 3.5 они оценивают на ASL-2. 2-й уровень включает базовую защиту от попыток кражи весов и подразумевается, что модель обучена говорить «нет» на опасные запросы.
Что было сделано в 4-й модели?
По сути, как они пишут – была доработана концепция Constitutional Classifiers — системы, где классификаторы в реальном времени, обученные на синтетических данных, отслеживают вредоносные запросы и отклоняют их. Модель проверяли на бенчмарке StrongREJECT, в качестве атакующей модели использовали Claude Sonnet 3.5, без alignment. Она генерировала джейлбрейки и, ожидаемо, показатели модели с точки зрения безопасности при таком подходе оценки – стали выше. Anthropic реализовали механизм быстрого устранение джейлбрейков. Модель генерирует синтетику на основе подозрительного ввода и на основании этого происходит дообучение классификаторов.
В системную карту также включили подробную оценку того как работает элаймент. Разные категории рисков: предвзятость, соответствие вредоносным инструкциям, скрытые намерения, и плохие рассуждения – всё это учитывается при элайменте.
Ну а в заключении хочется сказать про агентов. Anthropic говорят что они усилили безопасность модели с точки зрения применения как ядра агентной системы: Например реализовали механизмы оценки злонамеренного использования компьютера, классификатор доработали для защиты от инъекций – также при ComputerUseAgent mode. И конечно же постарались сделать безопасным вайб-кодинг. В плане того, что усилили механизм предотвращения вредоносной генерации кода агентами.
Жизненный цикл, данные и АНБ. Новый американский стандарт описывает лучшие практики по защите данных для AI. И, наверное, все мы понимаем базовое вроде «не должно быть перекоса в данных», «должен быть контроль доступа и очистка». Но как видит это АНБ? Тут всё не так уж и однозначно.
Это не фреймворк, в классическом понимании. Но что-то схожего тут есть – например рассматривают меры для жизненного цикла данных, раскладывают его по полочкам.
Как отмечается в документе, успешные стратегии управления данными должны гарантировать, что данные не были подвергнуты несанкционированному изменению на любом этапе жизненного цикла ИИ, не содержат вредоносного, а также не имеют непреднамеренной дублирующей или информации, которая может быть аномалией.
NSA определяет следующие риски:
1.Цепочка поставок. Тут кристально понятно. Они, кстати, приводят в пример кейс с отравлением википедии, когда злоумышленник вносит вредоносные правки непосредственно перед тем, как сайты с краудсорсинговым контентом делают снимок своих данных. Также уделили внимание на своей аналитике – отравление датасета LAION-2B – для злоумышленника может стоить от 60$ до 1000, а эффект будет большой.
2. Предвзятость, состязательные примеры, искажающие процесс обучения, проблемные метаданные и некачественный датасет – всё это относят ко второму типу угроз,
3. Дрейф данных. Хотя документ упоминает дрейф данных как один из рисков безопасности данных на некоторых этапах жизненного цикла, подробное описание этого риска и стратегий его снижения в документе отсутствует.
Между этим как мне кажется можно было бы определить угрозы, связанные с синтетикой, а может и нет … всё-таки ж речь про безопасность. К этим рискам они отнесли рекомендации:
NSA дают общие рекомендации:
1.Использование надежных источников данных и отслеживание происхождения
2.Проверка и поддержание целостности данных
3. Использование цифровых подписей
4. Использование доверенной инфраструктуры
5. Классификация данных и контроль доступа
6. Шифрование данных (AES-256)
7. Безопасное хранение данных (должны храниться на устройствах, соответствующих NIST FIPS 140–3)
8. Методы сохранения конфиденциальности (Дифференциальная приватность, федеративное обучение)
9. Безопасное удаление данных (в соответствии с NIST SP 800-88)
10. Проводить регулярную оценку безопасности данных (также в соответствии с NIST SP 800-3r2 и NIST AI 100-1)
По их мнению, да и по лучшим стандартам сейчас для цепочки поставок можно реализовывать хеширование данных, регулярно смотреть целостность.
ну а ссылка вот.
Это не фреймворк, в классическом понимании. Но что-то схожего тут есть – например рассматривают меры для жизненного цикла данных, раскладывают его по полочкам.
Как отмечается в документе, успешные стратегии управления данными должны гарантировать, что данные не были подвергнуты несанкционированному изменению на любом этапе жизненного цикла ИИ, не содержат вредоносного, а также не имеют непреднамеренной дублирующей или информации, которая может быть аномалией.
NSA определяет следующие риски:
1.Цепочка поставок. Тут кристально понятно. Они, кстати, приводят в пример кейс с отравлением википедии, когда злоумышленник вносит вредоносные правки непосредственно перед тем, как сайты с краудсорсинговым контентом делают снимок своих данных. Также уделили внимание на своей аналитике – отравление датасета LAION-2B – для злоумышленника может стоить от 60$ до 1000, а эффект будет большой.
2. Предвзятость, состязательные примеры, искажающие процесс обучения, проблемные метаданные и некачественный датасет – всё это относят ко второму типу угроз,
3. Дрейф данных. Хотя документ упоминает дрейф данных как один из рисков безопасности данных на некоторых этапах жизненного цикла, подробное описание этого риска и стратегий его снижения в документе отсутствует.
Между этим как мне кажется можно было бы определить угрозы, связанные с синтетикой, а может и нет … всё-таки ж речь про безопасность. К этим рискам они отнесли рекомендации:
NSA дают общие рекомендации:
1.Использование надежных источников данных и отслеживание происхождения
2.Проверка и поддержание целостности данных
3. Использование цифровых подписей
4. Использование доверенной инфраструктуры
5. Классификация данных и контроль доступа
6. Шифрование данных (AES-256)
7. Безопасное хранение данных (должны храниться на устройствах, соответствующих NIST FIPS 140–3)
8. Методы сохранения конфиденциальности (Дифференциальная приватность, федеративное обучение)
9. Безопасное удаление данных (в соответствии с NIST SP 800-88)
10. Проводить регулярную оценку безопасности данных (также в соответствии с NIST SP 800-3r2 и NIST AI 100-1)
По их мнению, да и по лучшим стандартам сейчас для цепочки поставок можно реализовывать хеширование данных, регулярно смотреть целостность.
ну а ссылка вот.
Не очень часто что-то нахожу/публикую интересное по форензике моделей. Да и вообще по тому, как расследовать инциденты в организации, если взломали через какую-то заражённую ML-модель. Поэтому исправляюсь. Предлагаю Вам немного полезного материала по этой теме.
1. NullfiAI, атака доказывающая, что средства защиты могут быть бесполезными. Давняя статья, я даже писал о ней - суть в том, что исследователи рассказали о том, как можно замалварить пикл, да так чтобы сканеры не отрабатывали.
2. Цепочка поставок - большая беда. ReversingLabs также недавно провели анализ PyPi и, к сожалению, обнаружили вредоносную ML-библиотеку. Это не первый похожий случай.
3. Кажется, что подходы классической безопасности хорошо подходят для анализа моделей - но уж нет. Авторы статьи "Gaps in Traditional DFIR Playbooks: Machine Learning Models" рассматривают особенности процесса на примере анализа onnx.
4. От авторов предыдущей статьи есть также публикация про расследование с ml-артефактами . Хорошее чтение с реальным примером.
Только ли в сериализации беда?
Вам может показаться после прочтения статьей что сериализация является важным источником угроз для ML. Частично это да. Для неё уже есть много крутых инструментов, flickling, к примеру. Хотя мы ни в коем случае не должны забывать про MLOps ландшафт, область, где модель храниться, хранит свои данные. Тут в большинстве случаев вам порекомендуют анализировать логи MLOps решений, DVC и кто делает коммиты в GIT. В целом вам также может понадобиться понимание ответа на вопрос "какие форматы датасетов" существуют? и тут тоже есть полезный ресурс - храним, запоминаем.
1. NullfiAI, атака доказывающая, что средства защиты могут быть бесполезными. Давняя статья, я даже писал о ней - суть в том, что исследователи рассказали о том, как можно замалварить пикл, да так чтобы сканеры не отрабатывали.
2. Цепочка поставок - большая беда. ReversingLabs также недавно провели анализ PyPi и, к сожалению, обнаружили вредоносную ML-библиотеку. Это не первый похожий случай.
3. Кажется, что подходы классической безопасности хорошо подходят для анализа моделей - но уж нет. Авторы статьи "Gaps in Traditional DFIR Playbooks: Machine Learning Models" рассматривают особенности процесса на примере анализа onnx.
4. От авторов предыдущей статьи есть также публикация про расследование с ml-артефактами . Хорошее чтение с реальным примером.
Только ли в сериализации беда?
Вам может показаться после прочтения статьей что сериализация является важным источником угроз для ML. Частично это да. Для неё уже есть много крутых инструментов, flickling, к примеру. Хотя мы ни в коем случае не должны забывать про MLOps ландшафт, область, где модель храниться, хранит свои данные. Тут в большинстве случаев вам порекомендуют анализировать логи MLOps решений, DVC и кто делает коммиты в GIT. В целом вам также может понадобиться понимание ответа на вопрос "какие форматы датасетов" существуют? и тут тоже есть полезный ресурс - храним, запоминаем.
В конце мая исследователи из ReversingLabs обнаружили атаку на цепочку поставок, распространяющуюся на разработчиков, которые использовали Alibaba AI Labs.
Злоумышленники загрузили в PyPI три вредоносных пакета, маскирующихся под официальные SDK для взаимодействия с сервисами Alibaba Cloud AI Labs:
1.aliyun-ai-labs-snippets-sdk
2.ai-labs-snippets-sdk
3.aliyun-ai-labs-sdk
Пакеты были доступны с 19 мая, в течение 24 часов до обнаружения. И за это время они были загружены примерно 1600 раз. Наибольшее количество загрузок пришлось на пакет ai-labs-snippets-sdk, который был доступен дольше остальных.
Сами по себе пакеты вовсе не содержали функциональности связанной с AI или взаимодействием с серверами Alibaba, а вредоносный код был скрыт в Pickle. Заражение происходило через __init__.py, который загружал вредоносные pickle.
Какая информация отправлялась злоумышленникам при запуске Pickle:
1. Данные о хосте, сетевом адресе машины
2. Название организации
3. Содержимое. gitconfig
4. Также происходила идентификация разработчиков, которые используют инструмент AliMeeting
Собранная информация отправлялась в base64 на сервера злоумышленников.
Злоумышленники загрузили в PyPI три вредоносных пакета, маскирующихся под официальные SDK для взаимодействия с сервисами Alibaba Cloud AI Labs:
1.aliyun-ai-labs-snippets-sdk
2.ai-labs-snippets-sdk
3.aliyun-ai-labs-sdk
Пакеты были доступны с 19 мая, в течение 24 часов до обнаружения. И за это время они были загружены примерно 1600 раз. Наибольшее количество загрузок пришлось на пакет ai-labs-snippets-sdk, который был доступен дольше остальных.
Сами по себе пакеты вовсе не содержали функциональности связанной с AI или взаимодействием с серверами Alibaba, а вредоносный код был скрыт в Pickle. Заражение происходило через __init__.py, который загружал вредоносные pickle.
Какая информация отправлялась злоумышленникам при запуске Pickle:
1. Данные о хосте, сетевом адресе машины
2. Название организации
3. Содержимое. gitconfig
4. Также происходила идентификация разработчиков, которые используют инструмент AliMeeting
Собранная информация отправлялась в base64 на сервера злоумышленников.
Forwarded from Alaid TechThread
Наш подход к генерации патчей для уязвимых зависимостей в Docker-образах
https://vk.com/video-28022322_456241194
#safeliner
https://vk.com/video-28022322_456241194
#safeliner
VK Видео
Контроль зависимостей на автопилоте AI-ассистент на страже Dockerfile
В докладе будет разобран наш опыт создания и интеграции LLM-агента, исправляющего уязвимости в контейнерных образах. Вы узнаете, почему Dependabot и Renovate не решают все ваши проблемы. Мы расскажем о нашем подходе, а также о том, сколько уязвимостей можно…
Forwarded from Борис_ь с ml
Гайд по AI-агентам с мерами митигации угроз кибербезопасности
#иб_для_ml
↗️ https://cdn-app.giga.chat/misc/0.0.0/assets/giga-landing/c02386dc_WP.pdf
✅ Команда Сбера представила новый документ - гайд по практикам разработки AI-агентов. В документе масса кода и архитектурных схем, разбираться можно долго. И я однозначно рекомендую его к ознакомлению.
Но мне, конечно интересна в первую очередь кибербезопасность. И да, такой раздел в этом документе имеется. Внимание на страницы 65-69.
📝 Раскрываемые темы и понятия в разделе
▪️ описание ключевых с точки зрения ИБ элементов AI-агента
▪️ схема этих элементов, изображающая AI-агента как объект защиты, приведен список поверхностей атаки
▪️ несколько сценариев реализации угроз (например, каскадное распространение промпт-атаки)
▪️ меры обеспечения кибербезопасности AI-агентов - самое интересное, на чем остановимся подробнее
🔒 Как защитить AI-агентов
На странице 69 расписано 12 различных мер.
Начинаем, конечно, с мониторинга. AI-агенты, как мы помним, сами по себе моделями не являются, соответственно ответы пользователям генерить не могут. Поэтому существуют обращения агентов к LLM, при чем как минимум - два. Первое с исходным входным текстом, чтобы сгенерировать запрос на выполнение действия (-й), второе - с результатом выполнения для генерации финального ответа. И это, по-хорошему, все надо логировать. Начиная от id потребителя и, в случае большой корпоративной системы, id фронтальной поверхности, заканчивая id сессии и id актуального коммита в памяти AI-агента на момент совершения события аудита.
Другой хорошей практикой (мерой), особенно в критичных системах, является ограничение формата вывода агентов со свободного естественного языка до набора детерминированных значений. Поможет и утечек избежать, и распространения промпт-атак, и других нежелательных последствий.
Собраны и некоторые общеизвестные, по-моему, вещи, но все-таки стоящие упоминания: проводить redteam-тестирование, ввести максимально жесткий контроль доступа, применять SAST/SCA к генерируемому агентами исполняемому коду, организовать рейтлимиты и прочие контроли надежности против спонж-атак, и несколько других пунктов.
И еще отдельно отмечу простое и при этом мне показавшееся, когда я увидел, неочевидным, правило: отслеживайте наличие в системном промпте любых секретов. Это могут быть ключи, токены, имена баз данных или учеток, словом - всего, что не нужно знать потребителю AI-агента. Потому что нельзя забывать - системный промпт модель обязательно расскажет(ее хлебом не корми - дай системник рассказать) , а значит, его инфу можно считать заведомо утекшей.
👀 Итого
Берегитечесть безопасность AI-агентов смолоду с ранних этапов проектирования - эта прописная истина работает и тут. И авторы дают конкретные предложения, как именно это делать. Документ отлично дополняет показанную в апреле модель угроз, покрывая агентную ее часть.
🔫 Предлагаю челлендж - будет больше 50 реакций под постом, сделаю свою версию маппинга угроз из МУ Сбера на митигации из данного гайда.
#иб_для_ml
Но мне, конечно интересна в первую очередь кибербезопасность. И да, такой раздел в этом документе имеется. Внимание на страницы 65-69.
На странице 69 расписано 12 различных мер.
Начинаем, конечно, с мониторинга. AI-агенты, как мы помним, сами по себе моделями не являются, соответственно ответы пользователям генерить не могут. Поэтому существуют обращения агентов к LLM, при чем как минимум - два. Первое с исходным входным текстом, чтобы сгенерировать запрос на выполнение действия (-й), второе - с результатом выполнения для генерации финального ответа. И это, по-хорошему, все надо логировать. Начиная от id потребителя и, в случае большой корпоративной системы, id фронтальной поверхности, заканчивая id сессии и id актуального коммита в памяти AI-агента на момент совершения события аудита.
Другой хорошей практикой (мерой), особенно в критичных системах, является ограничение формата вывода агентов со свободного естественного языка до набора детерминированных значений. Поможет и утечек избежать, и распространения промпт-атак, и других нежелательных последствий.
Собраны и некоторые общеизвестные, по-моему, вещи, но все-таки стоящие упоминания: проводить redteam-тестирование, ввести максимально жесткий контроль доступа, применять SAST/SCA к генерируемому агентами исполняемому коду, организовать рейтлимиты и прочие контроли надежности против спонж-атак, и несколько других пунктов.
И еще отдельно отмечу простое и при этом мне показавшееся, когда я увидел, неочевидным, правило: отслеживайте наличие в системном промпте любых секретов. Это могут быть ключи, токены, имена баз данных или учеток, словом - всего, что не нужно знать потребителю AI-агента. Потому что нельзя забывать - системный промпт модель обязательно расскажет
Берегите
Please open Telegram to view this post
VIEW IN TELEGRAM
Кому-то точно нужен был чек-лист для llm governance. Так вот я нашел полезную статью по теме.
https://www.newline.co/@zaoyang/checklist-for-llm-compliance-in-government--1bf1bfd0
Кажется вроде как базой, но что удобно - так это то что все в одном месте - законы, процесс, и кто сколько может заплатить за несоблюдение мер, но в разных странах. Конечно тут речь не про технику, но куда уж без комплаенса.🤪
https://www.newline.co/@zaoyang/checklist-for-llm-compliance-in-government--1bf1bfd0
Кажется вроде как базой, но что удобно - так это то что все в одном месте - законы, процесс, и кто сколько может заплатить за несоблюдение мер, но в разных странах. Конечно тут речь не про технику, но куда уж без комплаенса.
Please open Telegram to view this post
VIEW IN TELEGRAM
newline
Checklist for LLM Compliance in Government | newline
Deploying AI in government? Compliance isn’t optional. Missteps can lead to fines reaching $38.5M under global regulations like the EU AI Act - or worse, erode public trust. This checklist ensures your government agency avoids pitfalls and meets ethical standards…
В последнее время анализируя множество исследований, статьей по теме - ощущаю нехватку того что меры которые предлагаются для защиты не содержат как правило проактивного характера.
У нас есть классический cyberkillchain. Mitre попытались отобразить его в своём фреймворке Atlas - несколько этапов от начального рекона до эксфильтрации и т.д. Это круто, но как мне кажется - знания о защите должны также быть, не хуже да и вообще быть изложены в структурированном виде. А то всё об угрозах да и об угрозах - а как защищать, когда атака уже идёт ? Говорить "не использовать MLFlow, потому что уязвимо" или другое решение выглядит обсурдным.
Н А Д О Е Л О
Поэтому с начала марта я задумался о том как можно было бы представить anti cyberkillchain, да так чтобы он ещё укладывался в ландшафт ML.
я закомитил свои наработки по теме сюда
https://github.com/wearetyomsmnv/ML-Defense-Matrix
это матрица противодействия разным этапам, как мне самому кажется - это очень верхнеуровневый документ, его определённо надо дорабатывать с коллегами которые строят защиту - поэтому призываю вас принять участие, дать комменты(только обоснованные) - чтобы сделать проактивную защиту ML лучше. Не всегда можно покрыть риски только на этапе разработки. Это печалит.
О чём документ: В нём я изложил меры по защите(очень поверхностно, думаю буду прорабатывать их в соответствии с публикациям на arxiv) которые можно использовать на разных этапах - защита от разведки, защита от исполнения кода и тд. В перспективе добавить тему уже услышанную всеми - это агенты.
Инциденты уже шагают, угрозы уже изучены и задокументированы - но вот защита ... С этим всё слабо кмк. Прошу репост, тех кто заинтересован в развитии такой истории.
У нас есть классический cyberkillchain. Mitre попытались отобразить его в своём фреймворке Atlas - несколько этапов от начального рекона до эксфильтрации и т.д. Это круто, но как мне кажется - знания о защите должны также быть, не хуже да и вообще быть изложены в структурированном виде. А то всё об угрозах да и об угрозах - а как защищать, когда атака уже идёт ? Говорить "не использовать MLFlow, потому что уязвимо" или другое решение выглядит обсурдным.
Н А Д О Е Л О
Поэтому с начала марта я задумался о том как можно было бы представить anti cyberkillchain, да так чтобы он ещё укладывался в ландшафт ML.
я закомитил свои наработки по теме сюда
https://github.com/wearetyomsmnv/ML-Defense-Matrix
это матрица противодействия разным этапам, как мне самому кажется - это очень верхнеуровневый документ, его определённо надо дорабатывать с коллегами которые строят защиту - поэтому призываю вас принять участие, дать комменты(только обоснованные) - чтобы сделать проактивную защиту ML лучше. Не всегда можно покрыть риски только на этапе разработки. Это печалит.
О чём документ: В нём я изложил меры по защите(очень поверхностно, думаю буду прорабатывать их в соответствии с публикациям на arxiv) которые можно использовать на разных этапах - защита от разведки, защита от исполнения кода и тд. В перспективе добавить тему уже услышанную всеми - это агенты.
Инциденты уже шагают, угрозы уже изучены и задокументированы - но вот защита ... С этим всё слабо кмк. Прошу репост, тех кто заинтересован в развитии такой истории.
GitHub
GitHub - wearetyomsmnv/ML-Defense-Matrix: Mitre Atlas counter-attack techniques
Mitre Atlas counter-attack techniques. Contribute to wearetyomsmnv/ML-Defense-Matrix development by creating an account on GitHub.
В прошлом году Google выпустили исследование в котором показали как при помощи агентов искать zero days. Тогда была найдена проблема с sqlite3, критическая и быстро закрытая уязвимость.
Но уже в конце мая исследователь из Оксфорда опубликовал исследование в котором при помощи o3, без агентов и инструментов ему также удалось найти нолик, но уже в ядре линукса.
Уязвимости был присвоен CVE-2025-37899. Уязвимость позволяет удаленно выполнить код за счёт Use-after-free в SMB 'logoff'. Только доступ к апи, ничего больше. Наверное это первый публичный кейс когда ноль был обнаружен в ядре, да и как говорит автор - если можно закинуть 10к строк кода, то о3 справиться или поможет справиться.
На уязвимость уже вышел патч.
https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/
Но уже в конце мая исследователь из Оксфорда опубликовал исследование в котором при помощи o3, без агентов и инструментов ему также удалось найти нолик, но уже в ядре линукса.
Уязвимости был присвоен CVE-2025-37899. Уязвимость позволяет удаленно выполнить код за счёт Use-after-free в SMB 'logoff'. Только доступ к апи, ничего больше. Наверное это первый публичный кейс когда ноль был обнаружен в ядре, да и как говорит автор - если можно закинуть 10к строк кода, то о3 справиться или поможет справиться.
На уязвимость уже вышел патч.
https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/
Sean Heelan's Blog
How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation
In this post I’ll show you how I found a zeroday vulnerability in the Linux kernel using OpenAI’s o3 model. I found the vulnerability with nothing more complicated than the o3 API ̵…
Фреймворков для тестирования моделей уже достаточно много на рынке. Но куда они движутся ? Что их объединяет и какие особенности преследует каждый из них.
В этой статье я изложил некоторую аналитику по этой части, но чтобы текст не казался техническим насилием при прочтении - я изложил его в формате гонзо журналистики. Приятного чтения
В этой статье я изложил некоторую аналитику по этой части, но чтобы текст не казался техническим насилием при прочтении - я изложил его в формате гонзо журналистики. Приятного чтения
Хабр
Лаборатория Безумного Ученого: Хроники Четырех Экспериментов повлиявших на представление об обеспечении безопасности ИИ
Дата: 11 мая 2025 Жанр: Гонзо-журналистика Записки исследователя, проникшего в тайные лаборатории создателей инструментов безопасности ИИ Дорогие читатели, то, что я собираюсь вам рассказать, звучит...