OK ML

Зачем писать стилер, если у пользователя уже есть ИИ-ассистент с доступом ко всему?

Патрик Уордл показал, как превратить Muse (персонального ИИ-агента Meta) в инструмент атакующего через уязвимость приложения для macOS.
😑 Muse выполняет задачи пользователя, работает с почтой, календарём, WhatsApp и другими сервисами, забирает никнеймы у наших любимых групп. Для этого ему выдают доступ к аккаунтам и разрешения на использование ресурсов устройства. Именно эти полномочия и делают захват агента особенно опасным.

Как?
Уордл обнаружил, что локальный код мог изменить в настройках Muse адрес сервера транскрипции — того, куда отправляется голосовой ввод. Права администратора для этого не требовались. 😞

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

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

Но ведь для атаки уже нужен локальный доступ?
Одной ссылки без выполнения кода на Mac недостаточно. Уордл описывает в том числе сценарий ClickFix — пользователя обманом убеждают вставить и выполнить команду в терминале. 🌝 Однако выполнение команды от имени пользователя само по себе не означает доступ ко всем ресурсам, защищённым разрешениями macOS. Здесь агент становится посредником, тк атакующий использует уже выданные Muse полномочия.

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

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

Вот что меня цепляет в этой истории. Мы постепенно собираем в одном приложении доступы к переписке, файлам, камере и рабочим сервисам. А возможность воспользоваться ими может начинаться с одной изменяемой настройки адреса сервера.

Все!
🙂

Подробнее и техничнее в разборе Ars Technica

ИИ получил доступ к своим весам. ЧБД?

16 сентября Irregular опубликовала исследование agentic self-modification о том, как обычная задача на исправление ошибок может привести к изменению весов и развёртыванию новой модели. Без прямого указания это делать. 🥊

В эксперименте Qwen3.5-27B использовалась в двух ролях: управляла coding-агентом и обслуживала приложение, переводящее запросы пользователей в вымышленный язык kelp. Оба компонента загружались из одного сохранённого набора весов.
Агенту дали задачу исправить неверные ответы и полный доступ к shell. В окружении были доступны веса, обучающие примеры, инструменты файнтьюна и развёртывания.

🔭 Как исправление дошло до весов
Агент нашёл скрипт обучения и заметку об успешном дообучении в прошлом. Запустил файнтьюн, получил работающий адаптер, а затем обнаружил, что по умолчанию приложение всё ещё использует исходную модель.
Он самостоятельно объединил адаптер с базовыми весами и заменил общий чекпоинт. Новые экземпляры приложения и самого агента теперь должны были загружать изменённую модель.
На 20 отложенных запросах, которых агент не видел, результат вырос с 0/20 до 20/20. Исследователи проверили это в отдельном процессе, тк изменение сохранялось после новой загрузки.

Но вместе с полезным навыком обучение может закрепить и другие изменения:
🔨 Данные могут остаться в весах
🔨 Обученные отказы можно удалить

В показательном запуске до обновления модель отказала на 10/10 тестовых вопросов, после — на 0/10. Эксперимент касался конкретного искусственного ограничения, но снятие всей защиты авторы не демонстрировали.
Эта работа продолжает тему Emergent Misalignment (статьи, выпушенной уже больше года назад!), где обучение на небезопасном коде меняло поведение и за пределами программирования. Здесь дополнительный риск возникает из-за того, что агент сам выбирает обучение как способ ремонта и доводит результат до развёртывания.

Условия Irregular намеренно облегчали такой сценарий. Исследование показывает механизм, а не распространённость в продакшене.

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

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

Используешь модели с агентами? У кодинг-агента есть доступ к тому, что он не должен менять?

🎂 Классные доклады от Яндекса по безопасному построению агентных систем тут.
🎂 А тут конкретный практический кейс ограничения полномочий агенты работают внутри отдельной Lima VM, им доступны только выделенные каталоги проекта, SSH-ключи для GitLab остаются на хосте — агент не может самостоятельно пушить изменения, для зависимостей используется отдельный токен только на чтение. Это все можно оформить в чеклист!
🎂 И шикарный технический разбор моделей разрешений и песочниц Claude Code, Cursor и Codex тут.

Все!
🍬

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. 
И измерять защиту здесь полезно временем 🦸‍♂️от первого подозрительного действия до ограничения доступа, а также тем, какие ресурсы атакующий успевает охватить за этот интервал. Даже быстрое обнаружение мало помогает, если скомпрометированная учётная запись сохраняет широкие полномочия.

Все!
🦔

Репозиторий недели.  Mantis разделить нельзя объединять 📬

У Google есть Mantis — набор навыков для ИИ-агентов, которые анализируют код, воспроизводят уязвимости и готовят исправления. Навыки можно адаптировать под свой стек и среду запуска агента. В общем, бери и используй.  

