Меньше битов ≠ больше защиты

Чтобы запустить ML-модель на микроконтроллере, её часто переводят из FP32 в INT8 или INT4. Модель становится компактнее и быстрее, а иногда ещё и демонстрирует лучшую устойчивость к adversarial-атакам.
Звучит как бесплатная защита. Но есть нюанс.

Авторы исследования David and Goliath⁠ проверили три квантованные TinyML-модели с помощью десяти атак и шести защит. Оказалось, что квантование меняет геометрию модели: градиенты могут исчезать, взрываться или указывать атаке неверное направление.

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

Поэтому оценивать нужно именно итоговую INT8/INT4-модель, причём не одной атакой: полезны адаптивные, transfer- и black-box-сценарии, а также проверка на реальном устройстве.

Для меня эта тема не только теоретическая. В нашей с Максимом Князевым статье «Влияние квантования TinyML-моделей на устойчивость аудиосистем персонального интернета вещей»⁠ мы проверяли распознавание голосовых команд под атакой PGD-40. INT8-QAT сохранил 98,8% точности на чистых данных и 92,2% под атакой, а у INT4 показатели снизились до 49,42% и 47,8% соответственно.

Квантование отлично экономит память. Но в безопасности экономия битов ещё не означает экономию рисков.

#AIxSec #TinyML #AdversarialML #MLSecurity #Security #AIxSec_Research

Цифровой кофепоинт Яндекса

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

Это люди, нетворк и чужие мысли.

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

Коллеги собрали папку с Telegram-каналами ребят из Яндекса. Здесь авторы из разработки, ML, аналитики, продукта, менеджмента, безопасности и других направлений.

Кто-то публикует технические разборы, кто-то пишет о карьере и управлении, а кто-то делится профессиональными наблюдениями, которые хочется сразу унести в «Сохранённые».

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

Забрать папку
👉 https://t.me/addlist/KaVv1NTpJKpmYmZi

Ваш guardrail показал 1% ASR. Значит ли это, что он защищает LLM?

Нет. Возможно, вы просто тестировали его на атаках, которые он уже умеет блокировать.

Решил немного углубиться и описать подробнее мат. модель и свои мысли по поводу статьи The Attacker Moves Second, про которую писал чуть раньше. После адаптации атак под конкретную защиту ASR для большинства систем превысил 90%.

Ключевое слово здесь: адаптация.

Статический тест отвечает на вопрос:

Работает ли защита против заранее выбранного набора атак?

Security evaluation должна отвечать на другой:

Сможет ли атакующий обойти защиту, если знает её устройство, наблюдает ответы и изменяет стратегию после каждой попытки?

Компактно идею можно записать так:

a* = arg max S(D(a, x), g), где a ∈ A(K, Q, B)

Здесь:

• D — вся защищённая система, а не только LLM;
• a — кандидат атаки;
• x — исходная задача или контекст;
• g — цель атакующего;
• K — знания атакующего о защите;
• Q — доступная обратная связь;
• B — вычислительный и query budget;
• S — оценка достижения цели.

То есть a* — атака с наибольшим скором среди стратегий, доступных атакующему при заданных знаниях, обратной связи и бюджете.

Это моя компактная формализация постановки, а не дословная формула авторов.

Если статический набор A₀ входит в пространство доступных адаптивных стратегий A(K, Q, B), то при одинаковых задачах и scorer:

max S(D(a, x), g), a ∈ A(K, Q, B)
≥
max S(D(a, x), g), a ∈ A₀

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

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

Главный вывод для меня:

ASR без описания threat model, доступа атакующего, бюджета и способа адаптации является почти бессодержательной метрикой.

Эмпирический тест не может доказать, что защита надёжна. Он может только попытаться её сломать и не найти атаку в рамках явно заданной модели угроз.

Статья • USENIX Security ’26

#AIxSEC #LLMSecurity #PromptInjection #SecurityinAI #research

Агент сказал одно. Процесс сделал другое

Защита AI-агента часто заканчивается перед вызовом инструмента: проверили название, аргументы и решение модели — можно выполнять.

Но всё это описывает только намерение агента, а не фактическое поведение процесса.

Авторы свежей работы Hybrid Analysis for Secure MCP Tool Use in LLM Agents предлагают MTGuard — систему, которая проверяет весь жизненный цикл MCP-вызова:

до выполнения → во время → после

До запуска MTGuard анализирует параметры вызова. Во время выполнения собирает события процессов, файловой системы и сети. После сравнивает заявленное действие с тем, что инструмент сделал в действительности.

