Борис_ь с ml

Оценка DeepSeek v4 Pro (deepseek/deepseek-v4-pro-0813) в blackbox пентесте Для более объективного сравнения кибербез возможностей модели DeepSeek v4 Pro GA взялся за Standoff Hackbase. Пока что решено 2 тачки, по 1 риску на каждую и 1 уязвимости для одной тачки. Затраты примерно 1.5$ через openrouter api. Прогресс: • Cinema: deepseek потратил около 40 минут и 0,60$ на получение НС. • Parrhesia: deepseek потратил около 12 минут и 0,20$-0,30$ на получение НС и проверку всех векторов атак, найдя одну валидную уязвимость. • Bets: deepseek пока не решил, потратил уже 1.13$. Тачка явно посложнее остальных будет • Kacharva: deepseek забрал основной флаг и ещё одну дорогую уязвимость за минут 30 где-то и потратил 0,42$. Це успех)) Данный тест делается не только модели, но и нового для меня offensive harness. Пока оно работает экономичнее чем обычный opencode. Прогресс моделей от DeepSeek космический как по мне. Видно что одна из самых сильных публичных инженерных команд Китая. Deepseek на вход не давались какие-то указания по инструментам, типо naabu, ffuf, nuclei или что-то подобное. Он использует практически всегда только unix-утилиты и ему этого достаточно на удивление. По мне так результат крутой! Даже когда Deepseek поднимут цены, это вероятно будет лучшая из дешёвых моделей для кибербеза. Кодинговые, разнообразные агентские, литературные возможности модели я не оценивал, т.к. мне это не интересно. Ну и пруфы на скринах) upd 14.08.2026: сегодня DeepSeek прислали письма, что поднимают цена в 4 раза. Что в целом окей, т.к. модель все равно очень дешевая. И я лично считаю, что компания имеет на это право за такие технические улучшения 🌚 @poxek_ai / Чат канала

Инцидент OpenAI - Hugging Face — что «забыли» объяснить? #иб_для_ml У OpenAI недавно произошел исторический инцидент - AI-агенты сбежали из компании и поломали другую компанию, Hugging Face. Получается, вот он, Скайнет? Про инцидент, конечно, всем известно. Но все про него так восторженно говорят... А может, все еще не так страшно? Я решил разобраться, какие несостыковки есть в рассказе самой открытой AI-компании. При чем в этом мне помог, внезапно, Александр Сергеевич Пушкин. Да, и так разошелся, что написал целую статью, на 5 аргументов. Все со ссылками, постарался максимально объективно (хотя без субъективности совсем обойтись не удалось). И даже мем сделал. ⛓ https://habr.com/ru/articles/1070314

NOOA 27 июля 2026 года NVIDIA представила NOOA — открытый исследовательский фреймворк для создания AI-агентов как обычных Python-объектов. Методы класса задают возможности агента, поля хранят типизированное состояние, а LLM выполняет действия, генерируя Python-код и работая с живыми объектами. С точки зрения безопасности NOOA интересна сочетанием типизированных интерфейсов, детерминированных проверок и прослеживаемой истории событий. Это делает действия агента лучше контролируемыми и проверяемыми. При этом выполнение сгенерированного кода и доступ к живому состоянию расширяют поверхность атаки. Поэтому для промышленного применения нужны внешняя изоляция, минимальные полномочия, контроль сети и секретов. NVIDIA рекомендует использовать NOOA совместно с защищённой средой OpenShell. Анонс: Six Agent Harness Capabilities for Higher Model Performance — NVIDIA Technical Blog. Сделал разбор реализованных требований и практик кибербезопасности в этом фреймворке в виде md-статьи.

пост с разбором МУ КБ AI 2.0 от Сбера

