maxigacy (AI) Security

Ваш клиент пишет 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#interview #AIxSec #Security #SOC

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

Защита 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

Ваш 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

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

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

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

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

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

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

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

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

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

Чтобы запустить 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

✨ Как пройти Week Offer Security и попасть в команду, которая занимается безопасностью AI

Об этом рассказывает Максим Гусев — старший инженер по информационной безопасности в Яндекс 360. До компании он прошёл путь от стажёра до DevSecOps/MLSecOps-инженера и техлида группы автоматизации в ИБ.

👳‍♂️ В карточках Максим делится, почему решил попробовать Week Offer, как проходили технические сессии и что делать, чтобы подготовиться к собеседованиям. А ещё рассказывает, чем занимаются в области безопасности ML и LLM сегодня.

➡️ Если вас заинтересовала его история, присоединяйтесь к Week Offer Security 12–18 сентября. Сейчас Яндекс ищет инженеров по информационной безопасности с опытом от двух лет.

📆 Регистрируйтесь до 4 сентября, проходите две технические секции и получите офер, если всё пройдёт успешно.

Подписывайтесь:
💬 @Яндекс нанимает разработчиков

Почему 0% успешных атак ещё не победа

Интересное исследование с говорящим названием The Attacker Moves Second. Среди авторов: Флориан Трамер, Николас Карлини и другие исследователи из ETH Zurich, Anthropic, Google DeepMind и OpenAI.

Авторы проверили 12 современных защит от jailbreak и prompt injection. Многие из них ранее показывали почти нулевой процент успешных атак.

Но стоило использовать адаптивного атакующего, то есть подбирать атаку специально под устройство конкретной защиты, и для большинства решений Attack Success Rate превысил 90%.

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

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

Иначе красивый 0% ASR может означать лишь то, что атакующий ещё не сделал второй ход.

PS Тем временем нас уже больше сотки 🎉

Делитесь в комментариях как вам контент, может есть опредленные вопросы, которые я мог бы покрыть в следующих постах 🤗

#AIxSec #LLMSecurity #PromptInjection #Research

Prompt injection вместо сериала на выходных

В эти выходные читал статью Defeating Prompt Injections by Design Флориана Трамера и его коллег.

Авторы предлагают CaMeL — архитектурную защиту LLM-агентов от prompt injection. В её основе две модели:

— P-LLM строит план по доверенному запросу и может работать с инструментами;
— Q-LLM обрабатывает недоверенные данные, но не имеет доступа к инструментам.

CaMeL дополнительно разделяет потоки управления и данных и проверяет, какие данные разрешено передавать конкретным инструментам.

Главная мысль: вместо попытки научить LLM распознавать абсолютно все атаки лучше спроектировать систему так, чтобы даже успешная инъекция не привела к опасному действию.

Пожалуй, теперь это мой любимый формат выходных: практика английского и погружение в безопасность LLM-агентов.

А как проходят ваши выходные? Давайте поделимся в комментариях:)

#AIxSec #LLMSecurity #CaMeL #PromptInjection #Research

Встретился вчера по счастливой случайности с Женей Кокуйкиным @kokuykin и в какой-то момент наш разговор свернул в любимую рубрику «а что вообще может пойти не так с AI-агентами?».

Спойлер: много чего 😅

Мы спокойно даём Клоду доступ к терминалу, файлам, репозиториям и токенам. А потом тот же Клод получает доступ в интернет. Получается буквально сотрудник, у которого в одной руке ключи от сейфа, а в другой открытый Telegram. Или Twitter.

И это не абстрактная страшилка. Исследователи Check Point нашли уязвимость в Claude Code: достаточно было открыть вредоносный репозиторий и полный API-ключ мог улететь на сервер атакующего ещё до того, как пользователь успевал нажать «доверять этому проекту».

Конкретную дыру уже закрыли. Но сам вопрос никуда не делся:

если агент видит наши секреты и умеет общаться с внешним миром — кто и как контролирует, что именно он отправляет наружу?

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

Само исследование:
https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/

#AIxSec #Security #Notes #News #SecurityinAI

(AI + B2B + SaaS) × Security

В интернете сочетание AI B2B SaaS уже стало мемом: произносишь эти три слова — и можно идти поднимать следующий инвестиционный раунд.
Но недавно я задумался, как несколькими словами описать то, чем занимаюсь, и с удивлением получил ту же формулу:

(AI + B2B + SaaS) × Security

Расшифровываю:

AI — искусственный интеллект и новые риски, которые появляются вместе с его внедрением и использованием для задачи ИБ в том числе

B2B — я работаю в Яндекс 360 с продуктами для корпоративных заказчиков, где особенно важны требования бизнеса, управляемость и доверие.

SaaS — сервисы Яндекс 360 предоставляются по подписной модели: инфраструктура и обновления остаются на стороне провайдера, а пользователи получают готовые облачные инструменты.

А Security здесь именно множитель, а не ещё одно слагаемое. Потому что безопасность должна распространяться сразу на AI, B2B-процессы и SaaS-продукты.

Получается, кто-то строит очередной AI B2B SaaS, а я думаю, как сделать так, чтобы его потом не пришлось срочно спасать.

#AIxSec #Security #B2B #SaaS #Notes