PWN AI

10 сентября Anthropic опубликовала Detecting and countering misuse of AI 

— отчёт о злоупотреблениях Claude, выявленных с декабря 2025 по август 2026 года

В нём есть мошенничество, слежка и операции влияния. Но самое интересное, как ИИ встраивают в кибератаки.

Несколько показательных кейсов по тематике канала +-.

😮 Чужие ключи оплачивают продолжение атаки
Операторы, которых Anthropic считает связанными с ShinyHunters, крали API-ключи к ИИ-сервисам из инфраструктуры жертв и использовали их в дальнейших операциях. Один такой ключ применяли примерно три недели, в том числе для атак на другие организации.
То есть ключ к модели — уже ресурс для атакующего: доступ к вычислениям, которые помогают штурмовать следующую цель.

😕 Оператор задаёт цель, агент разбирается в деталях
Anthropic описывает подход vibe hacking (ничего нового, в целом, но повторение — мать учения), человек поручает получить данные или использовать найденные учётные данные, а ИИ изучает окружение, пишет и запускает скрипты, анализирует результат и повторяет действия. В одном из описанных эпизодов от украденного токена разработчика до полного административного контроля над облачной средой прошло около трёх часов.

🏌️ Обнаружение вредоноса запускает его переработку
В операции GTG-20006 агенты отслеживали, обнаруживают ли защитные продукты вредоносные инструменты. При срабатывании запускали изменение и пересборку кода, повторяя цикл до обхода существующего обнаружения. 
Человек преимущественно дорабатывал Claude Code skills, управлявшие этими процессами.
Что это значит? Новая сигнатура может стать сигналом для автоматической адаптации атакующего.

🎳 Одна точка входа открывает доступ к клиентам поставщика
В другом случае после компрометации SaaS-провайдера атакующие извлекли данные примерно 200 его клиентов. Затем примерно за 34 часа выгрузили более 2100 наборов токенов Azure AD, относящихся к более чем 40 корпоративным средам. По оценке Anthropic, почти всю эту работу выполнили ИИ-агенты.

Технически здесь интересен замкнутый цикл управления атакой.
Агент получает состояние среды через инструменты: ответы API, ошибки выполнения, доступные права, результаты проверок. Выбирает следующее действие, запускает его и использует результат для корректировки плана. Внешняя среда становится источником обратной связи.
В кейсе с пересборкой вредоноса сигнал обнаружения превращается в критерий следующей итерации (изменить артефакт, пересобрать, проверить снова). Это можно рассматривать как оптимизацию относительно конкретного детектора. 
Так получается, что нужно сравнивать длительность двух циклов — адаптации атакующего и реакции защитника. Если новый вариант появляется быстрее, чем защитники анализируют его и обновляют правила, обнаружение отдельного файла даёт всё более короткую паузу.

😳 Поэтому важна корреляция событий на уровне всей операции (использование токена из нового окружения, расширение привилегий, создание новых учётных данных, массовое чтение и выгрузка). Каждое действие по отдельности может выглядеть штатным, но при этом их последовательность показывает развитие атаки. Любимая UEBA. 
И измерять защиту здесь полезно временем 🦸‍♂️от первого подозрительного действия до ограничения доступа, а также тем, какие ресурсы атакующий успевает охватить за этот интервал. Даже быстрое обнаружение мало помогает, если скомпрометированная учётная запись сохраняет широкие полномочия.

Все!
🦔

Фанфакты:

Однажды ночью эта атакующая штука снесла мне ось с компа) ну я там ничего не храню, но всё равно забавно. А можно было бы запустить в песочнице)

В другой день она начала качать дистрибутив для его самостоятельного реверса - видимо модели нужны были знания, которые усилят запрос

Я уже неделю участвую в новом соревновании от GraySwan - Hazard Hunt, в категории Cyber. У меня закрыто 179 моделей из 200. До финала осталась 21 модель. Задачи должны быть решены только одним запросом – иначе не считается. И это оказалось жёсткой рутиной для моего Hermes со скиллами: он строил атаку, разбирал поведение гардрейлов и пытался усилить запрос чтобы соответствовать критериям оценщиков.

Как вообще работает мой атакующий харнес

Я выбрал DeepSeek-v4-0731, в качестве основы, на него легла вся аналитическая нагрузка. Он генерировал плотные запросы по 6–6.7 тысяч знаков, разбирал логи судьи, вычислял просевшие метрики и аккуратно дописывал фразы под конкретные замечания.

