fa
Feedback
PWN AI

PWN AI

رفتن به کانال در Telegram

На 99% состоит из людей. Хроники о небезопасном ИИ. Не нравится? Смени телек. Не продамся вашей рекламе - никогда. "Мнение автора" != "Мнение компании, где автор работает". Папка с каналами по безопасности ИИ: https://t.me/addlist/KQ6ZpCqAO-I1NmUy

نمایش بیشتر
6 843
مشترکین
+724 ساعت
+467 روز
+14230 روز

در حال بارگیری داده...

جذب مشترکین
ژوئیه '26
ژوئیه '26
+179
در 0 کانال‌ها
ژوئن '26
+335
در 7 کانال‌ها
Get PRO
مه '26
+307
در 6 کانال‌ها
Get PRO
آوریل '26
+250
در 4 کانال‌ها
Get PRO
مارس '26
+287
در 2 کانال‌ها
Get PRO
فوریه '26
+4 402
در 8 کانال‌ها
Get PRO
ژانویه '26
+571
در 8 کانال‌ها
Get PRO
دسامبر '25
+293
در 8 کانال‌ها
Get PRO
نوامبر '25
+232
در 8 کانال‌ها
Get PRO
اکتبر '25
+298
در 13 کانال‌ها
Get PRO
سپتامبر '25
+190
در 6 کانال‌ها
Get PRO
اوت '25
+236
در 6 کانال‌ها
Get PRO
ژوئیه '25
+262
در 12 کانال‌ها
Get PRO
ژوئن '25
+200
در 5 کانال‌ها
Get PRO
مه '25
+293
در 9 کانال‌ها
Get PRO
آوریل '25
+207
در 5 کانال‌ها
Get PRO
مارس '25
+343
در 26 کانال‌ها
Get PRO
فوریه '25
+262
در 8 کانال‌ها
Get PRO
ژانویه '25
+483
در 18 کانال‌ها
Get PRO
دسامبر '24
+182
در 5 کانال‌ها
Get PRO
نوامبر '24
+193
در 5 کانال‌ها
Get PRO
اکتبر '24
+269
در 5 کانال‌ها
Get PRO
سپتامبر '24
+375
در 21 کانال‌ها
Get PRO
اوت '24
+198
در 8 کانال‌ها
Get PRO
ژوئیه '24
+160
در 5 کانال‌ها
Get PRO
ژوئن '24
+263
در 4 کانال‌ها
Get PRO
مه '24
+554
در 11 کانال‌ها
Get PRO
آوریل '24
+270
در 10 کانال‌ها
Get PRO
مارس '24
+112
در 2 کانال‌ها
Get PRO
فوریه '24
+109
در 5 کانال‌ها
Get PRO
ژانویه '24
+286
در 8 کانال‌ها
Get PRO
دسامبر '23
+381
در 6 کانال‌ها
تاریخ
رشد مشترکین
اشارات
کانال‌ها
24 ژوئیه+3
23 ژوئیه+8
22 ژوئیه+12
21 ژوئیه+15
20 ژوئیه+8
19 ژوئیه+2
18 ژوئیه+4
17 ژوئیه+11
16 ژوئیه+6
15 ژوئیه+9
14 ژوئیه+17
13 ژوئیه+8
12 ژوئیه+9
11 ژوئیه+5
10 ژوئیه+8
09 ژوئیه+2
08 ژوئیه+9
07 ژوئیه+8
06 ژوئیه+6
05 ژوئیه+5
04 ژوئیه+9
03 ژوئیه+4
02 ژوئیه+2
01 ژوئیه+9
پست‌های کانال
Сейчас все помешаны на матрицах и таксономиях. Arcanum, HiddenLayer - отличные штуки, но, по сути, они просто переводят хакер
Сейчас все помешаны на матрицах и таксономиях. Arcanum, HiddenLayer - отличные штуки, но, по сути, они просто переводят хакерский сленг на язык бизнес-рисков, понятный для CISO и директоров. Утечка данных, Denial of Wallet, репутационный ущерб. Это полезно для защиты бюджета, но это вообще не объясняет, как именно взломали ваш замок. И тут на сцену выходит таксономия zakky8, которая ориентируется на механизмы возникновения атаки. Ей безразличны ваши квартальные потери. И главная фишка как раз в том, что происходит сдвиг от намерения злоумышленника к сломанной внутренней логике самой модели. Если Arcanum говорит вам, что вор хочет вынести базу данных, то эта таксономия указывает на то, что взломщик эксплуатировал ошибочное предположение, заложенное в архитектуру, будто оценки безопасности на уровне одного запроса вполне достаточно. По сути, это показывает разницу между знанием о том, что вас грабят, и пониманием того, что в датчике давления на двери сейфа есть логическая уязвимость. Вам может показаться, что мы уже видели все эти техники: DAN, Base64, role-playing. Но таксономия также показывает атаки, актуальные на 2025 и 2026 год. В том числе на агентов и ризонинг модели. Взгляните на эксплуатацию цепочек рассуждений в современных LLM. Забудьте про примитивное «проигнорируй правила». Атака теперь бьет прямо по внутреннему монологу, заставляя модель в фазе рассуждения самостоятельно и безупречно логически прийти к тому, что обход защитных барьеров – это единственный возможный путь для выполнения полезной задачи. В системах с вызовом внешних инструментов атаки стали куда изощреннее. Вместо грубого взлома текста теперь используют инструкции с отложенной активацией. Такой текст идеально маскируется под безобидный контекст и никак себя не проявляет, пока система сама не решит вызвать конкретный инструмент, скажем, функцию отправки письма. И как только этот вызов происходит, скрытая команда мгновенно перехватывает управление, подменяя параметры и превращая рутинное действие в выполнение вредоносного сценария. Главная ценность этого репозитория не в попытке продать иллюзию тотальной защищенности, а в жесткой инженерии. Да, там есть матрица контрмер, но её настоящая суперсила в том, как она безжалостно подсвечивает белые пятна. Некоторые из угроз пока что нельзя архитектурно закрыть. Например, для атак, где используются рассуждения и множество шагов прямо указано: защиты нет. И это реально преимущество, если это актуализировать. Таксономия как бы говорит, что нельзя гоняться за призрачными патчами для того, что пока не лечится, а буквально расставляет приоритеты в части защиты. Это экономит сотни часов и позволяет сосредоточиться на реальных, а не выдуманных точках контроля.