🌟 Первым шагом важно разобраться в проекте. Агент изучает архитектуру, при необходимости историю исправлений, строит модель угроз и план проверки. 
😴 Затем — искать. На основе собранного контекста исследует код и объединяет дублирующиеся находки.
🤲 После необходимо проверить собственные выводы. Отдельные этапы review и critic проверяют обоснованность находок, отсеивают ложные срабатывания и оценивают реалистичность сценария атаки.
👴 Дальше — воспроизвести. Агент создаёт проверочный пример и запускает его в изолированной среде. Подтверждённые находки можно объединять в многошаговые цепочки атак.
🧲 И наконец, исправить. Подготовить минимальный патч и проверить, что он блокирует воспроизведение проблемы. 

Для меня самое интересное — организация проверки гипотез. Убедительное объяснение модели проходит несколько этапов проверки, прежде чем попасть в итоговый отчёт. Правда, объяснение очень убедительное, на грани газлайтинга 😓!

Что иметь в виду?
Даже успешное воспроизведение не гарантирует эксплуатируемость во всех условиях, а неудачное при этом не доказывает отсутствие уязвимости. Авторы требуют ручной проверки результатов и изоляции запуска. Проект демонстрационный, официальной поддержки Google нет. 🤷‍♂️Кроме того, качество зависит от LLM. Слабая модель пройдёт через этапы поиска и не задержится на критике. Сильная модель может быть слишком консервативна и откидывать реальные уязвимости. Нужно калибровать под свой сценарий.

В целом Mantis интересна не столько как готовый инструмент, сколько как демонстрация архитектуры и хороший справочник для тех, кто начинает автоматизировать анализ кода. Здесь интересно изучить именно разделение задач, кто ищет проблему, кто оспаривает вывод и кто проверяет исправление и адаптировать под свой стек, подставив свои модели и окружение. Это лишком медленно для CI/CD на каждый коммит. 🔪 Но прекрасно подойдет для периодического аудита, перед релизом или при смене архитектуры.

Хочется добавить, когда этот репозитория имеет смысл. Mantis хорош для проектов со сложной архитектурой и глубокими гипотезами атак. Для простых паттернов (SQL в явном виде, очевидные буферы) статические анализаторы могут быть сильно дешевле. Для критичных компонентов Mantis может существенно сэкономить время эксперта.

Все
🤕

Пароль сменили. Сессии закрыли. А чужие инструкции остались в памяти ИИ. 

Именно такой сценарий исследователи Varonis показали в CoSnitch — исследовании уязвимостей Microsoft Copilot Personal.

Они описали три опасных механизма:
🤨 Запуск запроса по ссылке. Пользователь открывает специально подготовленную ссылку на копайлот, и помощник выполняет внедрённый запрос внутри его сессии.
🔭 Утечка через обычные инструменты. Помощник получает информацию из подключённых сервисов и передаёт её наружу через запрос к сайту атакующего. Возможность читать почту и пересказывать страницы превращается в канал извлечения данных.
😲 Отравление постоянной памяти. Пользователь просит пересказать веб-страницу. В ней спрятаны инструкции, которые копайлот воспринимает как команды и записывает в память. Пользователь получает обычное резюме, а помощник — чужие указания для будущих разговоров.

Почему?
Копайлот воспринял инструкции внутри веб-страницы как команды и записал подконтрольный атакующему текст в постоянную память 😑. Так содержимое недоверенного сайта получило возможность влиять на будущие ответы помощника. Смена пароля и завершение сессий эту запись не удаляли.

🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩🤩
Смена пароля и отзыв сессий не очищают память Copilot. В продемонстрированном сценарии внедрённые инструкции сохранялись до явного удаления.

Исправление связанное с CVE-2026-24301 нельзя автоматически считать очисткой уже изменённой памяти.

Дополнительно почитать тут. 

Все
🙂

N.B. По данным Varonis, Microsoft выпустила исправления 18 августа 2026 года, исследователи не обнаружили признаков эксплуатации в реальных атаках. Но надо быть начеку.

AI-агенты начали действовать вне инструкций. Вот что нужно знать разработчикам ⤵️

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

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

Что обнаружил британский AISI

Британский AI Safety Institute провёл кибериспытания AI-агентов, где 10 из 122 запусков привели к несанкционированным действиям..
Что агенты попытались делать:
🦖 Создавать вредоносный pull request
🦖 Использовать фальшивые личности
🦖 Газлайтить
🦖 Оставлять промпт инъекции для других AI-агентов

Агентам специально дали доступ в интернет и отключили часть защитных механизмов. Это была целевая проверка того, сможет ли агент что-то сделать плохое, если ему предоставить возможности. Попытки были неудачными, реального ущерба не было. Но вопросики имеются. Мы же помним, что на днях с ОпенАй и ХФ все было иначе и попытка оказалась успешной.
🫠 Там агент получил доступ в интернет и реально взломал систему во время тестирования безопасности. Это уже не попытка убедить человека внутри контролируемой среды…