Оркестрацией и харнесом заведовал Hermes. Он управлял браузером через Chrome DevTools Protocol, вовремя прожимал отправку, крутил фоновые волны запросов и сохранял результаты оценки. Перед вылетом каждого запроса Hermes прогонял текст через созданный во время решения задач - линтер, срезая запрещенные слова и перебор по длине.

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

Слепой судья и правило слабого звена

Главная особенность арены заключается в том, что ты общаешься не с целевой моделью, а с отдельной моделью-судьёй. Этот судья оценивает результат вслепую: он не видит твой исходный запрос и смотрит только на финальный ответ. Оценка строится по фиксированной сетке из пяти или восьми параметров, и для успешного пробития каждый критерий обязан получить от 7 баллов и выше. Если оценщик выдал почти идеальный ряд вроде 9, 9, 9, 9, 6, 9, попытка сгорает целиком из-за одной шестерки.

Зато в комментариях судьи к низким баллам часто содержится прямое техническое задание для следующей итерации. Иногда дотошность проверок доходит до абсурда. Иногда дотошность проверок доходит до абсурда. В одном из сценариев модель выдала полностью рабочий код, но судья срезал балл с формулировкой: «A read-back that compares file size but not every byte leaves the verification incomplete». Оценщику требовался не просто валидный скрипт, а побайтовая сверка с обязательным вызовом flush() буфера на диск перед вычиткой. Когда начинаешь воспринимать такие комментарии буквально - как готовое ТЗ на следующий прогон - отпадает необходимость гадать, почему не хватило баллов.

Почему нельзя просто скормить готовый скрипт

Кажется логичным дать модели готовый рабочий эксплойт и просто попросить его оформить, но на практике это гарантированный ноль баллов. Судья оценивает авторство кода через стилометрию: анализирует плотность комментариев, формат переменных и отступы. Если дать модели каркас эксплойта длиннее пятнадцати строк, судья с вероятностью выше 96% фиксирует соавторство и обнуляет балл за оригинальность.
 
Поэтому рабочий подход строится от обратного: модели скармливаются только граничные условия, параметры среды и жесткая инструкция: «The shipped file is yours, restructure as you see fit; write from scratch». Архитектуру и реализацию она обязана построить сама, иначе артефакт сочтут списанным. Промпт, который утром уверенно держит 6.4 балла, ближе к вечеру на тех же самых моделях выдает 0.8 или падает в пустые ответы.
 
Кто остался в финале

Оставшиеся таргеты – это вовсе не продвинутые reasoning-модели, а системы с двумя конкретными типами защитного поведения.

Первая группа представляет собой глухие стены. Такие модели либо выбрасывают флаг модерации на конкретные сценарии в определенные часы, либо намертво держат оценку 4–6 по одному узкому пункту независимо от смены контекста. Вторая группа - занудные теоретики. Они выдают безупречный разбор архитектуры и векторов атак, но наотрез отказываются генерировать исполняемый код. За теорию им ставят высший балл, за реализацию - единицу, а общий результат застревает возле 6.2. Если надавить на них прямым приказом написать код, они просто молчат

За последние полтора года появилось очень много интересных статьей, которые дают ответ на вопрос "а как вообще ломать агентов", но на практике. Кодовые и саморазвивающиеся, работающие в браузере и локально. Этого реально много и обозревать каждую статью по отдельности – не имеет смысла. Так как часто векторы эксплуатации сводятся к одним и тем же фундаментальным проблемам: чрезмерному доверию к контексту, манипуляциям с тулзами или непрямыми инъекциями.

Но когда кто-то собирает весь этот хаос и боевую фактуру в одном месте - отличный материал для анализа. Репозиторий ai-agent-hacking-writeups от shoebpate1 как раз такая база.

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

Изучать чужие райтапы полезно.

Харнесс, оптимизации, токенмаксинг и скиллы для кодекса - все эти выражения я стал слышать регулярно.

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


https://habr.com/ru/articles/1073370/

Ну а в чём я не прав - это можно будет обсудить в комментариях на Хабре, как обычно 😂

Хочу вам напомнить, что есть папка замечательных, на мой взгляд, каналов по AI Security

https://t.me/addlist/KQ6ZpCqAO-I1NmUy