Например, агент вызывает безопасный navigate(), но на уровне MCP-хоста команда подменяется на чтение /etc/passwd. Проверка аргументов видит обычную навигацию, а runtime-мониторинг — уже реальный процесс.

В экспериментах MTGuard обнаружил 116 из 240 небезопасных вызовов: 48,3%.

Но 48,3% это detection rate, а не доказанная доля предотвращённых атак. В эксперименте решения защиты не блокировали выполнение. Кроме того, post-execution-проверка может скрыть опасный результат от агента, но уже не отменит совершённый сайд эффект.

Есть и цена: два LLM-аудита добавляли в среднем около 12,39 секунды к каждому вызову инструмента.

Поэтому MTGuard не готовая серебряная пуля (опять эти разговоры про серебряную пулю…), а хорошая демонстрация более важного принципа: безопасность AI-агента нельзя строить только вокруг промптов и аргументов.

#AIxSec #AgentSecurity #MCP #RuntimeSecurity #AIxSec_Research #Research #SecurityinAI

«У нас стоит антивирус — значит, мы в безопасности».

Обычно эта уверенность живёт ровно до первого серьёзного инцидента.

На OFFZONE поговорил с руководителем центра мониторинга «АйТи Новации» Сергеем Шамаевым о том, как выглядит информационная безопасность не в презентациях, а на практике.

За пять минут успели обсудить:

— чем занимается SOC из 12 человек и с какими задачами приходят крупные заказчики;

— почему форензика и offensive security — две стороны одной медали;

— какие инструменты используются в реальных расследованиях: Volatility, Autopsy и SIEVER;

— почему компании чаще начинают всерьёз заниматься безопасностью уже после атаки;

— какие ошибки до сих пор встречаются в инфраструктуре: от надежды на один антивирус до паролей на стикерах;

— и главный вопрос: действительно ли стоит платить пентестерам за то, чтобы они ломали вашу систему?

Спойлер: стоимость пентеста почти всегда несопоставима со стоимостью настоящего инцидента.

Получился короткий, но максимально практический разговор о SOC, форензике и реальном состоянии корпоративной безопасности.

Сергей ведет свой тгк и пишет про кейсы работы в SOC, ссылочка: https://t.me/nedobrysoc

Смотрите интервью 👇

#interview #AIxSec #Security #SOC

AI уже примеряет одежду по фотографии. Но кто защищает сам AI?

Поговорил с Максимом Сураевым из Lamoda о безопасности виртуальной примерочной и рисках, которые появляются вместе с генеративными функциями.

В интервью разобрали:

• как работает AI примерка одежды в Lamoda
• какие две основные поверхности атаки есть у такого бота
• почему одних фильтров недостаточно для защиты AI
• как техническая проблема может превратиться в репутационный риск для бизнеса

Получился предметный разговор о том, как запускать AI функции в реальном продукте и учитывать безопасность еще на этапе разработки.

Смотрите полное интервью 👆

Какой риск AI сервисов вы считаете самым недооцененным: утечку данных, prompt injection или репутационный ущерб?

Ваш клиент пишет system prompt

Можно выбрать устойчивую модель, продумать системный промпт и настроить иерархию инструкций.

А потом позволить пользователю самостоятельно назначить своим сообщениям роль system.

Именно такую проблему обнаружили авторы исследования When AI Meets the Web, принятого на IEEE S&P 2026.

Они изучили 17 сторонних плагинов для AI-чатботов, развёрнутых более чем на 10 000 сайтов.

У 8 плагинов, которые использовались примерно на 8 000 сайтов, история диалога отправлялась из браузера внутри POST-запроса без проверки её подлинности и целостности.

Пользователь мог изменить историю, добавить сообщение от имени assistant или даже вставить собственную инструкцию с ролью system.

USER → SYSTEM

В экспериментах такая подмена повышала успешность исследованных нежелательных сценариев в 3–8 раз.

Второй путь атаки проходил через RAG.

Системы автоматического сбора контента у 15 плагинов извлекали со страниц не только контент владельца сайта, но и пользовательские отзывы и комментарии. В случайной выборке из 100 интернет-магазинов исследователи нашли 13 чатботов, которые уже получали сведения из отзывов.

Авторы не публиковали вредоносный контент на реальных сайтах, поэтому это не доказанная эксплуатация этих магазинов. Но канал для indirect prompt injection уже присутствовал:

отзыв атакующего → база знаний → контекст модели

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

Можно месяц укреплять системный промпт, а затем превратить user в system одним полем JSON.

Классический AppSec. Просто теперь с токенами.