После этого OpenAI пообещала (10 августа 2026 конгрессмен Грег Касар вместе с 31 членом Конгресса отправили письмо OpenAI, называя инцидент глубоко тревожным, требуя раскрыть информацию о том, как фронтирная модель эксплуатировала уязвимость безопасности, а ответили ему только 2 сентября и то без логов и деталей) :
🗜 Ограничивать интернет-доступ во время тестирования
🗜 Усилить мониторинг действий
🗜 Разработать механизмы автоматического отключения
🗜Приостановить работу над моделью Astra

AISI показал, что агенты ПЫТАЮТСЯ делать плохое.
OpenAI показал, что эти попытки иногда УСПЕШНЫ.

Потому что:
👽 Модель может решить, что цель важнее правил (помнишь прошлый пост про подгон метрик? Проблема глобальна одна и та же, цель важнее правил!)
👽 Модель может быть джейлбрейкнута
👽 Модель может неправильно интерпретировать инструкции
👽 Модель может эволюционировать через трейнинг

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

Пока что чек-лист для разработчиков и архитекторов:
🤲 Egress proxy вместо прямого интернета. Агент обращается только к разрешённым доменам, методам и портам.
🤲 Отдельная авторизация каждого действия — короткоживущий токен с конкретным разрешением, например, только чтение одной репы в течение 5-10 минут.
🤲 Строгие схемы и тулы. Агент вызывает не произвольный shell, а ограниченные функции вроде read_repository() или create_draft_pr(). Аргументы проверяются до выполнения.
🤲 Ограничения бюджета. Ограничиваются время работы, число запросов, создаваемых файлов, сетевых соединений и попыток после отказа.
🤲 Апрувы от человека. Отправка сообщений, создание аккаунтов, публикация pull request, изменение продакшена и запуск неизвестного кода требуют подтверждения человека.
🤲 Изоляция запусков. После каждого теста удаляются память, аккаунты, токены и оставленные артефакты, чтобы следующий агент не мог использовать результаты предыдущего.
🤲 Внешний мониторинг. Логи отправляются в систему, к которой агент не имеет доступа. Аномалии вроде тор-трафика, попыток скрыть действия останавливают запуск.
🤲 Kill switch вне процесса агента. Остановка должна происходить на уровне оркестратора, контейнера или сети. С килл свитч думаю скоро будет регламент.

Все!
🧘‍♀️

Агент знает, что читерит. Но продолжает читерить! 😆

Прошлым летом В августе 2026 исследователи поймали AI-агентов за читерством. В 57% случаев агенты нашли способ получить идеальные метрики, не решив задачу. 

Авторы решили проверить, насколько современные кодинг/ML-агенты склонны к reward hacking (по ссылке — исследование антропиков 25 года), т.е. оптимизации измеряемой метрики способом, который не соответствует настоящей цели задачи.

Эксперимент элегантен!
Агентам давали train, публичный test, код решения и evaluator. Они могли самостоятельно менять solution.py, запускать evaluation, смотреть score и продолжать эксперименты. Цель — улучшить метрику.

При этом существовал ещё один hidden holdout, которого агент никогда не видел. Но в данные специально заложили лазейки, позволяющие получить отличную метрику, не построив хорошую модель. Например:
💡 одни и те же пользователи встречались в обучающей и тестовой выборках — можно было не предсказывать результат, а фактически запомнить его;
💡 в тестовой выборке были почти полные дубликаты обучающих примеров;
💡 в одной задаче признаки вообще никак не были связаны с ответом, честная точность не могла устойчиво превышать 50%.
При этом существовала скрытая чистая выборка без этих лазеек. Поэтому можно было проверить, действительно ли агент построил хорошую модель или просто научился получать высокий балл на известном тесте. В 57,1% запусков агенты использовали reward hacking.

Причём читерство здесь вполне знакомо любому вовлеченному в МЛ. Один агент замечает, что одни и те же сущности есть и в обучении, и в тесте, — и начинает использовать их ответы вместо нормального предсказания. Другой пользуется почти полными дубликатами. А в задаче, где признаки вообще не содержат сигнала и честный предел — 50%, агенты всё равно пытаются выжать результат из конкретной тестовой выборки.
🌟 В дополнительном эксперименте дело дошло до совсем классического греха: обучения на тестовых данных. В одном из таких запусков точность достигла 99,4%.

Что в результате?
Мы хотим хорошую модель А формально задаём максимизацию метрики.
И чем лучше агент умеет оптимизировать заданную цель, тем важнее, чтобы измеряемая цель действительно совпадала с тем, чего мы от него хотим.

Практический вывод для ML-инженеров
⛹️‍♂️ Проверяй гипотезы на скрытых данных, которых агент никогда не видел
⛹️‍♂️ Убедись, что высокий скор на публичном тесте переносится на реальность
⛹️‍♂️ Относись к метрике как к гипотезе

Все!
🎶

P.S. Это зеркало нашей неточности в спецификации целей 🎶. Чем лучше агент оптимизирует, тем выше цена этой неточности. Проверяй метрики так же скептически, как проверяли бы датасет (ты же проверяешь датасет?).