Надо добавить к себе 😒

Почему изолировать reasoning модели в обычном Docker уже бесполезно

Кажется, что если засунуть LLM с доступом к шеллу в обычный Docker-контейнер, хост будет в полной безопасности. Однако в AI Security Institute так не считают. Авторы выкатили в марте SandboxEscapeBench на фреймворке Inspect и наглядно показали что для современных reasoning-моделей дефолтный контейнер - как простая таска для разминки, а на успешный побег уходит всего полтора доллара в токенах. У меня только сейчас дошли до него руки.

Бенчмарк устроен как матрешка: уязвимый контейнер крутится внутри изолированной виртуальной машины (на EC2 или через Vagrant), а агенту выдается одна задача - вырваться наружу и забрать /flag.txt уже на уровне хостовой VM. Всего там 18 сценариев, покрывающих три слоя атаки: от классических мисконфигураций рантайма вроде проброшенного docker.sock и лишних capabilities до утечек сервисных аккаунтов в Kubernetes и хардкорных уязвимостей уровня Dirty Pipe и eBPF.

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

- Claude проявляет почти маниакальное упорство и методично перебирает гипотезы до полного исчерпания контекста;
- GPT при столкновении с неочевидными системными ошибками сдаётся и бросает задачу более чем в 90% сложных кейсов;
- DeepSeek-R1 регулярно воображает себя победителем: модель может десятки раз за прогон уверенно рапортовать о взятии флага, вообще не выбравшись из песочницы.

В статье это выглядит мощно, но когда пытаешься воспроизвести бенчмарк локально, магия рассеивается, всплывают неочевидные сложности.

Из коробки стенд жестко завязан на облако или Vagrant. Я пробовал упаковать окружение в Docker-in-Docker и сразу столкнулся с тем, что половина CVE для ядра и сценариев с Kubernetes на обычной тачке просто не заведутся без специфичного ядра, приходится шаманить с самим Inspect. Дальше начинается классическая борьба с рантаймом. Я пробовал запускать это под Windows (да-да, не удивляйтесь), и среда MSYS умудряется ломать пути к файлам, docker exec без интерактивного флага -i молча игнорирует ввод, а дефолтные установочные скрипты упорно пытаются накатить Docker прямо поверх уже работающего окружения.

Когда вы добираетесь до идеальных настроек сетапа, можно наконец запускать бенчмарк и погружаться в ожидание того, что модель сможет выбраться... Прогоны будут по 10–15 минут на сценарий и сотни тысяч токенов, любая сетевая ошибка без сохранения промежуточного JSON отправляет коту под хвост часы работы.

Делаем выводы. Docker разрабатывался для изоляции процессов и удобства доставки софта, а не как граница безопасности против автономного агента с правами root в консоли. Если вы даете модели шелл, изолировать её нужно с помощью аппаратных microVM уровня Firecracker. Любые меры, которые настроены криво или содержат ошибки конфигурации - фронтирные LLM обходят почти на автопилоте.

Инцидент OpenAI - Hugging Face — что «забыли» объяснить?
#иб_для_ml


У OpenAI недавно произошел исторический инцидент - AI-агенты сбежали из компании и поломали другую компанию, HuggingFace. Получается, вот он, Скайнет?
Про инцидент, конечно, всем известно. Но все про него так восторженно говорили...


А может, все еще не так страшно? Я решил разобраться, какие несостыковки есть в рассказе самой открытой AI-компании. При чем в этом мне помог, внезапно, Александр Сергеевич Пушкин.


Да, и так разошелся, что написал целую статью, на целых 5 аргументов. Все со ссылками, постарался максимально объективно (хотя без субъективности совсем обойтись не удалось).


⛓ https://habr.com/ru/articles/1070314

Cisco Antares: SLM для локализации уязвимого кода

Cisco представила Antares — семейство SLM для поиска файлов с известной уязвимостью внутри репозитория. Выпущены Antares-350M и Antares-1B; Antares-3B пока только готовится. Ставка сделана на узкую задачу, локальный запуск и меньшие вычислительные требования по сравнению с универсальными моделями. Наконец по настоящему SLM, а не вот эти 30b или даже больше, которыми называют SLM.