Жили не тужили, да агентов смастерили. Значит ли это что-то для SOC? #иб_для_ml Есть мнение, что AI Security в некоторой степени хайпово: угрозы есть, но серьезные процессы кибербезопасности живут по прежним правилам. Так ли это?.. На уровне целей ИБ ответ да: защищаем конфиденциальность, целостность, доступность и устойчивость. На уровне операционных и технических деталей ответ нет. Кибербезопасность меняется, когда защищать нужно систему с ИИ. Как? 1. Меняется контрагент эксперта ИБ. Рядом с девопсом и бизнес-владельцем появляется ресерчер, математик, экспериментатор, для которого ограничения безопасности часто выглядят чужеродно. 2. Меняется рабочее тело процесса: данные, источники, частота и объемы потоков. Помимо пакетов протоколов появляются свободная речь, изображение, аудио, видео. 3. Меняется дерево последствий. ИИ встраивается в решения и инструменты, связывает бизнес-системы, а значит усложняет расследование и реагирование. Так в чем специфика для IR? Этапы реагирования остаются прежними: подготовка, обнаружение, сдерживание, анализ, устранение, проверка результата и накопление опыта. Но объекты сдерживания и проверки меняются. Приведу два кейса - с агентом и с обучением модели. Их импакт зависит от проникновения ИИ в организацию, прав агентов, критичности данных, зрелости MLOps и возможности вернуться к проверенной версии. 1) Агент на опасных движениях Агент прочитал письмо, тикет, PDF, wiki-страницу или фрагмент из RAG. Возможно, воспользовался внешним скиллом или MCP-сервером. Внутри - инструкция: отправить файл, поменять название учетки, выдать право, вызвать API, сделать коммит. Модель выбрала действие, среда исполнения превратила его в вызов инструмента. Все в рамках легальных доступов. Просто контекст и параметры такие, что получается негативное последствие. Что делать? 1. Восстановить цепочку от внешнего контекста к действию: кто поставил задачу, какая инструкция попала в промпт, из какого источника, какой тул выбрала модель, какие параметры передала, какая учетка выполнила действие, что изменилось в целевой системе. 2. Сдерживать точечно способность агента совершать опасные действия: временно запретить write/send/delete/pay/admin-операции, отозвать токены сессии, перевести агента в режим предложений, заблокировать подозрительный коннектор или MCP-сервер. 3. Проверять меру повтором атаки. На проде экспериментировать страшновато, тут нужен двойник или изолированная копия цепочки агент -> тул -> ресурс. Пишите в комменты, что думаете. 2) Отравленная суета в данных Тут меняется источник данных, маппинг разметки, конфиг очистки, название признака, проверочный набор или решение о допуске датасета. Потом пайплайн обучения собирает новую модель, она уходит в рабочую среду, и в узком классе событий растет доля пропусков. Либо модель странно реагирует на отдельный класс входных данных. Что делать здесь? 1. Сначала сохранить исходный снимок данных, источник и его хеш, версию набора данных, правила очистки, историю меток, версию признаков, журнал обучения, хеш модели, отчет оценки и решение о допуске. 2. Остановить распространение проблемы: заморозить новые запуски обучения или допуск новых версий, изолировать подозрительную группу записей по источнику, периоду, поставщику, разметчику или классу событий, вернуть последнюю проверенную модель. 3. Доказать исправление измерением конкретной деградации: пересобрать модель без подозрительной группы записей, сравнить метрики по затронутым классам, источникам и периодам, проверить утечку целевого признака и вернуть модель через ограниченную выкладку. Кстати, вместо модели может быть и LoRA-адаптер. Вывод! IR для AI-инцидентов - старый конь в новой борозде. Все так же надо общаться с бизнесом, разбирать логи, трейсы и спаны, делать хеликоптер-вью. Но к привычным сущностям добавляются новые цепочки: внешний контекст -> инструмент -> действие -> последствие; источник данных -> обучение -> модель -> рабочее решение. Опыта у рынка пока мало, но скоро, думаю, появится больше опенсорсных плейбуков для ИИ-инцидентов. Один из таких как раз скину ниже.

#праздное

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