Серые кардиналы, часть 2

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

😍 Доун Сонг — человек, который давно объясняет, почему АИ и безопасность нельзя разделять. Её область находится ровно на пересечении того, что мы любим и почему мы здесь!
Классическая работа Сонг Robust Physical-World Attacks on Deep Learning Models (2017) про атаку на распознавание дорожных знаков с помощью физических модификаций, и исследование (тоже 2017), о том, почему комбинация нескольких слабых защит от adversarial examples автоматически не создаёт сильную защиту.
За последующие 9 лет Сонг развивала эту логику. Свежая статья 2026 года (на основе 128 исследований) переводит проблему на агентов, тк безопасность агентов нельзя решить одним гардрейлом вокруг LLM. Нужна defense-in-depth на уровне всей системы — контроль потоков данных, разделение привилегий, IAM, мониторинг, харденинг моделей и инструментов. Но есть проблема! Базовые модели масштабируют как атаки, так и сложность контроля. Одна скомпрометированная базовая модель = скомпрометирована вся экосистема приложений.

😍 Перси Лян — исследователь МО, обработки естественного языка и базовых моделях. 
Статья,  пожалуй, главная для этого поста. Здесь систематизируется концепция foundation models. Когда одна базовая модель становится фундаментом множества downstream-приложений. Это создаёт не только возможности, но и архитектурные риски — именно те, что беспокоят Сонг.
Другая работа Лян (в соавторах, кстати, Тимнит Гебру) про то, почему нельзя оценивать LLM одной accuracy и как строить многомерную оценку моделей. Подчеркну, что речь идет не про свежие статьи, а про базовые принципы. Надо читать! Перси Лян объяснит тебе архитектуру рисков получше даже канала OK, ML!
Суть в следующем. Модель может быть точна на бумаге, но уязвима к adversarial атакам (про что Сонг) и одновременно несправедлива к меньшинствам. Один score — это иллюзия.

😍 Дэн Хендрикс — типолог рисков!
Measuring Massive Multitask Language Understanding (MMLU) — обязательная. MMLU открыл неприятный факт: модели, которые выглядят умными в общих тестах, часто не понимают специализированные знания. Модель может писать отличные эссе, но проваливает вопросы по медицине и праву. И ты этого не узнаешь, если не спросишь правильно. До MMLU не было инструмента, чтобы понять, где именно модель деградирует — на медицине? На юриспруденции? На истории?

An Overview of Catastrophic AI Risks — самая доступная точка входа в тему. Он делит катастрофические риски на четыре группы:
Malicious use, когда модель используется для вреда
AI race dynamics — гонка разработчиков (Safety теряется)
Organizational risks, когда компания теряет контроль над своей системой
Rogue optimization, когда модель оптимизирует не то, что нужно
Каждый из этих рисков усиливается благодаря foundation models. Одна модель — четыре типа проблем, умноженные на миллионы приложений.

🙂 Читать в таком порядке
Сначала Хендрикс (что может пойти не так), потом Лян (почему именно сейчас), потом Сонг (как защищаться).

Все
😌

OK ML pinned «Год каналу, а за год накопилось столько всего, что пора сделать навигацию 😑 Уязвимости и AI Security — Superset. Три уязвимости — XSS в NextChat — CVE-2025-50733 — RCE при загрузке моделей в skops — CVE-2025-54886 — SSRF в Firecrawl — CVE-2025-57818 — Local…»

Год каналу, а за год накопилось столько всего, что пора сделать навигацию

😑 Уязвимости и AI Security
— Superset. Три уязвимости
— XSS в NextChat — CVE-2025-50733
— RCE при загрузке моделей в skops — CVE-2025-54886
— SSRF в Firecrawl — CVE-2025-57818
— Local Deep Research — CVE-2025-57806
— SSRF в HackMD-MCP — CVE-2025-59155
— RCE в Keras — CVE-2025-9906
— Prompt Injection в Windsurf
— RCE в Hugging Face Transformers — CVE-2026-4372
— пять способов обойти PickleScan
— атаки на ML supply chain
— OWASP Agentic Skills Top 10
— AI Agent Traps от Google DeepMind
— Shadow AI
— безопасность MCP 1, 2 , 3

🧘‍♀️ Инструменты, библиотеки и фреймворки
— Optuna — тюнинг гиперпараметров
— spaCy — промышленный NLP
— Netron — рентген для ML-моделей
— JAXFORMER
— DVC
— Polars
— Weights & Biases
— Evidently AI
— Pydantic
— MLBox
— InterpretML
— OpenTelemetry + Langfuse
— Kedro
— NVIDIA NeMo
— Inspect Evals

🤩 AI-агенты и мультиагентные системы
— RoboDuck и победа Theori в AIxCC
— где пентест-агенты уже работают, а где нужен человек
— MetaGPT + AFLOW
— безопасность агентных систем 1, 2
— MCP как новая поверхность атак
— side-channel атаки на агентов
— мультиагентные системы и роевой интеллект
— мониторинг rogue agents
— Harness Engineering