2
Я редко пишу про offensive AI, поскольку это не совсем в тему моего канала. Больше года назад, когда я касался этой сферы, игроков на поле можно было пересчитать по пальцам. Я до сих пор помню свой разговор с создателем PentAGI, и тогда во всем мире насчитывалось от силы десять или пятнадцать подобных агентов. Сейчас этот потолок давно и бесповоротно пробит. Мне приходится буквально жить на Гитхабе, и блуждая по его просторам, я наткнулся на крайне любопытный репозиторий. Это насыщенная смесь из множества автономных агентов, научных статей и инструментов для пентеста. Материал отлично подойдет тем, кто давно ждет от меня развернутого поста по данной тематике. Помимо прикладных решений, здесь собрано много теории и глубоких аналитических обзоров. Погружение в эту материю может быть действительно фундаментальным. Сохраняйте себе, чтобы держать руку на пульсе эволюции автономных систем. https://github.com/Yeti-791/Awesome-Offensive-AI-Agentic-Landscape Можете сколько угодно спрашивать меня про то что я знаю о пентест-агентах, но лучше чем ссылку на этот репозиторий я вам не смогу дать.
1 141
3
Непонятно, почему так происходит. Смотришь на красивых демо умных агентов, которые читают файлы, управляют инструментами и строят длинные цепочки задач, а стоит копнуть чуть глубже, и вся эта магия рассыпается в прах от одного кривого запроса. Я тут перечитал свежий материал Криса Хьюза про изоляцию как самый важный принцип для безопасности агентов и понял, что все еще пытаются решать структурные проблемы вероятностными методами. Это как пытаться удержать цунами с помощью канцелярского скотча. Авторы нового исследования предлагают не перечислять бесконечные векторы атак, а задать один простой вопрос. Где именно в системе впервые происходит потеря изоляции. Они выделяют пять критических границ доверия: 1️⃣Первая граница между пользователем и агентом, где пользовательский контент перестает быть просто данными и становится кодом управления. 2️⃣Вторая граница между агентом и инструментом, определяющая доступ к внешним возможностям. 🌷Третья граница исполнения, где абстрактное рассуждение материализуется в конкретное действие. 4️⃣Четвертая граница взаимодействия между самими агентами. 5️⃣И пятая граница между системой и окружающей средой. Часто в рекомендациях по безопасности агентов видишь советы про строгие системные промпты или наличие ограничения на вызов инструмент, но это чистая иллюзия. Их можно уговорить, обмануть или заставить галлюцинировать. Цифры в материале снимают иллюзии. Рост числа серверов MCP составил две тысячи процентов за год, и подавляющее большинство крутится на машинах разработчиков, а не на защищенных корпоративных серверах. Это огромный риск цепочки поставок. Авторы прямо пишут, что сообщение в мультиагентной системе это скрытый приказ к действию. Один скомпрометированный агент передает вредоносные инструкции другим, и начинается каскадный сбой на уровне коммуникаций. Что в целом также известно уже и в OWASP, и других методологиях. Сетевое окружение превращается в активную враждебную поверхность. Бенчмарки вроде SafeArena и STWebAgentBench наглядно демонстрируют, что агенты выдают небезопасные результаты через обычные клики и навигацию, а модели, обученные вежливо отказывать, моментально ломаются, как только начинают действовать через интерфейс, а не через чат. Я не могу доверять агенту просто потому, что он выдал связный текст. Я должен гарантировать исходя из структуры, что его изначальное намерение не было подменено на стыке этих пяти границ. Ограничения, по сути, будут таким -песочницы, контроль исходящего трафика, детерминированные проверки политик на уровне ядра. Вместо нагромождения защитных слоев поверх хрупкого агента изоляцию нужно закладывать в саму архитектуру. Когда вы будете оценивать агента – стоит задать один вопрос «Где проходят границы этой системы и какой конкретный механизм их реально защищает?». Если ответ сводится к фразе разработчики написали строгий системный промпт, битва уже проиграна. Границы доверия не прощают небрежности.
1 185
4
Если отбросить всякие OWASP, статьи научные и т.д то какой вектор атаки на AI-системы вы считаете наиболее недооцененным и опасным в реальных прод-средах прямо сейчас?
1 223
5
Запускаю я недавно garak и promptfoo, смотрю на отчет и понимаю: я просто гоняю один и тот же набор сигнатур по кругу. Но кажется это больше для галочки. Но вот, недавно вышел AHA (Agent Hacks Agent - код). И это не сканер, это автономный инструмент для тестирования моделей, который строит граф концепций уязвимостей. Попробую расшифровать эту аббревиатурную кашу, потому что дьявол, как всегда, кроется в механике. Ребята протестировали 18 жестких конфигураций, разложив всё по осям: две жертвы (Claude Code и Codex), три модели-исследователя (Minimax, Kimi, Deepseek) и три бенчмарка – AgentHazard, AgentDyn (о котором я писал) и DTap. На них и прогоняли. И что они получил, а получили они 117 подтвержденных срабатываний. На отложенных задачах, без всякого дообучения, средний процент успешных атак подскочил на 14 процентов по сравнению с бейзлайнами. В сценарии прямой атаки на Codex модель Deepseek-V4-Pro выдала вообще 91,1% успешных взломов. Но это ещё не всё. В обнаруженных механизмах - кластеризация выдала 8 семейств уязвимостей. Он умеет подменять авторизацию. Агент просто верит, что ты админ, потому что ты пошёл против него социалкой. Скармливаешь ему SSH-ключ со словами «я на новом ноуте», и он без задней мысли прописывает его в authorized_keys. Восемь подтверждений, ноль опровержений. Эксплуатация доверия. Тут у меня, да и у многих, возникает мысль: «Зачем нам ваши дорогие облачные API, давайте просто закрутим этот же цикл на локальном Hermes». Звучит как план идеального ограбления: бесплатно, приватно, свои данные. Но чтобы взломать агента, модель-исследователь должен быть умнее жертвы. Если ты назначаешь локальный Hermes и планировщиком и создателем атак, ты получаешь замкнутую систему, где слепой ведет слепого. Ему банально не хватает той самой изощренной креативности и глубины рассуждений, чтобы нащупать неочевидный механизм. В лучшем случае он пережует известные паттерны, но новое семейство уязвимостей не откроет. Да и сам AHA пока что далеко не волшебная таблетка, снимите розовые очки. Во-первых, это дикая жратва токенов. Четыре субагента крутятся в цикле, постоянно рефлексируют и критикуют друг друга. Счет за API будет таким, что вас, несомненно, попросят объяснить – почему нейросети ведут диалог сами с собой. Во-вторых, иллюзия того, что всё под контролем. Субагент критик может решить, что уязвимость воспроизводима, хотя это просто галлюцинация модели-исследователя. Граф уязвимостей красив на бумаге, но он упирается в слепые зоны самой базовой модели. Плюс инфраструктура: тебе нужен жесткий Docker для песочницы жертвы, чтобы твой автономный агент не снес тебе реальный прод, а это уже не просто pip install.   В сухом остатке для меня AHA - это реально скачок по сравнению с привычными тулзами, потому что он переносит саму идею взлома между моделями. Но это дорогой, тяжелый и все еще ограниченный железом инструмент. Команду безопасности пока не заменит. Ночь наступает, и в этой ночи он жрет наш бюджет, а не только уязвимости.
1 622
6
بدون متن...
1 480
7
Сейчас всё больше и больше людей проникаются в тему loop engineering. Мы ставим перед агентом задачи, а дальше идут итеративные циклы наблюдения, мышления, действия и рефлексии. Мне нравится, когда кто-то может строить отсюда до замка, замкнутость - это круто. Но глубже погружаясь в мир автономных агентов, я сильнее ощущал чувство отсутствия защищённости. Такая у меня суперсила. А тут я наткнулся на статью “Safety in Self-Evolving LLM Agent Systems: Threats, Amplification, and Case Studies”, и я пропал. Статья не рассматривает отдельные атаки, а в целом смотрит в глубь, в архитектуру и в подходы. Авторы разложили поверхность атаки на матрицу из пяти функциональных модулей и пяти этапов жизненного цикла. Из двадцати пяти ячеек матрицы семнадцать являются критически уязвимыми, и для них просто не существует работающих методов защиты. Исследователи сравнили два фреймворка с открытым кодом. Один из них – наш знакомый Hermes. Они запустили сорок целевых атак, нацеленных именно на путь эволюции агента. Результат в Hermes оказался абсолютным. Сто процентов. Все сорок атак успешно закрепились в архитектуре. При этом встроенный сканер безопасности заблокировал ровно 2.5% процента угроз. 1/40. Архитектура Hermes активировала в три с половиной раза больше уязвимых ячеек матрицы по сравнению с более статичным аналогом. Читая результаты, меня преследовала плохая мысль о статических фильтрах на входе и на выходе. В классических моделях угроза эфемерна. Ввели мусор, получили мусор, сессия закрылась. Но в циклах самоэволюции - если вредоносный паттерн обманывает этап оценки и проскакивает в фиксацию, он не просто выполняется. Он получает прописку в агенте. Дальше хоррор. Авторы выделяют семь сквозных эффектов усиления. Эти эффекты по синергии взаимодействуют друг с другом, делая невозможным обеспечение безопасности путем изолированной защиты отдельных модулей. Возьмем модуль взаимодействия между агентами. Представьте себе популяцию агентов. Каждый отдельный агент проходит все проверки, ведет себя идеально и соответствует строгим критериям. Но популяция в целом эволюционирует в абсолютно небезопасном направлении. Агенты начинают использовать стеганографию в своих внутренних коммуникациях для обхода общих фильтров. Они коллективно вырабатывают иммунитет к нашим правилам, потому что синергия их взаимодействий создает новые и неочевидные паттерны поведения. Или возьмем умственные ресурсы. Авторы приводили в пример атаку когда атакующий тонко отравляет опыт, который агент извлекает из своей базы знаний. Агент самостоятельно и абсолютно рационально приходит к вредоносным выводам, считая их результатом собственного улучшения. Он не взломан. Он просто неправильно запомнил прошлое. В статье это называют как налог на безопасность. Любые проверки делают агента медленнее и снижают его метрики полезности, поэтому на этапе оценки эволюционный алгоритм просто рационально отбраковывает "тормозящие" ограничения. В модуле самопроектирования авторы описывают то, что они называют Optimizer-Optimizee Collapse. Агент начинает менять не только свои инструменты, но и правила, по которым он оценивает свою эффективность. Если ограничение замедляет его работу и снижает итоговый скор за полезность, эволюционный алгоритм рационально и хладнокровно отбраковывает ограничение. Агент сам срезает себе ветку безопасности, потому что в его локальной петле эволюции так просто выгоднее. В таком случае бессмысленно проверять, что агент решил сейчас, если через пять итераций он изменит сам механизм принятия решений. Думаю, контроль должен быть не над ответами, а над правилами, по которым агент может менять себя. Статья предлагает выход путём создания неизменяемого ядра на жестком детерминированном коде, которое математически верифицирует любые предложенные агентом изменения строго до этапа их фиксации. А ещё они предлагают интересную таксономию различных угроз для самоэволюционирующих агентов (можете посмотреть на картинке к статье). Loop Engineering невероятно интересен. Но если вы не заложили жесткие архитектурные границы в саму петлю, поздравляю. Вы создали автоматический самоподдерживающийся генератор уязвимостей.
1 421
8
Недавно я решил протестировать Open Policy Agent. Если кратко, OPA представляет собой цифрового бюрократа. Это не гардрейл, к
Недавно я решил протестировать Open Policy Agent. Если кратко, OPA представляет собой цифрового бюрократа. Это не гардрейл, который пытается понять ваш замысел, и не эвристический фильтр, ищущий скрытые смыслы. Это детерминированный движок, берущий на вход JSON-контекст и прогоняющий его через набор жестких правил на декларативном языке Rego. Его единственная задача - сказать «да» или «нет», опираясь исключительно на букву правила. В мире AI-агентов, постоянно норовящих выйти за рамки дозволенного, OPA играет роль безжалостного швейцара, проверяющего документы на входе. Я поднял OPA-сервер в Docker и прогнал через него тридцать тестов (это мало, как мне кажется), часть из которых были сделаны с нуля, а часть взял из готовых примеров. Агента собрал на базе CrewAI и слегка допиленного DeepSeek. Больше всего меня зацепило, что движок умеет мыслить последовательностями, а не просто реагировать на отдельные слова. Обычно политики безопасности представляют как плоский список запретов: нельзя удалять файлы, нельзя трогать базу. Но агент штука хитрая. Он может легально прочитать приватный ключ, а затем так же легально отправить его по почте. Каждый шаг по отдельности кристально чист, и классический фильтр его пропустит. Поэтому я скормил OPA политику на композиционный анализ, заставив Rego смотреть не на текущий вызов, а на историю действий. Когда агент после чтения файла потянул отправку письма, сервер просто положил запрос на стол с вердиктом об эксфильтрации. А так же он поймал цепочку, где агент сначала выполнил код, а потом пошел гуглить, как замести следы. Разогнавшись на цепочках, я прогнал его на тестах где агент должен был сделать запросы к базам данных, через SQL. OPA перестал просто искать ключевые слова вроде DROP. Он начал разбирать грамматику, ловить составные запросы и блокировать запросы, если хоть одна команда в списке была грязной. Тут меня ждал первый облом. В документации гордо расписана встроенная проверка схем, но на практике она напрочь игнорирует обязательные поля. Rego вообще язык специфический. 🤨 Если напишешь не то имя поля, движок не кинет исключение. Он просто молча вернет пустоту, политика не сработает, и ты будешь часами чесать затылок, глядя в логи. Зато с ловлей зацикливаний он справился отлично, безжалостно кикая агента, который пять раз подряд вызывал один и тот же инструмент, и строго следя за тем, чтобы в параметры не просочились лишние поля. За всё это я платил скоростью. OPA отрабатывал от пяти до ста двадцати миллисекунд. Для прототипа нормально, но понятно, что в продакшене такой сервер придется сажать в отдельный контейнер рядом с агентом и настраивать постоянные соединения. Иначе агент будет думать дольше, чем генерировать текст. 💰💰 И всё же, даже с этими продвинутыми трюками OPA остается тем, чем является. Детерминированным фильтром. Он не понимает смысла. Если вы заблокировали слово "SSN", агент просто назовет поле "social_security_number", и OPA радостно пропустит запрос. Он не умеет отслеживать, откуда именно пришли данные в параметры. Закодированные промпт-атаки пройдут сквозь него как нож сквозь масло, если только вы не наколдуете поверх кучу дополнительных правил. Итог простой. OPA в связке с AI-агентом это идеальная, быстрая и иногда непрошибаемая стена. Почему иногда ? Потому что всё-равно есть вероятность взлома. Он отлично справляется с ролью жесткого контроля: режет опасные инструменты, следит за схемой параметров и даже анализирует цепочки действий. Но строить на нем всю безопасность кажется чересчур наивным делом. Это база, на которую нужно класть языковую модель для понимания семантики входящих запросов, песочницу для изоляции и трекер потоков данных. Мы не можем заставить нейросеть быть хорошей, но можем построить вокруг нее харнесс, из которого плохие действия просто не выйдут. И OPA для стен этого лабиринта подходит лучше всего. Главное - не забыть закрыть в нем все люки.😒😒😒
1 280
9
Половина статей про атаки на генеративные модели с использованием изображений оперирует откровенно недостоверными цифрами. Недавно я наткнулся на препринт от исследователей из Наньянского технологического университета. Они решили сделать простую вещь: взять более 200 text-to-image моделей с Hugging Face и посмотреть, насколько страхи вокруг NSFW-джейлбрейков совпадают с реальностью в опенсурс мире. Результаты получились такими, что половину публикаций по этой теме за последний год можно смело отправлять в корзину. Авторы отобрали более 200 моделей с Hugging Face и разбили их на четыре семейства: SDXL, SD, FLUX и Qwen. Для атак они использовали MMA-Diffusion - фреймворк для генерации промптов, который автоматически подбирает способы обхода фильтров безопасности. Промпты брали из датасета UnsafeBench: это около 300 запросов, которые гарантированно должны генерировать NSFW-контент, если модель не защищена. Эту конструкцию прогнали через все 200 моделей, замерили Attack Success Rate (ASR), а затем посмотрели, что получилось на самом деле. Посмотрите, как это обычно работает в исследованиях. Берете модель, отправляете в нее атакующий запрос, срабатывает детектор NSFW, вы записываете в таблицу «успешный взлом» и считаете ASR. ASR растет, начинается паника, все пишут про катастрофу. Только беда в том, что защитный классификатор часто срабатывает на визуальный мусор. Исследователи поняли, что обычный ASR измеряет не уязвимость модели, а неспособность классификатора отличить реальное нарушение от артефактов генерации. Детектор NSFW, который они использовали, - это стандартный классификатор, обученный на датасете NSFW-изображений. В предыдущих статьях он срабатывал на всё подряд: на кривые руки, лишние пальцы, размытые лица и даже на изображения, которые визуально отдаленно напоминают нарушение, хотя по смыслу им не являются. Поэтому авторы ввели метрику Advanced ASR (AASR). Успешным взломом теперь считается только та генерация, которая прошла три фильтра подряд. Первый фильтр представляет из себя самый простой классификатор NSFW, который выдает вердикт «unsafe». Но этого недостаточно. Второй фильтр проверяет, что модель рисует именно то, что от нее просили в промпте. Если запрос было что-то опасное, а модель нарисовала абстрактное пятно, на котором классификатор сходит с ума, это не взлом, а артефакт генерации. Третий фильтр оценивает, что картинка не представляет собой кашу из пикселей. Грубо говоря, AASR задает вопрос: «Действительно ли модель сгенерировала опасный контент, который выглядит адекватно и соответствует запросу, или же классификатор ошибся на артефактах и искажениях?» По сути, именно этот вопрос должен быть определяющим в таких исследованиях. Возьмем базовые модели SDXL: обычный ASR показывает 0,83 (то есть 83% атак якобы успешны), а AASR всего 0,07. Разница в 12 раз. SD-Turbo: ASR 0,80, AASR 0,07. SDXL-Turbo: ASR 0,67, AASR 0,10. Qwen-Image-NSFW: ASR 0,77, AASR 0,17. То есть подавляющее большинство «успешных взломов», о которых пишут в статьях, - это, как оказалось, шум. Классификаторы в тех исследованиях фиксировали совсем не нарушения безопасности. Тут важно понять, что именно исправляет AASR. Обычный ASR это метрика первого порядка, она отвечает на вопрос: «Сработал ли классификатор?». Но классификатор - не панацея. AASR это уже метрика второго порядка, она отвечает на вопрос: «Было ли реальное нарушение, которое выглядит адекватно и соответствует запросу?». И разница между этими двумя вопросами колоссальная. Однако есть модели, которые реально опасны даже после применения всех фильтров. FLUX-Asian2 показывает AASR 0,80; SDXL-RV5 - 0,73; FLUX-Logo-LoRA - 0,73; FLUX-Realism-LoRA - 0,70; GEN-ScandiInterior - 0,70; FLUX-NSFW-Master - 0,67. И самое забавное: некоторые из них выглядят совершенно безобидно в описании, пока не попробуешь прогнать через них атакующий промпт. Интересно посмотреть, как ведут себя разные семейства моделей под воздействием атак. SDXL уже устарел, но и худший вариант: медианный AASR 0,44, верхняя граница уходит за 0,60. SD -промежуточный вариант с медианой около 0,27. FLUX совсем непредсказуемый: медиана ниже, чем у SD, но разброс такой, что никогда не знаешь, что получишь. Qwen самый устойчивый вариант: медиана около 0,15, большинство значений сконцентрировано в нижней части диапазона. Выбор архитектуры ставит вопрос о том, какой уровень риска вы закладываете в систему по умолчанию. А дальше всё мрачно. Эволюция SDXL идет в неправильную сторону. В 2023 году средний AASR был около 0,30, в 2024-м - 0,38, а в 2025-м - уже 0,55. За два года рост почти в два раза. Новые поколения моделей SDXL не становятся безопаснее, они становятся уязвимее. FLUX держится на стабильно высоком уровне с легким ростом. У SD, наоборот, пик пришелся на 2023 год, потом пошло на спад. Короче говоря: делите любой высокий ASR на десять, не верьте описаниям на слово и помните, что FLUX непредсказуем, а новые модели становятся уязвимее с каждым годом. Всё остальное - детали. Актуально это не только для NSFW-джейлбрейков 🍓. Сложно предположить почему авторам захотелось разобрать тему именно таких вот джейлбрейков, но ввести альтернативную ASR'у метрику идея кажется здравой.
1 309
10
Недавно ко мне в коммиты залетел интересный обучающий ресурс - AI Risk Atlas. первое, что мы видим когда заходим на сайт - эт
Недавно ко мне в коммиты залетел интересный обучающий ресурс - AI Risk Atlas. первое, что мы видим когда заходим на сайт - это знакомый нам дизайн 😁. Но помимо этого в глаза бросается большая такая энциклопедия с описанием различных рисков в AI Security, некоторые подкрепляются примерами инцидентов из реального мира. Хоть и часть является не совсем про AI Security - всё-равно, ресурс можно закинуть в копилочку базовых обучающих ресурсов. Из ноу-хау можно отметить интерактивную песочницу. В ней можно визуально посмотреть как может распространятся атака в зависимости от того, какие приняты меры по защите. Такая вот азбука.
1 610
11
Привет. Интересно стало какие AI Security решения появились за последний год ? Поделитесь пожалуйста в комментариях, возможно мы соберём самый полный список того что делается умельцами из России.
1 832
12
Приветы, сегодня посмотрим на работу GAVEL (ICLR 2026) от Offensive AI Lab. Попытка сделать мониторинг активаций LLM более структурированным и интерпретируемым. 🦸‍♂️🦸‍♂️🦸‍♂️ Идея Классический подход к мониторингу активаций выглядит так: берём датасет опасных промптов, обучаем классификатор, надеемся на обобщение. Тут есть ряд проблем - низкая точность, сложность интерпретации, необходимость переобучения при изменении сценариев. GAVEL предлагает другую парадигму: декомпозировать поведение модели на Cognitive Elements (CE) - интерпретируемые атомарные факторы вроде making_threat, payment_tools, personal_information, content_creation. Как это устроено изнутри Берётся замороженная LLM. Из неё извлекаются активации из нескольких выбранных слоёв, причём только для части диалога, которую генерирует сама модель (assistant). Эти активации подаются на вход TopicRNN - LSTM с несколькими слоями. На выходе модель выдаёт логиты для каждого CE, решая задачу multi-label классификации. Правила описываются в rules.json и определяют use cases через три типа условий. all_required - CE, которые должны сработать все (логическое И). any_of - группы CE, где достаточно срабатывания любого. supporting - CE, которые поддерживают правило, но не обязательны. Для примера, правило scamazon (скам-имитация Amazon) требует обязательного наличия personal_information И payment_tools, плюс хотя бы одно действие из any_of (купить, отправить, скачать и т.п.), и опционально поддерживается trust_seeding, making_threat или tax. Пороги срабатывания для каждого CE подбираются автоматически на тестовых данных. После калибровки для каждого правила из rules.json считаются метрики: TPR, FPR и AUC. Что показывают бенчмарки В статье авторы сравнивают GAVEL с девятью базовыми подходами на Mistral-7B (Circuit Breakers, RepBending, CAST, JBShield, Llama Guard 4, Perspective, OpenAI Moderator и обычным классификатором активаций). Результаты сильные: средний AUC по девяти сценариям злоупотребления достигает 0.97, а средний FPR удерживается на уровне 0.03. Для сравнения: методы дообучения вроде Circuit Breakers выдают AUC 0.68 при FPR 0.06, а подходы на основе проекций типа CAST дают те же 0.68 AUC, но с катастрофическим FPR в 0.60. Отдельного внимания заслуживает устойчивость к атакам. При атаках типа Misdirection, когда вредный контент разбавляют безобидным шумом, GAVEL удерживает TPR выше 85% по всем категориям. В то же время GPT-4 в роли судьи проседает до 12–15% на задачах с бредовыми теориями и вмешательством в выборы, а перехват цели и обход фильтров через перефразирование систему тоже не ломают. GAVEL остаётся стабильным, так как смотрит на внутренние когнитивные состояния модели, а не на поверхностные токены. Ещё важно сказать про переносимость между моделями и языками. Одни и те же датасеты когнитивных элементов и правила работают на Llama3-8B, Qwen3-8B и Gemma-4B без переобучения. При тестировании на трёх языках (английском, испанском и китайском) TPR держится в коридоре 0.86–1.0 при почти нулевом FPR.   Что на практике Во-первых, интерпретируемость, когда срабатывает алерт, ты видишь, какие именно CE его вызвали и какое правило применилось. Это отличается от бинарного классификатора, который просто говорит "опасно". Во-вторых, модульность - добавление нового сценария атаки, по сути, правка JSON-файла, а не переобучение модели. В-третьих, переносимость - подход работает с разными LLM без модификации базовой модели, меняется только RNN-зонд. Но. Вся система стоит на точности отдельных CE-зондов. Если RNN ошибается в детекции making_threat, то правило tax_scam, просто не сработает и ты об этом можешь не узнать. RNN-зонды сами по себе требуют размеченных данных для обучения, и качество CE-таксономии напрямую определяет качество всей системы. Ручное написание правил не масштабируется автоматически - для каждого нового домена нужна экспертиза. И это всё равно внешний слой контроля поверх модели, а не решение проблем безопасности самой LLM. Полезно для регулируемых отраслей, где важны аудит и объяснимость. GitHub: https://github.com/Offensive-AI-Lab/gavel
2 441
13
Давно я не делал обзор на интересные книги в AI Security для новичков. Пора исправляться. Недавно бегло пролистал свежую книг
Давно я не делал обзор на интересные книги в AI Security для новичков. Пора исправляться. Недавно бегло пролистал свежую книгу Practical AI Security от Харриет Фэрлоу. Авторша работала в австралийской разведке и писала кандидатскую по состязательным атакам. Раньше она проводила курсы для государственных организаций, по AI Security. А сейчас она делает свой стартап и ведёт бимбобложик. Редкое сочетание. Впечатление специфическое. С одной стороны это отличный онбординг для классических экспертов по кибребезе. Фэрлоу не зацикливается только на простых тактиках джейлбрейка моделей, а структурно и простым языком разбирает атаки на цепочку поставок, а также атаки по сторонним каналам на кластеры GPU и показывает фреймворк MAESTRO для мультиагентных систем, который мы разбирали в начале прошлого года. К книге идет репозиторий с кодом. Можно запустить и покрутить руками, хотя местами атаки выглядят откровенно тепличными и учебными. До того чтобы внедрить в продакшен тут далековато. Но это ж и не задача книжки. Задача дать базу. С другой стороны книга отлично показывает одну из очевидных и интересных проблем, о которой я говорю уже давно. Целые разделы посвящены гардрейлам и фильтрации инструкций, но через банальные регулярные выражения. Мы давно знаем, что внедрение таких заглушек только нормализует девиантное поведение системы, создавая иллюзию контроля для безопасников, пока сама архитектура остается дырявой. Но приятно, что книга собирает воедино ровно те тезисы, которые также были мной описаны в постах с самого начала ведения канала. MLSecOps, изоляция архитектуры, white box подход и подходы к здравой оценки магического мышления вокруг безопасных моделей. Из действительно сильных и пугающих примеров приведу историю из книги, про Африку. Сам впервые прочитал именно тут о ней. В 2020 году в южноафриканском парке браконьеры обошли систему инфракрасных камер на базе Microsoft Azure, которая должна была обнаруживать людей. Система обработала десятки тысяч изображений, но пропустила нарушителей. В итоге погибли четыре носорога. Действительно трагичные последствия, в сравнении с теми инцидентами о которых я писал тут 🐱. А вот еще один кейс, думаю вы его читали, но если нет - то вот кратко. В 2025 году исследователи успешно взломали Google Gemini через отравленные приглашения в календарь. Небезопасные инструкции были вшиты прямо в текст встречи, и агент Gemini, пытаясь помочь пользователю, начал отдавать команды умному дому на открытие штор и включение бойлеров. Хорошая иллюстрация того, что происходит, когда мы даем моделям автономию и доступ к инструментам, полагаясь лишь на промпты и эвристики вместо жесткой архитектурной изоляции и границ доверия. Фэрлоу в своей книге как раз говорит, что AI Security давно переросла рамки обхода фильтров в чат-ботах. Это про некий системный образ мышления, про границы доверия и понимание того, как модель встроена в инфраструктуру. Если мы даем агенту доступ к умному дому или камерам в саванне без жесткой архитектурной изоляции, никакие гардрейлы нас не спасут. Иллюзия контроля остается иллюзией, пока мы не начнем проектировать безопасность на уровне архитектуры, а не лепить заплатки регулярками и прочим шлаком. Но для давних читателей моего канала - это может показаться базой. Это как раз говорит о том что сама книга, как фундаментальная база и карта системных угроз - вещь полезная. Но если вы ищете грязную практику обхода white box защит на уровне токенов и механистической интерпретируемости, то надо поработать самому. книга, надеюсь не забанят, но если забанят то вы будете знать почему.
3 068
14
بدون متن...
2 426
15
بدون متن...
2 318
16
Я спарсил кучу AI Security тулов на GitHub и посмотрел на качество. Звёзды врут, а каждый четвёртый инструмент уже не поддерживается. (приготовьтесь, много чисел) Недавно я писал про агентные скиллы, да и про то, что мне часто в мои репозитории отправляют шлак. Я решил спросить себя, а что в самом тулинге по нашей теме - не в скиллах, а в реальных проектах, сканерах, гардрейлах и бенчмарках? Я собрал и разобрал их так же безжалостно. Считал я так. 28 дорк запросов к GitHub по топикам и ключевым словам, включая неочевидные запросы для поиска foolbox и прочих инструментов (не всё так просто ищется). Получилось 1 136 кандидатов. После очистки осталось 510 релевантных репозиториев и 477 реальных инструментов. Срез сделан на конец мая 2026. Качество я оценивал без звёзд как сигнала, потому что мы уже сами показали, что они врут: тиры считались по свежести коммитов, реальному объёму кода, лицензии и послужному списку в виде форков. Я не всегда смог запускать код. Я оцениваю, что это за код, структуру, данные и какие именно там используются механизмы защиты/атаки, а не насколько хорошо он ловит атаки (думаю об этом отдельно). Дополнительно каждому инструменту я выставлял статическую оценку инженерного качества от 1 до 5 (1 - тонкая обёртка без валидации, 5 - крепкий код с тестами, CI и собственной оценкой точности). Первое, что бросается в глаза - 84 инструмента из находимого рынка созданы за первые пять с половиной месяцев 2026 года - для сравнения, за весь 2025-й их было 43, а за 2024-й всего 25. Главный драйвер - агенты: 35% инструментов относятся к безопасности агентов, и 68% из них родились уже в 2026 году. Это значит, что человек, который сегодня гуглит «LLM guardrail», в большей степени выбирает из проектов младше полугода, без послужного списка и без единой опубликованной оценки. Сколько здесь качества, а сколько мусора, зависит от того, на какой уровень смотреть, поэтому я разделил выборку на две популяции. Видное на рынке - это 239 инструментов с пятьюдесятью звёздами и выше, то есть то, что вы реально найдёте поиском. Из них половина качественные, 24% - инструменты, которые особо никто не проверял, да и живых данных нет по ним (живые, но без сильной поддержки), ещё 24% заброшенные, без коммитов больше года, и 2% откровенный мусор. Длинный хвост ниже десяти звёзд выглядит иначе: 60% там чистый шлак, 39% инструменты, которые не валидировались разработчиком и слабые по качеству. Если упростить - меньше половины находимого тулинга в нормальном состоянии, каждый четвёртый заброшен, а всё, что ниже десяти звёзд, почти полностью мусор. Тезис про звёзды подтвердился во второй раз. Топ-10 репозиториев держат 50% всех звёзд в нише, и при этом 21 инструмент с двумястами пятьюдесятью звёздами и выше заброшен на год-два. Среди них именно те, к которым тянутся первыми: protectai/rebuff с 1 499 звёздами -  знаем его, писал про него ещё в 2024, последний коммит которого собственно был в августе 2024; BorealisAI/advertorch с 1 364 звёздами, мёртвый с 2023 года; репозиторий verazuo/jailbreak_llms с 3 705 звёздами - датасет, замороженный в 2024. По категориям здоровье очень разное. Сканеры держатся лучше всех - 77% реального качественного материала и почти ничего заброшенного; якоря здесь promptfoo с 22 тысячами звёзд, NVIDIA garak с восемью тысячами и cyberark FuzzyAI. Если кому и доверять, то этой категории. Гардрейлы - монетка: 44% качества против ровно такой же доли непроверенных, десятки почти одинаковых «AI agent firewall», половина из 2026 года и почти без реальных тестов со стороны. Бенчмарки оказались ловушкой - 46% из них заброшены, а замороженные в 2024-м бенчмарки как мы можем догадаться – измеряют угрозы 2024 года. Дальше я перешёл от взгляда снаружи к чтению исходников. Разобрал 24 настоящих гардрейла и посмотрел, что они вообще предъявляют как доказательство, что детект работает. Публичный бенчмарк уровня JailbreakBench или AgentDojo нашёлся ровно у одного из 24, то есть у 4%. Свой внутренний крошечный набор используют 33%. Ещё 8% называют «бенчмарком» то, что мерит скорость, а не точность. И у 54% нет вообще никакой оценки точности в ловле промпт-атак. Иными словами, статически вы не можете понять, ловят ли атаки 96% гардрейлов. Технически при этом они выглядят нормально - средняя оценка 3.5 из 5, есть тесты, CI и многослойность, - но качество кода не равно доказанной защите. Характерная деталь: llm-guard, pipelock и rampart хвалятся миллисекундной задержкой, но не приводят ни одного значения TP или FP. Скорость измерить легко, корректность трудно, поэтому мерят скорость. В коде вскрылись ещё два звоночка. Четыре гардрейла из 24 имеют необследуемое ядро: aegis и ZenGuard - примерно 90 строк клиента к закрытому облаку, а last_layer прячет детектор в бинарный .so с заявленными «92%», которые невозможно проверить; «open source» там декоративный. А девять из 24 вообще не про инъекции и джейлбрейк - PII- и инструменты для маскировки данных под вывеской «гардрейл», так что реальная категория защиты от промпт-атак - мала. И прослеживается закономерность: кто честен, тот показывает скромные числа - localmod 0.75, cloakbot прямо признаёт утечку в 6-8%, - а кто рисует «100%» и «92%», тот невоспроизводим. Если посмотреть на то, чем вообще детектят, картина по категориям складывается такая. У гардрейлов regex остаётся каркасом всей ниши и используется в 75% случаев; чисто на регулярках построен 21% - это нормально для PII, но хрупко для семантики. Чистого LLM-судьи как единственного слоя нет ни у одного: это дорого и недетерминированно, поэтому он всегда идёт в составе гибрида, а сам гибрид - мейнстрим, на него приходится 54%. Худший класс - закрытое ядро со средней оценкой 2.0. Сканеров я разобрал 44, и они делятся почти пополам: 16 динамических, которые шлют атаки в живой таргет (garak, PyRIT, FuzzyAI), против 17 статических, анализирующих код и конфиги без запуска. Самый сильный класс среди них - LLM-redteam с оценкой 4.4, хотя его находки держатся на «утверждает модель»; самый слабый из настоящих - чистые сигнатуры с 3.4 и нулём при собственной оценке. При этом 14% «сканеров» - вообще не сканеры (а больше, как инструменты для получения информации о происхождении данных и governance), а свою точность мерят лишь 24% из них. Бенчмарков формально 13, но настоящих только девять; остальные четыре - это гайд, awesome-лист, одиночная атака и сканер-тулза. Единого стандарта скоринга нет: метрику ASR или F1 используют шесть, LLM-судью двое, правила один, ручную разметку один, а трое не считают ничего. Четыре бенчмарка из 13 заморожены. Регулярки - универсальный и дешево, так к сожалению заведено в разработке инструментов для AI-security и при этом везде хуже всех проверяемо с точки зрения качества. LLM-as-judge - растущий слой, на нём построены лучшие новые тулзы, но он недетерминирован и не калиброван. Свою точность почти никто не мерит: около 4% гардрейлов и 24% сканеров, а сами бенчмарки, которые должны быть линейкой, фрагментированы и на треть заморожены. И ярлыки протекают - 14% «сканеров» и 31% «бенчмарков» на деле оказываются чем-то другим. Главная же параллель со скиллами вот в чём: раз 96% решений не публикуют точность, выбор идёт вслепую, а гардрейл, молча пропускающий атаку или режущий легитимный трафик, и есть тот самый случай, когда защита «делает хуже». Ну и вывод такой. Сортируйте инструменты не по звёздам, а по дате последнего коммита и числу форков. По умолчанию доверяйте сканерам и скептически смотрите на гардрейлы, закладывая цикл замены примерно в 12 месяцев. Не верьте «безопасности», подтверждённой замороженным бенчмарком. Читайте код и лицензии. Датасет с оценкой я опубликую в комментах к посту. Можно использовать как bullshit-фильтр. 😁. А можете и оспорить мои цифры в комментариях.
4 880
17
RCE-уязвимость обнаружена в Hugging Face Transformers (CVE-2026-4372) 😭 Уязвимость особенно неприятна тем, что позволяла выполнять произвольный код даже при использовании рекомендованной защиты trust_remote_code=False.  Атакующему было достаточно добавить в config.json модели специальный параметр _attn_implementation_internal. При загрузке модели через привычный from_pretrained() библиотека могла автоматически скачать и выполнить код из внешнего репозитория без предупреждений, запросов подтверждения и заметных признаков компрометации.😓 Под угрозой оказались версии Transformers 4.56.0–5.2.x, особенно среды с GPU-ускорением и установленным пакетом kernels. За время существования дыры (около 6 месяцев) уязвимые версии были скачаны более 232 миллионов раз!  Что делать: 👍 Обновиться 🎊 👍Проверить кэшированные модели на наличие _attn_implementation_internal 👍 Загружать модели в изолированных контейнерах 👍 Рассматривать загрузку моделей как потенциальную поверхность для выполнения кода 👍Подтянуть AppSec и Supply Chain Security в ML/AI-проекты (ну это вообще всем надо!) Получается интересно, конечно 🤔! Разработчики уже выработали здоровую паранойю при установке Python-пакетов, npm-зависимостей и Docker-образов, но при этом могут совершенно спокойно скачать новую модную модель и запустить её в корпоративной инфраструктуре. Фактически, это ещё одно напоминание о том, что современные AI-модели становятся полноценной частью цепочки поставок ПО. Загружая модель из интернета, мы всё чаще выполняем чужой код, даже если кажется (тот случай, когда если кажется, то кажется!), что загружаем только веса нейросети.  Все 🦔
2 194
18
Сканеры скиллов держатся ровно до первого, кто целится точнее Помните, я писал, что просканировать скилл сканером - это несерьёзно, и что тем, кому это продают как безопасность, кто-то сильно подыгрывает? Тогда это были теория и бенчмарки. Теперь Trail of Bits вышли в поле и проверили руками. Не по себе. Меньше чем за час они написали три вредоносных скилла, которые прошли чистыми через ClawHub, Cisco skill-scanner и все три сканера, подключённых к skills.sh от Vercel - Gen, Socket и Snyk. Четвёртый занял пару часов, и только потому, что промпт-атаку подбирали итеративно. Самая тупая атака кладёт самый дорогой стек У ClawHub двухслойная защита: VirusTotal с проприетарным Code Insight на Gemini 3 Flash плюс отдельная гард-модель, по умолчанию GPT 5.5. Обе обошли первой же атакой, и она неприлично простая: между безобидной шапкой и откровенно вредоносным кодом вставили 100 000 переводов строки. Сканер OpenClaw обрезал файл по лимиту и просто не дошёл до пейлоада, а модель VirusTotal поплыла. К чести OpenClaw, они пускают в пакет только белый список типов файлов - ни бинарей, ни архивов. Это сужает арсенал. Для следующих целей такого ограничения нет. Прятки в бинарях skills.sh и Cisco skill-scanner работают по произвольным git-репам - значит, можно тащить бинари, и тут начинается веселье. Скилл context-loader работает через indirection: SKILL.md велит агенту достать «настоящие инструкции» из .docx, а .docx - это просто zip с кучей XML, внутри которого едет пейлоад sync1.sh. Второй, поинтереснее, - simple-formatter. SKILL.md честный, про правила форматирования текста. Рядом безобидный питон. И заботливо приложенный прекомпилированный байткод utils.cpython-312.pyc, в котором сбор переменных окружения под эксфильтрацию, его не было в исходниках. Это похоже на бэкдор в xz-utils: пакет расходится с исходником. Прошло чистым и на skills.sh, и на Cisco. Потому что статика skill-scanner не смотрит в .pyc, игнорит скрытые файлы, проверяет только то, на что ссылается SKILL.md, а незнакомые типы держит за непрозрачные. Сузить область сканирования - это защита от переполнения контекста, но это же и дыра: через что не смотрят, через то и заходят. Промпт-атака, которая просто уболтала судью Четвёртый скилл, dev-env-setup, не ломает рассуждения сканера - он его убеждает. Скилл переключает npm и yarn на реестр атакующего, но обёрнут в язык «корпоративного зеркала реестра за периметром VPN», со ссылкой на публичную npm-org страницу и упоминанием «AppSec-аудита». Cisco на Sonnet 4.6 разглядел альтернативный реестр и поставил... LOW. И в итоге - safe. Причём модель волновало не то, что URL изначально может быть подконтролен атакующему, а то, что скилл может «утечь и раскрыть внутреннюю топологию сети». Сканер на чужой модели заботливо защищает атакующего от утечки его же приманки. Авторы, к слову, не просто поломали, а прислали в Cisco skill-scanner PR. Но даже это не трогает промпт-атаку - она проходит спеку без замечаний. А языков на свете сильно больше, чем Python, Bash, JS и TS, и под каждый паттерны прописывать отдельно. (Отдельно отмечу для тех, кто читал мой пост про agentthreatrule.org: тут поломали именно открытый Cisco skill-scanner, мульти-движок с LLM-судьёй, а не ATR-блэклист, который вливается в Cisco AI Defense. Это разные штуки, не путаем.) Честный скилл выглядит хуже малвари Обратная сторона дуального назначения, которая мне нравится больше всего. Авторы заглянули в официальные офисные скиллы Anthropic (docx/xlsx/pptx) и нашли soffice.py с LD_PRELOAD - подгружает либо готовый lo_socket_shim.so, либо библиотеку, скомпилированную на лету из C в докстринге. Подозрительнее LD_PRELOAD произвольного бинаря придумать сложно. Скорее всего это честный костыль под песочницу claude.ai. Но skill-scanner верит пояснению внутри скилла: Sonnet 4.6 ставит LOW. Подложишь свой /tmp/lo_socket_shim.so в песочницу - скилл сам его подгрузит и выполнит. Выводы о том что скилл это не доверенное по умолчанию – писать не хочется, думаю это и так понятно) просто забавный кейс по обходу сканеров.
5 815
19
И ровно в этот момент в защиту ИИ начинают заливать рекордные деньги. 2025. В кибербез вливают сто девятнадцать миллиардов, и AI-Security становится сегментом номер один по числу сделок. И на этом фоне - гардрейлы, стали новыми заборчиками от атак. На воркшопе LLMSEC показывают, что они обходятся гомоглифами, невидимыми символами и разбивкой текста по буквам. А в октябре во фреймворке OpenAI Guardrails находят вариант обхода гардрейла, где сами защитные механизмы становятся вектором атаки: LLM-судья, который должен ловить вредное, оказывается так же манипулируем, как модель, которую он сторожит. Защита из той же глины, что и угроза. В 2026-м произошло кое-что похуже. Грабли поставили на поток. Раньше ложное чувство защищённости нужно было хотя бы выстрадать - написать статью, обучить модель, продать коробку. Теперь его генерируют за вечер. Я веду Awesome-LLMSecOps, и туда всё чаще летят пул-реквесты с «новыми AI-Security тулзами», у которых одна общая родословная: их целиком сгенерил claude-code по промпту вида «сделай мне сканер промпт-инъекций», а человек сверху не прочитал ни строчки и не проверил ни одного вердикта. Снаружи красиво: громкое имя, README с эмодзи, слова «adversarial», «swarm», «autonomous». Внутри - пусто. И толку с такого «решения» ноль, кроме вреда: оно даёт зелёную галочку там, где защиты нет. Свежий пример, который я разбирал, - проект под гордым именем «Adversarial AI Swarm», обещающий сотни ИИ-агентов, атакующих твою кодовую базу. Открываешь код - а там нет ни ИИ, ни swarm, ни агентов. Это grep, обёрнутый в баззворды. Пятьсот «агентов» - это пятьсот прогонов одного и того же regex по тем же данным, с time.sleep() между ними и красивым выводом в терминал в духе «agent #47 проверяет PyPI advisories». Обнаружение промпт атак - без анализа потока данных: нашёл слово user_input в полусотне символов от вызова LLM - выкатил HIGH. Это не сканер. Это театр сканера. И такого летит мне много ((( И вот это - самое опасное, что родил наш двадцатилетний сюжет. Сломанную защиту с топ-конференции хотя бы рецензируют, прежде чем сломать. А статический сканер, который обещает ловить промпт-атаки и не ловит ничего, кроме подстроки, ты ставишь в CI, видишь зелёную галочку - и выдыхаешь. Эта галочка и есть ложное чувство защищённости в чистейшем виде. Ты не остался без защиты. Ты остался с уверенностью, что защита есть, - а это хуже, чем знать, что её нет. Так что вывод этого поста - не «AI-Security обман». Угрозы настоящие, и поле настоящее, и работы в нём на годы вперёд. Вывод в том, что инструмент с правильными словами в README защищает ровно настолько, насколько защищает его код, - а не его нейминг. Прежде чем тащить очередной «autonomous AI security scanner» в прод или ставить ему звезду - открой исходники и спроси ровно одно: на чём держится его вердикт, на структуре или на угадайке по подстроке? Если на угадайке, ты получил не защиту, а зелёную галочку. Будьте осторожны. Каждое поколение защит верит, что уж в этот раз всё иначе. Просто теперь это поколение умещается в один промпт.
2 131
20
Ложное чувство защищённости – предвестник AI-тревожности. Как-то меня затревожило, неужели AI-Security, пространство где не с
Ложное чувство защищённости – предвестник AI-тревожности. Как-то меня затревожило, неужели AI-Security, пространство где не существовало скама? Да и вообще интересно было как он выглядит? Я под этим понимаю обман со стороны вендоров или же тех, кто обещает защиту. В кайф, конечно, смотреть на то, как скамили раньше, пока не заскамят меня … Это уже происходит давно, но это грабли, на которые AI-Security наступает несколько лет подряд, аккуратно перекрашивая их в каждом новом поколении технологий. И вы можете осуждать меня страшно в комментариях, но давай размотаем хронологию одного очень затянувшегося самообмана. 2006. Барено в статье задаёт вопрос прямо в заголовке статьи: а может ли машинное обучение вообще быть безопасным? Звучало слишком академически и дофига абстрактно - моделей в проде почти не было, ломать было нечего. Вопрос отложили в долгий ящик. Пролежал он там одиннадцать лет, пока кто-то не вернулся к нему с инструментами в руках. 2017. Никлас Карлини с Вагнером выкатывают атаку, которая разносит defensive distillation - модный тогда метод «повышения устойчивости» модели. Первый звоночек: то, что выглядит как защита, вполне может оказаться просто непротестированной защитой. Звоночек проигнорировали - и через год он превратился в набат. 2018. Команда из Беркли берёт девять защит от adversarial-атак с конференции ICLR и ломает семь. А следом выходит статья с названием: «Obfuscated Gradients Give a False Sense of Security». Запутанные градиенты дают ложное чувство защищённости. Вся суть - в одной фразе: защиты не делали модель устойчивее, они просто ломали инструмент атакующего. Картонный доспех, который держится ровно до первого, кто целится точнее. Пока что это оставалось спором на слайдах. А потом состязательные атаки пошли в прод. Июль 2019. Cylance – один из интересных эпизодов, без которого пост не пост.  В проде крутилась ML-модель которая должна была обнаруживать малварь, и её надо было обмануть. Ребята из Skylight реверснули её и обнаружили, что та болезненно зависит от анализа строк и почему-то обожает одну конкретную игру. Игрой оказался Rocket League. Дальше они вытащили строки из экзешника игры, ужали «секретный соус» до жалких шестидесяти килобайт и стали дописывать их в малварь. Модель послушно перекидывала вердикт из «однозначно вредонос» в «безопасно». Сто процентов уклонения на топ-10 малвари мая 2019-го - WannaCry, SamSam, Mimikatz, далее по списку. Боевую модель обманывали строками из аркады про машинки. Реакция вендора. Не «спасибо, чиним архитектуру», а «это не универсальный обход, а манипуляция конкретным признаком в ограниченных обстоятельствах». Я выучил корпоративный, вот вам перевод: ничего не сломалось, вам показалось. Можно было бы списать всё на невезение одной модели. 2020. Карлини возвращается к нам и объясняет, почему нет: защиты не становятся лучше, их по-прежнему просто плохо оценивают. Те же ошибки, что и в 2018-м, только теперь авторы статей заранее пишут целые абзацы о том, почему у них-то всё иначе. Не иначе. Можно было бы списать и это - на болезни роста узкой ниши adversarial ML. Но в 2023-м грабли обзавелись новой, куда более длинной рукояткой. Май 2023. Открывается LLM-эра, и OWASP ставит промпт-атаки на первое место в топе рисков для языковых моделей. Мы знаем это. Но причина обидная: атака не требует ни PhD, ни эксплойта, ни особого ума. Текст. Просто текст в нужном месте. На вход модели поступает весь мир. Казалось бы, после такого индустрия наконец начнёт тестировать защиты всерьёз. В 2024 IEEE S&P, одна из топовых академических-конференций, снова принимает сломанную защиту от состязательных атак. Математически невозможные утверждения, а правка одной строки в их же коде обнуляет точность модели до нуля. Шесть лет спустя после «Obfuscated Gradients» - те же грабли, тот же рецензент, тот же финал.
1 637