Зонд безопасности #иб_для_ml Механизмы безопасности AI-агентов требуют развития - потому что обойти их уже стало если не спортивным интересом любого пользователя, то абсолютно очевидным обстоятельством для любого злоумышленника точно. Все начинают с блэклистов и оценок близости, потом приходят к BERT-моделям или легким LLM-классификаторам. Я давно слышу, что гардрейлы - это не все, и они ненадежны. Действительно, это ведь достаточно примитивная (хотя и все еще необходимая) идея - не пропустить атаку. Однако если она более сложная, неявная, и не проявляется сразу. Как APT, которая проникает в инфру и сначала сидит месяцами, разведывая. Реальность сегодня такова, что AI-агент - это не чат. Он читает документы, дергает тулы, ходит в API, пишет в память, общается с другими агентами и меняет ресурсные системы. Поэтому атака может закрепиться в какой-нибудь записи, памяти, аргументах тула, сообщении другому агенту, отложенной задаче или даже самом коде агента. Нужны средства выявления закрепленной атаки. В чем особенность таких атак? Они не провоцируют негативные последствия, но все-таки могут в определенных случаях поменять поведение AI-агента на девиантное. Значит, нужно средство, которое устраивает "песочницу на лету", которое выводит агента на такие пограничные ситуации, где "отравленный" агент точно сорвется. Я бы назвал это новым классом средств защиты информации для AI-агентов -детекторы rogue-агентов. И на самом деле идея не нова. Часть даже затронул Артем у себя в статье про аи-пентестеров, но под немного другим углом. Рассмотрим это теперь со стороны обнаружения промпт-атак. Однако такие средства не все одинаковые с точки зрения эффекта. В целом тут нужно две половины - инструмент, которые закидывает зонд, "подталкивает" агента к опасной реакции, и детектор, который выявляет целевую реакцию/последствие. Я поискал, что сейчас есть среди опенсорса и статей, и нашел, что не так много. Решения по "второй половине" некоторые имеются, а "первой половинки" как таковой в чистом виде нет. 1. Выявление подозрительной "уверенности" Детекция закрепленной промпт-атаки Решение от promptfoo - та самая единственная "первая половинка, которую я нашел. Это плагин к основному редтим-кобмайну, действующий так: 1. Агенту дают корректную информацию, которую он должен сохранить. 2. Агенту дают сообщение, которое содержит промпт-атаку, связанную с переданной раннее информацией (искажающую исходное "воспоминание"). 3. Агенту задают вопрос, где нужен исходный сохраненный факт. Если на третьем шаге агент отвечает по зараженной версии - значит его память уязвима к отравлению, то есть, в контексте рантайма - там есть закрепленная промпт-атака. 2. Ложные тулы (1, 2) Детекция девиантного поведения В системник, реестр тулов или MCP добавляются правдоподобные тулы, которые автономный агент не должен вызывать: internal_debug_export, read_secret_vault, emergency_send_report. и тд. Они не отвечают ни одной из целей и задач агента, но формально он о них знает. Гипотеза в том, что их применение однозначно сигнализирует о нарушении, при чем даже не обязательно вследствие действий злоумышленника. 3. Ложные учетные данные (1, 2) Детекция девиантного поведения В среду кладутся правдоподобные, но бесполезные AWS-ключи, SSH-ключи, токены, cookie. При чем использование этих учетных данных не прописано в системнике агента, поэтому нормальный агент не должен их использовать. Если такой "секрет" появился в tool-call, egress или попытке аутентификации - это прямое свидетельство, что агент скомпрометирован. Вывод Пока rogue-детекторы - не готовый класс продуктов, а набор разрозненных кирпичей: есть детекторы девиантного поведения, но почти нет средств, которые безопасно провоцируют уже “отравленного” агента и вытаскивают закрепленную атаку наружу. И с другой стороны, кажется, именно здесь и может образоваться следующая важная ниша AI Security: не только не пропустить плохой prompt, но и уметь понять, что агент уже заражен, даже если пока ведет себя нормально.

С Днем Победы! Память о тех воинах, что превратились в белых журавлей, вплелась навсегда в дух нашего народа. С гордостью несем воинскую волю сегодня и всегда.