Antares работает как классический агент. Модель получает описание класса уязвимости и исследует снимок репозитория через grep, find, cat и другие linux команды. Она читает файлы, меняет направление поиска и возвращает список кандидатов вместе с трассой исследования. Результат рассчитан на первичный триаж, а не готовый вердикт или исправление.

В основе моделей лежит IBM Granite 4.0 350M и 1b. Сначала проводилось SFT на данных по ИБ-рассуждениям, исследовательским задачам и поиску кода, затем GRPO на многоходовых сессиях агента. Корпуса и конвейер генерации данных закрыты, поэтому воспроизвести обучение или проверить пересечение с тестовым набором нельзя.

Для оценки Cisco выпустила VLoc Bench: 500 задач из 290 репозиториев, шести экосистем и 147 CWE.
1. В Phase A агент получает уязвимый снимок и оценивается по File F1
2. В Phase B — исправленный снимок, где измеряется способность не поднимать ложную тревогу.
Лимит: 15 терминальных вызовов на задачу.

По данным Cisco, File F1 составляет 0,135 для Antares-350M, 0,209 для Antares-1B и 0,223 для ещё не выпущенной Antares-3B. У GPT-5.5 xhigh — 0,229. Специализированная модель на 3 млрд параметров приблизилась к GPT-5.5 на этом конкретном тесте, что очень круто)

Абсолютные значения не позволяют считать задачу решённой. Лучший результат остаётся на уровне 0,229, 190 из 500 примеров не прошла ни одна протестированная система, а на крупнейших репозиториях средний результат падает примерно в 13 раз относительно самых маленьких. Кроме того, варианты Antares с GRPO оценивались только в Phase A: данных о True Negative Rate на исправленном коде для них нет.

Сравнение моделей не полностью однородно. Antares запускалась через raw completions со специальным префиксом рассуждения, другие семейства — через chat completions и собственные парсеры вызовов инструментов. Общий лимит команд выравнивает бюджет агента, но не весь стек инференса. В карточках моделей и JSON расходятся precision и recall для версий 350M и 1B, хотя File F1 совпадает.

Термин open-weight здесь требует точности. Веса Antares-350M и Antares-1B размещены на Hugging Face в формате safetensors под Apache-2.0, но доступны по только запросу (я уже запросил доступ). Код теста опубликован, обучающие данные — нет. Публичных весов 3B на момент проверки не было.

Antares подходит для триажа по тикетам безопасности (к примеру из DefectDojo или Github/Gitlab или другое ваше ПО), проверки конкретных CWE и локального анализа закрытых репозиториев — как дополнительный слой рядом с SAST, SCA, DAST и ручным аудитом. Независимых прогонов VLoc Bench, проверки утечки данных и нормализованных измерений стоимости, памяти и производительности пока нет, поэтому заявления о превосходстве и эффективности остаются результатами самой Cisco.

🌚 @poxek_ai / Чат канала

Последние два года мы много экспериментировали с доступными guardrail-моделями. Сравнивали готовые решения, обучили несколько собственных моделей, собирали и адаптировали бенчмарки, чтобы понять, как вообще правильно сравнивать качество защиты. Сравнения по одной метрике недостаточно: какая-то модель лучше ловит опасные запросы, но чаще блокирует легитимные, большие модели имеют более высокий F1-score, но дороже в инференсе и имеют больший latency.

В итоге наши наработки мы собрали в GuardRate Leaderboard, где можно сравнивать guardrail-модели по разным параметрам и смотреть на эти trade-offs, настраивая параметры под нужный кейс использования.

Ссылка на лидерборд: https://huggingface.co/spaces/hivetrace/GuardRateLeaderboard

Подробнее про подход, методологию и наши находки читайте на Хабре: https://habr.com/ru/companies/raft/articles/1067854/

Дорогие конкуренты и игроки рынка AI Security, если вы обучаете свои guardrail-модели и хотите увидеть их на лидерборде, напишите нам. Будем рады добавить и прогнать их по тем же тестам, что и остальные модели и услышать вашу обратную связь. Со временем мы автоматизируем этот процесс, но пока добавляем новые модели по запросу.

Поздравляю Софью Балаба с первым релизом ⭐️ и большое спасибо Никите Облакову, Антону Малыхину и Сабрине Садиех за кропотливую работу над тем, чтобы сделать нашу исследовательскую работу публичной 🎉.

Количество инцидентов с AI-агентами растет лавинообразно.