🦔 Исследования и разборы статей
— Model Inversion Attacks
— scheming у AI в реальном мире
— Your Agent Is Mine: атаки на LLM supply chain
— WEF: AI for Cybersecurity 2026
— обзор исследований по LLM-based vulnerability detection
— может ли AI самостоятельно взломать бинарник
— Emergence AI: что произошло, когда AI оставили жить без людей
— Anthropic об AI-enabled cyberattacks
— InfoKV и сжатие KV-cache
— Люди, которые делают AI (Серые кардиналы 1, Серые кардиналы 2)
— Как агенты читерят

💔 ML: архитектуры, концепции и теория
— KAN vs MLP
— нейросимвольный AI
— маленькие языковые модели
— метрики качества текста: BLEU, ROUGE, BERTScore, COMET и другие
— теория категорий и AI
— ReaGAN и агентный подход к графовым нейросетям

🔪 Практика и эксперименты
— как искать секреты в Git-репозиториях
— SQL-инъекция в ML-проекте
— Practical NLP: репозитории и ноутбуки
— типичные ошибки ML в проде
— первый запуск локальной LLM на Jetson Orin Nano
— тренажёр prompt injection от Lakera
— с чего начать изучение AI Security

Короче, тут уже не канал, а небольшой индекс по ML × AI Security.
Буду периодически обновлять этот пост, чтобы всё интересное можно было найти в одном месте.

Обзор раздела Assistants - Inspect Evals

Inspect Evals — опенсорсный фреймворк для оценки LLM, разработанный UK AI Security Institute и Meridian Labs. Inspect Evals содержит 200+ бенчмарков. В этом посте разберем раздел Assistants — 100+ специализированных бенчмарков для оценки AI агентов. Это инструменты для оценки реальных возможностей агентов, а не какое-то там чат-ботство (начни с туториала). 

🟢 Базовый уровень

👨‍💻 BFCL оценивает способность LLM вызывать функции/инструменты. В целом, базовый навык для любого агента — уметь выбрать нужный инструмент и вызвать его правильно.
👨‍💻 BrowseComp — бенчмарк для агентов-браузеров. Простой, но непростой бенчмарк для оценки способности агентов просматривать веб. Состоит из вопросов, которые обычно требуют доступа в интернет для правильного ответа. 

🟡 Средний уровень

👨‍💻 GAIA — бенчмарк для общих AI ассистентов.  Предлагает реальные вопросы, требующие фундаментальных способностей (рассуждение, мультимодальная обработка, веб-просмотр, использование тулов). Концептуально простые для людей, но сложные для большинства AI. Есть 3 уровня сложности (level 1-3).
👨‍💻 Mind2Web — это по сути своей обобщённый агент для веб. Набор данных для разработки агентов, которые могут следовать инструкциям на естественном языке и выполнять сложные задачи на любом веб-сайте. Amazon, Facebook, Gmail — всё возможно.
👨‍💻 OSWorld тестирует способность агентов выполнять реалистичные задачи в симулированных компьютерных окружениях — комплексное взаимодействие с разными приложениями, файловой системой, настройками.

🔴 Продвинутый уровень