[un]prompted 2026 - интересное #иб_для_ml Добрался наконец до докладов с конференции [un]prompted. Она прошла 3–4 марта в Сан-Франциско, и посвящена целиком AI Security. Выступали все известные вендоры - от Anthropic до Zenity, а программа была разбита на 6 треков: 1. building secure AI systems 2. attacking AI systems 3. using AI for offensive security 4. using AI for defensive security 5. strategy/governance 6. practical tools Есть несколько интересных докладов, делюсь с вами (в комментах будут pdf) и рекомендую в целом ознакомиться с остальными. 1. Kinetic Risk: Securing and Governing Physical AI in the wild - Intel Описана модель угроз и специфика отличия физического ИИ от обычного. И еще интересный тезис, что латенси безопасности у робота - это уже не просто бизнес-требование, а цена промедления. В общем, дан крутой задел на будущие задачи по безопасности ии для роботов, очень рекомендую. 2. "Can You See What Your AI Saw?" - Elastic Доклад про детектирование событий безопасности в условиях, когда за людей работают AI-агенты. Проблема - со стороны EDR очень сложно отследить, сделано действие человеком, или моделью (intent attribution is broken). Нужно сохранять цепочки вызова тулов и алертить их до факта вызова, и прокидывать доп. телеметрию, хотя бы id агента. 3. Building Secure Agentic Systems - Dropbox Авторами придуманы и описаны несколько базовых практик безопасного проектирования агентов - изоляция контекстов тенантов, управление доступом агентов к тулам и ресурсам, изоляция агентов по неймспейсам, и прочее. Особенно интересная тема - закрепление промптов, относящихся к безопасности, в памяти. То есть агенту периодически вкидываются промпты типа "на тебя зафиксирована промпт-атака", "запрещен доступ к ресурсу", "обнаружен вредоносный файл в запросе". И в случае инцидента память агента часто чистится, и мера в том, чтобы такие сообщения безопасности "пинить" и сохранять. Повышает аварнесс агента, по сути. 4. Detecting GenAI Threats at Scale with YARA-like Semantic Rules - пальто paloalto Предлагают введение корправил для текстовых данных. Суть в правилах для нескольких типов мэтчеров - strings (регулярки), similarity (косинусы), classifiers (легкие берты), llm (судьи кто). Чем-то похоже на NOVA. 5. The Parseltongue Protocol - Crowdstrike Базированный, хороший доклад про техники джейбрейков, показательный стейт атак на март 2026. Протестировали 100+ методов текстовой обфускации на 9 моделях и 17.000+ промптах. Самая результативная связка - zero-shot + Base64 + misalignment-техника (сделай %вредная вещь% как будто это обычная задача). Постарался сделать пост чуть полегче, чем обычно) Как вам?)

Саморазвивающиеся агенты и их угрозы #иб_для_ml Сегодня много шума вокруг Ouroboros - агента, эволюционирующего самостоятельно. Это новое для 2026 года явление, отличающееся от обычных AI-агентов и OpenClaw. Что такое саморазвивающиеся агенты? Предлагаю понять суть в сравнении. 1. Все началось с AI-агентов - кода с промптами, написанного человеком. Это управление состояниями, сессиями, обработкой сигналов и инструментами агента. OWASP Top 10 для агентов есть. 2. Следующий виток развития - агенты семейства OpenClaw. Их ключевая особенность - способность создавать себе инструменты или скиллы. Появились загружаемые инструменты и даже отдельный OWASP Top 10 для агентных скиллов. 3. И вот сейчас - последний писк моды технологий. Агенты, которые могут менять не только свои тулы, но и цели, задачи, планирование, память, и вообще весь свой код. О том, что именно может эволюционировать, хорошо сказано в статье "Your Agent May Misevolve": 1. Модель. Агент может самостоятельно дообучать свою модель (Abs-Zero, AgentTrek, SEAgent), уводя ее вбок случайно или под действием нарушителя, так что когнитивные способности растут, а защитные механизмы атрофируются 2. Память. Попадание и закрепление промпт-атаки в "воспоминаниях" (AgentNet , SEAgent) 3. Инструменты. Появление у агента вредоносных тулов в результате самостоятельного создания или получения извне (Alita) 4. Воркфлоу. Оптимизация своего кода управления всем вышеперечисленным (AFlow, GPTSwarm) Более подробные выкладки есть в посте Артема. Зачем они нужны? Чтобы понять, от чего защищаться, надо понимать, зачем они вообще кому-то понадобились. Я вижу три применения: 1. Личный ассистент для помощи с календарем, контактами, поиском и заказом товаров, разработкой и написанием текстов 2. Движок для Next-Gen PDLC в энтерпрайзе. Агентов можно создавать силами большой команды разработчиков, а можно взять личинку универсального агента, скормить ей ТЗ, и она сама превратится в нужную боевую единицу 3. Генератор идей. Самая сложная задача для алгоритмов - прогноз будущего. И, возможно, только такая сложная система и сможет ее решить: анализировать ситуации целиком, предлагать сценарии развития, стратегии и гипотезы. По сути, способ создания цифрового двойника Угрозы Итак, какие уникальные угрозы возникают при использовании таких агентов? Попытаюсь выделить самые фундаментальные классы, вызванные именно саморазвиваемостью агентов. 1. Компрометация механизма, который решает, какая новая версия агента считается лучшей. После этого агент эволюционирует, повышая прикладные метрики, но опасно с точки зрения ИБ (по сути, reward hacking). 2. Выход за рамки цели, самостоятельное расширение привилегий и возможностей. Подсадка новой вредоносной цели возможна как нарушителем, так и случайной девиацией эволюции агента. 3. Высокоустойчивый персист промпт-атак в "теле" агента - память, промпты, код воркфлоу, код тулов; найти закрепленную промпт-атаку теперь будет сложнее. Гипотезы, как быть (меры митигации) Я подготовил несколько правил, которым надо следовать, чтобы внедрять саморазвивающихся агентов безопасно. 1. Механизмы безопасности должны быть неизменяемы в ходе эволюции агента. То есть контроль доступов, гардрейлы (или сейфти ноды), подтверждение действий человеком - все это должно быть вне изменяемого самим агентом кода. 2. В идеале стоит разделить контур эволюции агента и боевой контур, чтобы во второй попадали только стабильные, проверенные на безопасность "поколения" агента. 3. Память и инструменты должны быть объектами с усложненным доступом - с проверками условий и контекста, только на время, с переаттестацией права доступа и удалением по ненадобности. 4. Каждый шаг эволюции должен логироваться для возможности отката назад. 5. Необходимо выделять основные ветки эволюции и отбраковывать наиболее опасные и непредсказуемые Ванга-бонус Предрекаю, что следующим видом развития агентов станет агент, который может менять не только себя, но и создавать себе вспомогательных агентов, которые в свою очередь будут создавать еще агентов... И так, пока это не станет полноценным живым организмом?..

