maxigacy (AI) Security

Firewall для tool calls Разрешить агенту инструмент delete_file ещё не значит разрешить удаление лю

2026-09-17T06:12:55+00:00

Firewall для tool calls

Разрешить агенту инструмент delete_file ещё не значит разрешить удаление любого файла. С execute_sql та же история: название одно, последствия зависят от запроса.

Поэтому между решением модели и выполнением хочется иметь отдельную проверку. Особенно когда агент работает с реальными данными.

В мартовском препринте AEGIS: No Tool Call Left Unchecked авторы описывают такой слой. Он перехватывает вызов до выполнения, извлекает строки из аргументов, проверяет их по шаблонам угроз и заданным политикам.

Дальше три варианта: пропустить, заблокировать или приостановить до решения человека.

В основе проверки здесь правила и паттерны. Например, признаки опасных SQL-запросов, shell injection и обращения к чувствительным файлам.

По результатам авторов:

• заблокированы 48 из 48 атак в подготовленной ими выборке;
• на 500 безопасных вызовах было 6 ложных срабатываний, то есть 1,2%;
• медианная добавленная задержка составила 8,3 мс на 1000 вызовах в локальном развёртывании.

Все шесть ложных срабатываний вызвали легитимные SQL-запросы с OR. Знакомая проблема: конструкция выглядит подозрительно, хотя запрос нормальный.

Но 48 примеров мало для вывода об устойчивости защиты. Авторы признают, что правила могут пропускать новые варианты атак. А вызовы в обход SDK вообще находятся вне модели защиты AEGIS.

Мне здесь интереснее сама точка контроля: модель предложила действие, а право его выполнить проверяется отдельно.

Потому что проверка перед delete_file полезна ровно до момента, когда тот же файл можно удалить через shell.

#AIxSec #AgentSecurity #ToolCalling #MLSecOps

Выпуск уже на канале! https://www.youtube.com/watch?v=FxcfiUxpQAo https://rutube.ru/video/0a86d8bc

2026-09-13T09:17:40+00:00

Выпуск уже на канале!

https://www.youtube.com/watch?v=FxcfiUxpQAo

https://rutube.ru/video/0a86d8bccfedd1806767f5143718ffc1/

https://vkvideo.ru/video-241490908_456239018

Друзья, всем привет 🫶 Сегодня мы с @maxigacy будем записывать подкаст для вас про найм в ИБ (собесе

2026-09-12T11:30:16+00:00

Друзья, всем привет 🫶

Сегодня мы с @maxigacy будем записывать подкаст для вас про найм в ИБ (собеседования, задания, наиболее востребованные направления в ИБ и тд). Как обычно, самые умные мысли приходят в последний момент: пожалуйста, напишите в комментариях к этому посту или мне в лс те вопросы, касательно найма, которые вам интересны (на которые вам хотелось бы послушать мнение со стороны). Мы ответим на них в ходе подкаста

Не стесняйтесь, пишите)

P.S. У меня фотографии под рукой подходящей нет, поэтому ловите веселых нас с Максом😅

🫡 Сайт | 🤔 Хабр

#информационная_безопасность
#карьера

Накиньте вопросов, пожалуйста, постараемся на них ответить в подкасте, если напишете до 16.00

2026-09-12T11:30:16+00:00

Накиньте вопросов, пожалуйста, постараемся на них ответить в подкасте, если напишете до 16.00

Меньше алертов. А уязвимостей? После запуска SAST начинается отдельная работа: понять, какие находк

2026-09-11T06:25:36+00:00

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

После запуска 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

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

2026-09-10T15:10:33+00:00

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

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

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

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

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

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

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

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

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

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

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

Смотрите полное интервью☝️
The video is too large.

⚪️ Представляем Алису AI для бизнеса — ИИ-ассистента для рабочих задач. Давайте ему самые разные пор

2026-09-09T13:21:17+00:00

⚪️ Представляем Алису AI для бизнеса — ИИ-ассистента для рабочих задач. Давайте ему самые разные поручения — он сам определит последовательность действий, обратится к нужным сервисам и выдаст результат.

Если ваша организация — клиент Яндекс 360, то ИИ-ассистент для вас уже доступен. Если же нет, то зарегистрируйтесь в экосистеме. За трёхмесячный пробный период успеете бесплатно попробовать Алису AI для бизнеса и другие возможности.

Подписывайтесь 🔴 @yandex

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

2026-09-09T13:20:27+00:00

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

жду всех на ZeroNights 30 сентября в Питере) Буду рассказывать про проверки плагинов в Трекере https

2026-09-08T09:24:35+00:00

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

Можно ли доверить LLM решение о том, кому выдавать доступ? Короткий ответ: точно нет. Поговорил с

2026-09-08T06:14:56+00:00

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

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

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

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

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

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

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

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

Ваш клиент пишет system prompt Можно выбрать устойчивую модель, продумать системный промпт и настро

2026-09-04T06:25:29+00:00

Ваш клиент пишет 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? Поговорил с Максимом Сураевым из Lam

2026-09-02T13:41:50+00:00

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

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

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

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

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

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

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

«У нас стоит антивирус — значит, мы в безопасности». Обычно эта уверенность живёт ровно до первого

2026-08-31T07:51:30+00:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#interview #AIxSec #Security #SOC
The video is too large.

Агент сказал одно. Процесс сделал другое Защита AI-агента часто заканчивается перед вызовом инструм

2026-08-29T15:15:42+00:00

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

Защита 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? Нет. Возможно, вы просто тестиров

2026-08-27T17:12:58+00:00

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

Цифровой кофепоинт Яндекса Самое ценное, что можно получить от работы в большой компании - это не с

2026-08-24T17:23:11+00:00

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

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

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

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

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

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

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

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

Меньше битов ≠ больше защиты Чтобы запустить ML-модель на микроконтроллере, её часто переводят из F

2026-08-23T06:45:01+00:00

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

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

2026-08-20T15:08:43+00:00