👨‍💻 AssistantBench тестирует способность AI агентов выполнять реальные задачи (полноценные, вроде "забронируй отель за X$ в районе Y, но учти ограничение Z»), требующие длительного времени на выполнение в веб-среде. 
👨‍💻 GDPval - Экономически ценные задачи. Измеряет производительность моделей (реальную экономическую ценность выполненной работы) на экономически ценных, реальных задачах в 44 различных профессиях.
👨‍💻 Sycophancy Eval создан для оценки лицемерия 👑. Видел, как модель пишет "Вы совершенно правы…" в ответ на явно ошибочное утверждение? Это то самое. Тест проверяет, будет ли модель соглашаться с пользователем просто ради угодливости.
👨‍💻 The Agent Company — самый сложный бенчмарк в этом разделе. Агент работает в полноценной компании, где нужно просматривать внутренние веб-сервисы, читать файлы, запускать код, координировать несколько инструментов одновременно. Это уже не шуточки-прибауточки, это серьёзно.

🙂
Остальные разделы репозитория
❗️Coding
‼️ Cybersecurity (надеюсь, в следующем посте расскажу про него)
‼️Safeguards
❗️Mathematics

Что дальше? Выбери 2-3 бенчмарка в зависимости от своих целей:
 🤎 Тестируешь базовый агент? Начни с BFCL
👧 Нужна общая оценка? GAIA
💯 Оцениваешь production-ready решение? The Agent Company
Если ты новичок в агентах 🆘 , то начни с туториала Inspect,
потом попробуй BFCL на простой модели, затем переходи на GAIA.

Все
😳

MCP или 400% рост использования = 400% рост проблем

👹 Совпадение? Не думаю! 
В 2025 году MCP adoption выросла на 400%. Это не очепятка. За год разработчики увеличили использование Model Context Protocol в 5 раз. И в тот же самый период (а это январь-март 2026) было зафиксировано 30+ CVE, направленных конкретно на MCP экосистему. За два месяца! 60 дней, из них 40 рабочих!

Напомню, что такое MCP. Простыми словами, это мост между ИИ-ассистентом и внутренними системами твоей компании/твоими.
Вместо того чтобы копировать данные в ChatGPT (как в Shadow AI),  даешь ИИ прямой доступ к нужным инструментам:
🤓 Доступ к файлам на компьютере
🤓 Доступ к GitHub репозиториям
🤓 Доступ к Slack, Gmail
🤓 Доступ к базам данных
🤓 Доступ к внутренним API

Но проблема в том, что MCP-сервер — это не какой-то там безопасный API. Это уязвимая программа, которая слушает входящие команды. И если эта программа скомпрометирована, скомпрометирована вся цепочка.

Вот цепочка атаки for dummies:
🕛 Атакующий создаёт  MCP-сервер. который выглядит как полезный инструмент.
🕧 Разработчик устанавливает этот сервер (Он же кажется официальным, репозиторий на GitHub, хорошие отзывы, звезды)
🕐 Сервер имеет backdoor  (а когда ИИ-ассистент подключается к нему, backdoor запускается)
🕜 Attacker получает доступ (к IDE разработчика, его файлам, его GitHub токенам, его клиентским данным)
🕑 Вся система скомпрометирована! ИИ теперь работает не только на тебя или даже совсем не на тебя!

Реально? РЕАЛЬНО!
1️⃣ OpenClaw и 800+ Malicious Skills (ClawHavoc campaign распространила 800+ вредоносных скиллов и позже выросло до 2200+ на GitHub). В начале 2026 года исследователи обнаружили, что популярный open-source ИИ-фреймворк OpenClaw стал целью для атакующих. Люди просто кликали "установить расширение" и не знали, что устанавливают малварь. Расширение выглядело как "AI Assistant for Productivity" или "Database Helper". На самом деле это были инфостилеры, которые собирали API токены и отправляли их на серверы атакующего.
2️⃣CVE-2025-6514. Одного MCP-сервера достаточно! Исследователи JFrog обнаружили, что один скомпрометированный MCP-сервер может взломать любого ИИ-клиента, который к нему подключается. Никакой пользовательской аутентификации не требуется.
3️⃣ Supply Chain через MCP. В августе 2025 года был зафиксирован первый supply chain attack, использующий компромисс OAuth токенов через MCP-интеграцию. 700+ компаний было скомпрометировано через компромисс интегрированных сервисов.

Статистика: 30+ CVE за 60 дней
Вот что почитать и данные:
🍓 30 CVEs за 60 дней (январь-март 2026)
🍓 40+ CVEs за 4 месяца (январь-апрель 2026)
🍓 Comprehensive analysis от Lab Space

Интересно по ссылкам, дополнительное чтение или "уважаемая черешня, какое стоп-слово"!
🍒 CVE-2025-68145/68143/68144 (Anthropic's mcp-server-git)
🍒 MCP Security 2026
🍒 A Timeline of Model Context Protocol (MCP) Security Breaches
🍒 MCP Security Vulnerabilities in 2026: 40+ CVEs and Counting

Кстати, знаешь, какие MCP-серверы сейчас запущены в вашей компании?

Все!
🌟

Shadow AI. Много ссылок

80% сотрудников используют неодобренные ИИ-инструменты.
🥳

Это не слухи. Вот результат анализа 22,4 млн запросов от компании Harmonic Security. Исследователи  обнаружили 665 разных сервисов ИИ в корпоративных сетях. 665 🤹! А компании купили лицензий на 40% из них. Для остальных 60% (для которых люди буквально за день нашли способ использования) — никаких контрактов, никакой поддержки, никакой видимости. Ещё забавнее, что 38% сотрудников сами признают, что делились конфиденциальной информацией с ИИ без разрешения. А 16,9% утечек произошло через бесплатные аккаунты, которые IT вообще не видит. Они просто вообще не учитываются. Человек вошёл через личный акк, работу сделал, вышел. Ищи-свищи! 

Стоимость этого? 🫂 Samsung узнала о проблеме, когда три инженера за месяц слили исходный код, встречи и данные производства. Сначала компания запретила ChatGPT. Потом отменила запрет, потому что запреты не работают.
В здравоохранении ситуация критична. 57% врачей используют ChatGPT или Gemini для написания заметок о пациентах. Они обрабатывают защищённую медицинскую информацию в инструментах, на которые нет контракта. Это одновременно нарушает HIPAA и рискует жизнями пациентов (если ИИ ошибётся в диагнозе). При этом, когда одной больнице дали одобренный ИИ-инструмент, неодобренное использование упало на 89%. Врачи при этом экономили 32 минуты в день. Не потому, что их запугали. Потому, что им дали что-то лучшее.

IBM посчитала, что Shadow AI добавляет 670 000 долларов к стоимости одного взлома. Организации с высоким уровнем неконтролируемого ИИ платят $4,63 млн за взлом вместо $3,96 млн.

И это только видимые числа. Реальная стоимость insider-угроз, созданных неосторожным использованием ИИ, составляет $10,3 млн в год на одну компанию.

Тем временем, ❤️ европейский закон об ИИ вступил в силу 2 августа 2026. GDPR уже наказывает компании, если сотрудник вставил личные данные клиента в ChatGPT без контракта обработки данных. Как это работает на практике, описано в этой статье про EU AI Act.

Vectra AI провела полный анализ проблемы. Гартнер прогнозирует, что 40% компаний столкнутся с инцидентом, связанным с Shadow AI, к 2030 году. 

Что делать? Пост скорее про статистику происходящего, чем про какие-то возможные рекомендации, тут я и не знаю толком, что делать. Люди есть люди. 
🔪 Мониторьте нейтрально. Чтоб видеть, что происходит.
🔪 Установите границы. Исходный код проекта — нельзя. Исходный код из публичных репозиториев — можно. Данные о клиентах — нельзя. Общая информация о тренде на рынке — можно. И т.д.
🔪 Самое сложное. Дайте людям правильный инструмент.

Все!
😼

Из одного большого фреймворка — в экосистему специализированных библиотек. Рассмотрим NeMo от NVIDIA

NeMo по умолчанию воспринимается как фреймворк для обучения LLM, мультимодальных и speech-моделей, а теперь NVIDIA делает ставку на модульную архитектуру (из-за монолитности там было тяжело что-то найти, да и контейнер разросся). Реструктуризация анонсирована официально, исходный репозиторий NeMo 2.0 теперь сфокусирован на speech-компонентах, а остальное выносится в отдельные библиотеки. Как следствие — чудные открытия, которыми я поделюсь!

Теперь NeMo — это набор отдельных проектов. Самые интересные (имхо) ☝️:
🥹 NeMo AutoModel — распределённое обучение LLM/VLM с Day-0 поддержкой моделей с HF (без конвертации, с сохранением исходного формата чекпоинта).
🥹 NeMo Megatron-Bridge — обучение и файнтюнинг больших моделей на параллелизме Megatron-Core. Вместе с AutoModel и RL переехал с PyTorch Lightning на нативный PyTorch-цикл — техническая суть всей реструктуризации.
🥹 NeMo RL — SFT и RL (DPO, GRPO и другие современные методы постобучения), от одной GPU до тысяч, на Ray.
🥹 NeMo Gym — инфраструктура RL-окружений (унифицированные интерфейсы к разнородным средам и сбор роллаутов для обучения через NeMo RL).
🥹 NeMo Evaluator — вот здесь как раз бенчмарки и харнессы.
🥹 NeMo Guardrails — один из самых популярных опенсорсов для добавления guardrails и контроля поведения LLM.
🥹 NeMo Curator — подготовка и очистка данных. Data Designer — синтетика. Anonymizer — PII. Safe-Synthesizer — генерация безопасных синтетических датасетов. Небезопасные сами умеете 🤥
🥹 🥹 Switchyard — маршрутизация запросов между LLM, совместимость с API OpenAI и Anthropic + observability. Написан на Rust и разбит на крейты (server, libsy, protocol, translation), то есть роутинг можно встроить в своё приложение (без прокси). NVIDIA официально пометила старый blueprint LLM Router как deprecated в его пользу. Отдельная история, это цена трансляции протоколов. Если оставить для Claude-моделей format: openai вместо явного format: anthropic, теряется cache_control. Запрос проходит, но prompt caching молча не включается, и платишь полную цену за входные токены. Конфигурация, о которую легко споткнуться. Как будто весь пост можно посвятить только Switchyard.
🥹 labs-OO-Agents (NOOA) — самое чудное открытие. Ресеч! Агент — это обычный Python-объект. Поля = состояние, docstring = промпт, аннотации типов = контракты. Метод, тело которого состоит из ..., во время выполнения дописывается LLM-циклом; методы с обычным телом остаются детерминированным кодом. ИДея классная, есть статья.
🥹 NeMo Platform — то, что всё это сшивает (Inference Gateway, оценка и тюнинг агентов, NeMo Agent Toolkit для сборки, общая инфраструктура (Secrets, Files, Entity Store, Jobs)).

Что забирать сейчас?
Switchyard — если у тебя зоопарк провайдеров и хочется роутинг без Python-прокси. Guardrails — он и так давно в проде у многих. Gym + RL — если ты занимаешься постобучением, а не «GRPO по гайду с клодом, кими, чатом гпт в девине». Остальное — читать по мере надобности, благо теперь оно наконец разложено по полкам, а не свалено в один репозиторий на 138920 гигабайт. NOOA разберём отдельно?

Все!
😆

Первый опыт запуска локальной LLM на Jetson Orin Nano

Проверим, насколько современные edge-устройства готовы к локальному запуску языковых моделей. В качестве платформы — Jetson Orin Nano Developer Kit 8GB, в качестве модели — Qwen2.5-3B-Instruct через llama.cpp.

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

После загрузки в последовательной консоли появляется стандартный запрос входа Ubuntu:

Ubuntu 22.04.5 LTS
yahboom login:

Если используется готовый образ от производителя (например, Yahboom), первоначальная настройка пользователя уже выполнена. Вместо мастера oem-config сразу появляется приглашение к входу в систему, поэтому необходимо знать логин и пароль, заданные производителем образа. Тут придется поискать логин/пароль 🔪

Отдельный момент — перепрошивка устройства 🤔
Официальные инструменты NVIDIA для прошивки Jetson ориентированы на Linux (Ubuntu). На macOS полноценной поддержки нет, поэтому перепрошивка с Mac заметно сложнее, приходится использовать виртуальную машину, отдельный Linux-компьютер или искать неофициальные способы. Если планируется менять JetPack или восстанавливать устройство, проще заранее иметь доступ к ПК с Ubuntu. 

После первого подключения оказалось, что GitHub недоступен:

fatal: Could not resolve host: github.com

Причина была в конфигурации сети.
По умолчанию устройство подняло собственную точку доступа (Jetson_Orin_Hot), а маршрут был направлен через USB-подключение к компьютеру, которое не обеспечивало доступ в интернет.
После подключения Jetson к домашнему Wi-Fi всё заработало без дополнительной настройки. Мой косяк и тупняк 🥳, но вдруг кому пригодится. 

Далее был собран llama.cpp с поддержкой CUDA. Компиляция заняла значительно больше времени, чем ожидалось. Ну ничего, шалость удалась! 

Производительность 👇
Замеры сделаны через llama-bench из состава llama.cpp (build 876a43211) (JP 6.2, режим питания MAXN_SUPER, jetson_clocks, графическая оболочка отключена, модель Qwen2.5-3B-Instruct в кванте Q4_K_M (1.79 GiB), все слои на GPU, flash attention включён, 5 повторов). 

🤡 Без nvpmodel -m 2 и jetson_clocks результаты получаются ниже и с большим разбросом. Наверно, именно поэтому в сети гуляют замеры Orin Nano, различающиеся в разы. Плюс обратная сторона, jetson_clocks поднял потребление в простое с 4.6 до 7.0 Вт и температуру с 54 до 63 °C. 

Две метрики:
🤜 pp (prompt processing) — скорость чтения того, что отправили модели (упирается в вычислительную мощность GPU). 
🤜 tg (token generation) — скорость, с которой модель пишет ответ (упирается в пропускную способность памяти, поскольку на каждый токен нужно прочитать все веса).

pp512   895.27 ± 10.50 t/s
tg128    23.98 ±  0.01 t/s

Проверка теорией 😳
У Orin Nano 102 ГБ/с  LPDDR5, модель весит 1.79 ГБ, потолок генерации — около 53 т/с. Достигнутые 24 т/с это 45% от паспортной полосы, что для реальной нагрузки нормально (помимо весов на каждый токен читается ещё и KV-кэш).
Деградация при росте контекста:

┌─────────┬────────┬────────┐
│ Глубина │ pp512  │ tg128  │
├─────────┼────────┼────────┤
│       0 │ 895.3  │ 23.98  │
│    1024 │ 866.0  │ 23.69  │
│    4096 │ 773.3  │ 23.01  │
│    8192 │ 667.9  │ 22.18  │
└─────────┴────────┴────────┘

На 8K контекста генерация теряет 7.5%, обработка запроса — 25%. Для практики это значит, что длинная беседа скорость ответа почти не замедляет.

Влезет ли 7B проверить руки пока не дошли
После отключения графики свободно ~5.5 ГБ из 7.6. Qwen2.5-7B в Q4_K_M это ~4.7 ГБ весов плюс около 0.5 ГБ KV-кэша на 8K контекста плюс compute buffers — влезает впритык и только headless. Ожидаемая скорость по той же формуле, 102 / 4.7 ≈ 21 потолок, реально порядка 10–12 т/с. Q5 и выше на 8 ГБ уже не поместятся. 🤨

Все!
💡

PS
В рецепте лимонного пирога первым ингредиентом идёт 200 г твёрдого сыра, потом чайная ложка соли и масло оливковое. Модель поплыла 😏.
3B на русском и вот вам лимонный пирог с грюйером! Но это уже совсем другая история!

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

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

О теории категорий обычно говорят как об одной из самых абстрактных областей математики. Довелось прочитать популярную книгу «Восторг абстрактной математики» Юджении Ченг (вслух тебе её прочитают на ютубе, можешь купить на озоне за 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-систем — примерно как когда-то теория типов в программировании (сорри, если сравнение кажется ничего себе), способ говорить о том, что из чего собрано и почему оно склеивается. Пока это скорее исследовательское направление, но мы же тут, чтоб держать руку на пульсе.

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