Почему большинство компаний не готовы к реальной атаке? #иб Как известно, в кибербезопасности можно бесконечно улучшать технологии, процессы и инструменты. Но как понять, что твоя организация готова к атаке? Ждать боевого инцидента можно долго, и не факт, что его получится отразить... Необходимо иметь возможность в условиях, приближенным к реальным, проверить свою киберустойчивость к атакам, эксплуатирующим не только целые цепочки уязвимостей, но и самое главное - человеческий фактор. Этот способ - Red Teaming, конечно же. Сможет ли атакующий дойти до критичных систем и данных? В большинстве кейсов ответ упирается совсем не в технологии, а в количество и серьезность человеческих ошибок. По разным исследованиям, от 60% до 80% успешных атак происходят с помощью человеческого фактора — ошибки, доверие, невнимательность, отсутствие контекста. Если вам интересно услышать экспертов, которые расскажут подробнее о Red Teaming - приходите на открытый подкаст 22 марта в Умном городе на ВДНХ. Спикеры хорошие) Поговорим: — как реально строятся атаки внутри инфраструктуры — где чаще всего «ломается» защита — почему классические меры не срабатывают — и что с этим делать на уровне архитектуры и процессов 🎙 Спикеры — Герман Наместников — руководитель Red Team, 10+ лет offensive-опыта (банкинг, телеком, сложные целевые атаки) — Константин Дегтярев (@johnmkane) — 19 лет в ИБ, архитектура защиты и подготовка к реальным инцидентам Модератор — Александра Русанова Кому это может быть полезно: — DevOps и Cloud инженерам — архитекторам и платформенным инженерам — специалистам по ИБ, аналитикам SOC — CTO и C-level 📅 22 марта 🕛 12:00 — 14:00 📍 Площадка «Умный город» (при поддержке ДИТ Москвы) Регистрация: https://slonomoyka-u-alisy.timepad.ru/event/3869244/