#AIxSec #PromptInjection #RAGSecurity #AppSec #AIxSec_Research

Можно ли доверить LLM решение о том, кому выдавать доступ?

Короткий ответ: точно нет.

Поговорил с Борисом, экспертом по AI Security и автором блога "Борис_ь с ML", о том, как устроена безопасность ML-систем и AI-агентов.

В интервью обсудили:

• как Борис попал в безопасность ИИ
• почему экспертный канал может привести к новым карьерным возможностям
• действительно ли AI Security создаёт новые проблемы или переупаковывает старые
• что там с правами у AI-агентов
• почему нельзя позволять LLM самостоятельно принимать решения о доступе
• где проходит граница между автономностью агента и контролем безопасности

Получился разговор не только про технологии, но и про развитие в AI Security, публичность и новые риски, которые появляются вместе с AI-агентами.

Смотрите полное интервью 👆

А вы бы разрешили LLM самостоятельно выдавать доступы пользователям и AI-агентам?

жду всех на ZeroNights 30 сентября в Питере)
Буду рассказывать про проверки плагинов в Трекере https://habr.com/ru/companies/yandex/articles/1062416/

Теперь AI B2B SaaS в полной мере) и даже Security добавили)

ИИ уже умеет писать код, анализировать документы и автоматизировать рутину. Следующий рубеж — поиск уязвимостей.

Но насколько хорошо AI справляется с реальным пентестом? Может ли он самостоятельно найти проблему, правильно оценить её критичность и предложить рабочее исправление? Или пока он только создаёт дополнительный шум для команды безопасности?

Об этом поговорили с Даниилом Иванькиным — старшим инженером по информационной безопасности в Т-Банке.

В интервью разобрали три практических сценария применения AI в пентесте.

Первый — анализ Git-репозитория. Агент получает доступ к исходному коду, изучает его и пытается найти потенциальные уязвимости ещё до того, как приложение окажется в продакшене.

Второй — работа с API-контрактами: Swagger, YAML и другими описаниями интерфейсов. Здесь AI может проверять большое количество эндпоинтов, искать подозрительные места и объединять дублирующиеся находки, чтобы специалисту не приходилось вручную разбирать сотни одинаковых предупреждений.

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

Но у AI-пентеста остаётся важное ограничение: модель может ошибаться, неверно понимать контекст и выдавать убедительно звучащие ложные срабатывания. Поэтому человек из процесса пока никуда не исчезает. Его роль меняется — вместо ручного перебора каждой гипотезы специалист управляет агентами, проверяет результаты и принимает финальные решения.

Также поговорили о том:

— как измерять реальную пользу AI в информационной безопасности;
— почему качество находок важнее их количества;
— какие эксперименты уже приводят к обнаружению настоящих уязвимостей;
— как Даниил пришёл в профессию и выступил с первым докладом сразу после школы;
— как школьников готовят к олимпиадам, CTF и работе в информационной безопасности;
— почему преподавание помогает самому специалисту развиваться быстрее.

Получился честный разговор без обещаний, что «ИИ завтра заменит пентестеров». Скорее наоборот: AI становится новым инструментом в руках инженера и помогает быстрее проверять гипотезы, масштабировать процессы и освобождать время для задач, где действительно нужны опыт и человеческое мышление.

Смотрите полное интервью☝️

Меньше алертов. А уязвимостей?

После запуска SAST начинается отдельная работа: понять, какие находки действительно нужно чинить. Здесь и хочется подключить LLM, чтобы она прочитала код и помогла разобрать отчёт.

В препринте QASecClaw авторы проверили такую связку. Semgrep находит подозрительные места, затем LLM изучает исходники и решает, какие срабатывания оставить.

На OWASP Benchmark с 2740 Java-тестами, по общей таблице авторов, получилось:

• ложных срабатываний: 560 → 64;
• верно обнаруженных уязвимых тестов: 1273 → 1233.

То есть убрали 496 ложных алертов. Но заодно отфильтровали 40 настоящих находок, которые Semgrep уже обнаружил.

Вот эти 40 мне интереснее красивых «минус 88,6% шума». Хочется посмотреть, почему модель решила, что там всё нормально, и не повторяется ли одна ошибка на целом классе уязвимостей.

К самой работе тоже есть вопросы: некоторые цифры в тексте и таблицах расходятся. Плюс это препринт и синтетические Java-тесты. Переносить результат на свой продукт без проверки я бы не стал.

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

Потому что пустой отчёт получить несложно. Хочется всё-таки безопасный код.

#AIxSec #AppSec #SAST #MLSecOps #AIxSec_Research