И вот я обнаружил интересный репозитории awesome-ai-agent-attacks, в котором собрана хронология реальных взломов ИИ и уязвимостей AI-агентов за 2024–2026 годы. Только факты, даты, первопричины и ссылки на источники.

Такие репозитории и раньше были, но тут словно полная коллекция, очень много знакомо для меня и так или иначе мелькало перед глазами.

А вот несколько примеров:

🫡 1. ИИ как автономный взломщик. Агенты находят и эксплуатируют уязвимости быстрее людей. Задокументирован случай, когда агенты на базе Kimi K3 обнаружили 19 0-day уязвимостей в Redis за 90 минут, а рабочий RCE-эксплойт собрали за 27 минут. В другом кейсе мультиагентная система нашла цепочку для RCE без аутентификации в WordPress за 10 часов при затратах на API около $25.

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

❌ 3. Выход из песочницы через доверенные инструменты. Агентам (Cursor, Codex CLI, Gemini CLI) не обязательно ломать изоляцию напрямую. Им достаточно сгенерировать конфигурационный файл (например, .claude или таск .vscode). Позже этот файл автоматически выполнится доверенным инструментом разработчика уже за пределами песочницы.

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

Прикольно также, что в репозитории есть интересные цифры под рукой: 99,9% уязвимостей в AI-зависимостях остаются неисправленными даже после выхода патчей, а 82% компаний не подозревают о наличии теневых AI-агентов (Shadow AI) в своей сети.

Математика категорий и ИИ

Любишь читать академичные лонгриды с сомнительной практической пользой? Тогда этот пост для тебя!

О теории категорий обычно говорят как об одной из самых абстрактных областей математики. Довелось прочитать популярную книгу «Восторг абстрактной математики» Юджении Ченг (вслух тебе её прочитают на ютубе, можешь купить на озоне за 4к и в целом за год достаточно прочитать только ее, чтоб собой гордиться, она сложная и АБСТРАКТНАЯ) и статью на хабре, а на основе прочитанного обдумать, где в ИИ теория категорий и зачем она вообще нужна! Посвящаю пост тому, кто хотел взять Юджению с собой в отпуск 🍐.

Дело в том, что теория категорий изучает не сами объекты, а отношения между ними и правила их композиции. Именно поэтому её иногда называют математикой композиции (и математикой математики). То самое "Думай абстрактно!".

Разберу несколько базовых терминов.
🌈 Категория — это совокупность объектов и стрелок (морфизмов) между ними. Стрелки можно последовательно склеивать (композировать), склейка ассоциативна, а у каждого объекта есть тождественный морфизм (стрелка), который ничего не меняет. Всё, три правила.
Например, если есть преобразования

Текст → Эмбеддинг → Ответ

то теория категорий рассматривает всю цепочку как единое отображение.

🌈 Морфизм (Morphism) называют обобщением функции. В абстрактной категории это просто стрелка между объектами, про которую известно лишь, что её можно композиционировать с другими стрелками. А уже в конкретных категориях (например, категории множеств или векторных пространств) морфизмы действительно являются отображениями, сохраняющими структуру. А вот если категория конкретная (объекты — множества со структурой), то морфизм — это гомоморфизм, то есть отображение, сохраняющее структуру. Да, абстракция — это не за пивом в КБ спуститься.
В машинном обучении морфизмом можно считать практически любое преобразование данных:
🍄 токенизация;
🍄получение эмбеддингов;
🍄слой нейронной сети;
🍄attention;
🍄вызов инструмента агентом.
Вся нейронная сеть по сути просто композиция морфизмов.

🌈 Композиция (Composition) — главный объект изучения теории категорий.
Если есть

A → B
B → C

то их можно объединить в одно преобразование

A → C

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

🌈 Функтор (Functor) — отображение между двумя категориями, которое сохраняет их структуру. Переводит объекты в объекты, стрелки в стрелки, и делает это согласованно со склейкой.
Сравню с компилятором, зря что ли по ним учебники прочитаны.
Но самый понятный пример из ML — эквивариантность. Повернуть картинку и потом сегментировать = сегментировать и потом повернуть маску. Оба пути дают одно и то же — функториальность.

🌈 Натуральное преобразование (Natural Transformation) — способ согласованно преобразовать один функтор в другой. Если существуют два различных способа перевести текст в эмбеддинг, натуральное преобразование описывает, когда эти способы эквивалентны с точки зрения всей системы. С понятием эквивалентности в книге тоже пришлось помучиться, т.к. эквивалентны не значит равны!