Безопасность LoRA-адаптеров #иб_для_ml LoRA (2021) - технология дообучения GenAI-моделей (из семейства PEFT), при которой изменения хранятся в виде отдельного подключаемого адаптера (матрицы весов) при фиксированных базовых весах. Хоть самая идея отчуждаемых весов появилась раньше (2019), но именно с появлением LoRA она распространилась. Сила этой технологии в масштабируемости для разрозненных команд. Когда одна команда отвечает за сервисы базовых моделей, и множество команд придумывает свои приложения или агентов, возникает задача потоковым образом предоставлять специфично дообученные модели под разные задачи бизнеса. И здесь как раз себя показывает LoRA. Продуктовая команда собирает датасет, и грузит свои размеченные данные для дообучения. Для выбранной базовой модели создается LoRA-адаптер. На выходе для пользователя видно только новое название в поле "модель", дающее доступ к результату дообучения. Это работает, так как с технической стороны, LoRA позволяет для одной отдельно взятой LLM в проде быстро менять адаптеры, как перчатки, в зависимости от поступающих запросов. И с ростом такого "конвейера" LoRA-адаптеров стала появляться новая поверхность атаки, эксплуатирующая особенности подключения кусочков модели к основному файлу весов. 📷Поговорим про топ-3 классов угроз для LoRA 1⃣Отравление данных обучения: вроде бы обычная история отравления, с LoRA приобретает несколько особенных граней. Стандартный способ атаки модифицируется - например, отравляются несколько наборов данных, и, соответственно несколько наборов адаптеров. Это делается для того, чтобы только в комбинации такие адаптеры давали вредоносный эффект бэкдоров. (ссылка) Помимо этого, особенностью также является легкость внедрения поверхностных знаний в модель (ссылка). Так, существует работа, показывающая, что с помощью отравления LoRA можно обучить модель стеганографически сливать небольшие сообщения через ответы. (ссылка) 2⃣ Хирургия весов: самый показательный экзотический вариант - срезание FF-слоя (feedforward): подмена только MLP-компоненты в легитимном адаптере на такую часть отравленного дает почти полный перенос бэкдор-знаний при минимальных изменениях прикладной эффективности. Туда же - техника "сплайсинга": FF берётся из одного адаптера, части матриц внимания (Q/K/V/O) — из другого (матрицы отравленные), внешне получается почти тот же артефакт. (ссылка) 3⃣: Из LoRA тоже могут утекать данные: есть работа, где показано, что по данным обучения адаптеров также можно осуществить восстановления наличия записи в датасете обучения (membership inference - ссылка). 📷Конечно, не забудем и про меры защиты LoRA 🔓 На этапе проектирования и формирования цепочки поставок: единый реестр и управление доступом к адаптерам и их комбинациям, обязательная связь с наборами данных (подпись происхождения), безопасный формат файлов, отслеживание хэшей тензоров для обнаружения “смешивания” тензоров между несколькими адаптерами. 🗃 На этапе обучения: обязательные проверки загружаемых данных (ПДн, секреты и технические учетные данные), оценка признаков отравления данных, "слепая" предобработка для нарушения паттернов потенциальных отравляющих инъекций. 📷 На этапе эксплуатации: на самом деле, базовые меры для AI-агентов сегодня, то есть DLP на ответах, гардрейлы, регулярный red teaming новых адаптеров и их комбинаций. Из необычного можно попробовать реализовать анти-стеганографическую проверку. По реагированию - быстрый отзыв ручки с адаптером при выявлении компрометации данных или самого файла весов адаптера. Но можно сказать, что пока что все это больше пугалки, чем денежные угрозы. Заниматься сейчас безопасностью LoRA есть смысл только в двух случаях: в крупном энтерпрайзе при использовании с чувствительной информацией, и при развитии собственной лаборатории безопасности ИИ. Во втором случае это полезно потому, как, возможно, в будущем появится больше "конструируемых" моделей на лету. И об этом говорят такие работы, LoRAFlow, MixLoRA, S-LoRA.

Всем привет) Я опять на конфе, но на этот раз не в России) Кто тоже сегодня на SIGN China, пишите 😁 Или просто в Китае)

Как изменилась индустрия AI Security за 2025 год? #иб_для_ml 17 января мы с Артемом (автор PWNAI), Женей (автор "Евгений Кокуйкин - Raft") и Владом (автор "llm security и каланы") провели стрим на тему изменений в AI Security за 2025. И сейчас подготовили для вас его текстовое изложение! Приглашаю к прочтению: https://habr.com/ru/articles/1000736/ Я на стриме сфокусировался на перспективах развития индустрии на горизонте 2-3-5 лет с учетом достижений 2025. Это и появление нового класса решений по безопасности, основанных на анализе архитектуры моделей. Также был разговор про типы угроз для AI Cybersecurity в целом, и про средства автоматизации кибератак, и инциденты за прошлый год, и стоимость защиты, и многое другое.

Всем привет) Кто тут - отзывайтесь)