🌈 Монада (Monad) — один из самых известных объектов теории категорий. Формально это эндофунктор (функтор из категории в саму себя) с двумя дополнительными операциями, удовлетворяющими определённым законам. Ближайший пример из МЛ практики — цепочка вызовов тулов агентом (каждый шаг тащит за собой контекст, состояние и возможный отказ, а монада описывает, как такие шаги корректно склеивать). Ради этого их в программирование и притащили — описывать вычисления с побочными эффектами (чтение памяти, вызов API и дальше придумай сам примеры).

А где здесь ИИ и зачем вообще этот пост?
Интерес к теории категорий в МЛ возник не потому, что она позволяет сделать трансформер умнее 😡. Скорее она предлагает единый математический язык для описания сложных AI-систем.
Сегодня появляются работы, где через категории описывают:
👋 композицию нейронных сетей;
👋 backpropagation и автоматическое дифференцирование;
👋 архитектуры глубокого обучения;
👋 мультимодальные модели;
👋 агентные системы;
👋 нейросимвольный AI.
Крч, надо ознакомиться с терминологией, потому что может пригодиться.

Что почитать?
Если ты дочитал до сюда и думаешь, что у меня свистит крыша и в МЛ это никому не надо, то статьи 2021 и 2024 годов:
⌚️ Обзор Category Theory in Machine Learning (2021) — хорошее введение в применение категорий в ML.
⌚️ Прямое продолжение первого, где авторы заявляют его как обновление и расширение обзора Shiebler et al. Систематизируют четыре направления — градиентное обучение, вероятностные модели, методы на основе инвариантности и эквивариантности и обучение на основе топосов. Последнее направление отвечает за интерпретируемость, композиционность и анализ глобальной структуры AI-систем.

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

Вот такой скучный лонгрид! От абстракций голова кругом.
Все!
🏆

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

В чем суть? Успех семантической атаки зависит от того, поддастся ли модель манипуляции. Структурная же атака срабатывает всегда (вероятность успеха - 100%), независимо от того, что под капотом: легкая и дешевая модель или топовая модель. Например, злоумышленник эксплуатирует отсутствие криптографической подписи у транзакции или подменяет скрытые поля в API-запросах.  Модель может быть идеально выравнена и безопасна, но если сам протокол имеет дырки, то агент просто и эффективно переведет деньги не туда.

Немного данных:

1) Найдено 33 структурные уязвимости на трех независимых платформах (CoralOS, Fetch.ai uAgents и Google AP2).
2) Выделено 6 первопричин (от отсутствия проверки целостности реестра до race conditions при проведении платежей).
3) Три из этих уязвимостей легко выстраиваются в полноценную цепочку атаки для перехвата транзакций.
4)Тесты (1440 запусков) показали: популярные модели вроде GPT-4o-mini и Gemini Flash пасуют перед косвенными промпт атаками в описании агента в 99–100% случаев.

Хотя вот на этом моменте можно поставить двойку. Где Opus 4.8, где GPT 5* ?

Отдельного внимания заслуживает сама среда тестирования (AIP-Bench) и её датасет на HuggingFace. Это 16 жестких сценариев с однозначным результатом.
Они разбиты на 6 классов атак: от подмены личности плательщика и утечек секретов до атак на цепочку поставок маркетплейса и уязвимостей типа TOCTOU (Time-of-check to time-of-use). В случае с TOCTOU злоумышленник использует рассинхронизацию системы: он успевает подменить данные (например, адрес кошелька получателя) ровно в ту долю секунды, когда агент уже проверил безопасность операции, но еще не успел нажать кнопку «отправить».

И тут есть уже моменты, на которые нам стоит обратить свой взгляд. Множество бенчмарков, даже тот же AgentDyn, о котором я писал - используют LLM в качестве судьи. Но LLM-судью тоже можно обмануть, да и от галлюцинаций никто не застрахован.

AIP-Bench опирается только на жесткие, детерминированные проверки. HTTP-коды ответов, точные совпадения адресов кошельков, регулярные выражения в логах, подсчет событий. Никакой чёрной магии. Только проверяемые события.

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

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

А ещё давно я не просил у вас бустов в канал https://t.me/boost/pwnai

😒