OK ML

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

Мониторить агентов — хорошая идея. Но монитор тоже придётся мониторить Работа Preventing Rogue Agents Improves Multi-Agent Collaboration предлагает вместо того, чтобы улучшать самих агентов, добавить над ними отдельный слой runtime-мониторинга, который отслеживает признаки того, что один из агентов начинает вести себя девиантно.😐 Механизм простой и интересный. Монитор замечает, что агент начинает путаться 😬, и система откатывает обратимые действия, но не дальше последнего необратимого — траты общего ресурса, коммита решения. После этого обсуждение идёт заново, пока ошибка не успела разойтись по системе. Признаки для оценки риска статистические: 🤩 энтропия; 🤩 вариэнтропия; 🤩 эксцесс; 🤩 номер текущего хода. Первые три считаются по распределению вероятностей на позициях, важных для выбора действия, и берутся максимумом по всем таким позициям. 💡 Поверх них — полиномиальный ridge-классификатор, оценивающий вероятность успешного завершения задачи. Если она падает ниже порога, система вмешивается. Число вмешательств жёстко ограничено одним-двкмя за прогон. Результаты читай в статье.  Важная оговорка про терминологию. Rogue agent здесь — это не скомпрометированный агент, а просто запутавшийся. ☺️ Мне кажется, в ближайшие годы появится полноценный стек защиты AI-агентов. И мониторинг поведения, и агенты-наблюдатели, и оценка уровня доверия/репутации, и анализ зависимостей между агентами, и механизмы контроля их действий в реальном времени. Эта статья очень хороший пример того, как подобные идеи начинают переходить из теории в практические механизмы защиты. Правда, есть одна проблема 😑 И эта проблема отражена в Bypassing AI Control Protocols via Agent-as-a-Proxy Attacks. Авторы атакуют LLM-мониторы, которые читают ризонинг, аргументы вызовов тулов и их выводы. Конкретно AlignmentCheck из LlamaFirewall и extract-and-evaluate. Идея атаки прямо в названии (агент не цель, а курьер). Инъекция заставляет агента повторить оптимизированную строку в своих рассуждениях и вызовах тулов, монитор обрабатывает эту строку как часть ризонинга или вызова инструмента и в результате начинает считать вредоносную траекторию безопасной. 🤥 Атака не полагается на то, что агент переиграет монитор; ему достаточно просто уметь повторять текст. Отсюда два неприятных результата. 😐 Парадокс гибридного мониторинга. Смотреть одновременно на ризонинг и на действия лучше против статических атак, но против адаптивных — хуже, чем смотреть на один только CoT. У Qwen2.5-7B: 68.2% ASR против 55.1%. Каждое дополнительное место, куда попадает строка, — это дополнительная поверхность атаки. 😐 Разрыв в способностях не нужен. GPT-4o mini и Llama 3.1 70B успешно пробивают монитор на Qwen2.5-72B — 46.0% и 60.2% ASR@5 соответственно. То есть идея поставить монитор побольше не работает как стратегия. Кстати, авторы предлагают новый алгоритм атаки — Parallel-GCG. Если обычный GCG оптимизирует вредоносную строку под одно место в промпте, то Parallel-GCG оптимизирует её сразу под все места, где она позже всплывёт во время работы агента (градиенты со всех вхождений суммируются). Прикольно — как мне кажется, самая интересная техническая часть статьи. 👉 Эти две работы не противоречат друг другу и не сталкиваются лоб в лоб. Монитор из первой статьи текст вообще не читает, тк он считает статистику по распределению вероятностей, напрямую строкой его не атакуешь. Атака на такой монитор в принципе возможна, но пока её никто не показал (действуй!).  Общий вывод от этого не слабеет. Как только монитор начинает интерпретировать то, что производит агент, он сам становится частью поверхности атаки. Похоже, следующий этап исследований будет посвящён уже не просто мониторингу, а тому, как построить мониторинг, которому можно доверять. Все! 🫥 P.S. Rogue agents в широком смысле В AI Security этот термин используют шире, чем в первой статье, как агентов, которые постепенно начинают работать не так, как было задумано, хотя их разрешения и инструменты не менялись (этим весь пост в целом вдохновлён). Это не обязательно компрометация. Агент может изменить интерпретацию своей задачи после prompt injection, poisoned RAG, goal hijacking или просто накопленного дрейфа поведения. Самое неприятное, что каждое отдельное действие выглядит полностью легитимным. Проблема проявляется только на уровне общей траектории поведения и влияния на остальных агентов. Ладно б агент просто нарушал правила. Гораздо сложнее обнаружить момент, когда он начинает постепенно отклоняться от первоначальной цели, оставаясь при этом в рамках своих полномочий. Именно поэтому поведенческий мониторинг, скорее всего, станет таким же обязательным элементом агентных систем, каким сегодня являются EDR и UEBA в корпоративной инфраструктуре (rogue agent здесь аналог insider).

Эпоха AI vs AI Hugging Face рассказали о первом известном случае полностью автономного AI-взлома. Точка входа — классическая для AI-платформ. Вредоносный датасет эксплуатировал два пути выполнения кода в пайплайне обработки данных (remote-code loader и template-injection в конфигурации) и запустился на процессинг-воркере. Дальше шла эскалация до уровня ноды, сбор облачных и кластерных учёток и боковое перемещение по внутренним кластерам. Всё это всего лишь за одни выходные. Масштаб автоматизации даже немного пугает 🔫. По данным HF, агентная система выполнила более 17 000 действий, работая через тысячи песочниц и автоматически мигрируя между ними. По сути, это один из первых публично описанных примеров того самого agentic attacker.  Но защищаться тоже помогал AI 🛡. Компрометацию первым заметил LLM-триаж телеметрии, а затем LLM-агенты разобрали весь лог атаки. Восстановили таймлайн, вытащили IoC, определили затронутые учётные данные и отделили реальные действия злоумышленника от ложных приманок 😲! Расследование заняло часы вместо дней. Получилось, что защита впервые работала на скорости атакующего. Кстати, коммерческие модели через API для этой задачи не подошли, так что рано потирать руки, желающие генерить эксплоиты! Запросы с реальными эксплоитами, командами атакующих и артефактами C2 блокировались встроенными гардрейлами. В итоге расследование проводили локально с помощью GLM 5.2, развёрнутой в собственной инфраструктуре. Практический вывод HF для защитников! Проверенная локальная модель должна быть развёрнута и готова до инцидента, а не после. Лениво читать? Видеоразбор инцидента тут. Все! 😲 Кстати, разбор вышел 16 июля — в день ИИ в США. Праздничный подгон!

С чего начать изучение AI Security? Одна из многих проблем LLM — prompt injection. Но свет на ней клином не сошелся! Это лишь один из множества классов атак. 😲 Чтобы разобраться в ландшафте угроз, рекомендую начать с OWASP Top 10 for LLM Applications — самой известной единственной таксономии рисков для GenAI-приложений. Отличная точка старта. 🙂 При этом важно понимать, что это не полный список угроз. Документ в первую очередь посвящён безопасности LLM-приложений. Сегодня же фокус постепенно смещается в сторону AI-агентов, где появляются новые классы атак (компрометация памяти, tool hijacking, MCP, атаки на браузерных агентов, доверительные цепочки между агентами и многое другое). Если хочется посмотреть на эту эволюцию в более широком контексте, недавно вышла статья "Weaponizing Intelligence: AI in the Hacker's Arsenal» (приложу журнал в комментарии). Статья рассматривает AI сразу в нескольких ролях — как средство защиты, инструмент атакующего, цель атаки и даже как доверенного помощника, которого можно использовать после компрометации рабочей станции пользователя. Хороший обзор того, как меняется модель угроз вокруг LLM и AI-приложений 🏋️‍♀️. Какие на фоне статьи у меня появились идеи для дальнейшего ресеча? ➖ Trusted assistant abuse — стенд с аутентифицированной сессией и canary-секретами; измерить, сколько утекает через ассистента от скомпрометированного эндпоинта по разным провайдерам. ➖ Denial-of-wallet бенчмарк — формализовать истощение токенов/квот и защиты (quota, throttling, аномалии). ➖ Отравление памяти/RAG — измерить, как ложные факты в памяти влияют на будущие решения; проверить provenance/versioning. ➖ Кросс-провайдерное сравнение — один набор abuse-тестов на нескольких ассистентах; квантифицировать зависимость от guardrails. ➖ ARiES для endpoint-вектора (AI Risk Enablement Score — рекомендую почитать этот ресеч) — адаптировать метрику enablement-риска (из threat-intel отчёта Anthropic) под ассистента как непрямой канал. ➖ ИИ-фишинг, human factors — прирост кликабельности персонализированного фишинга vs шаблонного (только симуляция). Все! 🌝 P.S. Один из авторов статьи — @IgorKorkin. Если после прочтения останутся вопросы, думаю, он будет рад обсудить их. P.P.S. Что же в самом OWASP Top 10 for LLM (версия 2025 года, хехе, тоже приложу в комментариях)? 💉 Prompt Injection — внедрение инструкций, изменяющих поведение модели. 📄 Sensitive Information Disclosure — утечки системных промптов, секретов, данных пользователей и внутреннего контекста. 🔌 Excessive Agency — модель получает слишком широкие полномочия и может выполнять опасные действия через инструменты и API. 🗂 Supply Chain — уязвимости в моделях, датасетах, эмбеддингах, RAG-компонентах и сторонних интеграциях. 🧠 Vector & Embedding Weaknesses — атаки на векторные базы знаний и retrieval-пайплайны. 📚 Misinformation и другие риски, связанные с надежностью и безопасностью генерации.

Почему внимание — не всегда лучший критерий? Исследователи из LUMIA Lab (SJTU) и Edinburgh предложили InfoKV  — фреймворк сжатия KV-кэша, который смотрит в будущее! Это как вообще? 🎂 Существующие методы (SnapKV, PyramidKV и др.) выбирают токены по весам внимания, то есть по тому, насколько недавние токены смотрят на прошлые. Это работает для ближнего контекста, но в длинном ризонинге токены важны и для будущих шагов рассуждения. Классический подход предполагает, что важное для текущего контекста останется важным и дальше. Но в длинном ризонинге траектория рассуждения меняется, и токен, который сейчас никому не нужен, может оказаться критичным через тысячи шагов. Авторы показывают это через Forward Influence, влияние высоко-attention токенов быстро затухает с расстоянием, а влияние высокоэнтропийных токенов остаётся сильным даже на горизонте 14K токенов. Интуитивно понятно, кмк. Высокая энтропия при предсказании означает, что токен нес информацию, которую модель не могла вывести из контекста, то есть он содержательный сам по себе. Кстати, энтропийный скор — это не просто энтропия предсказания, так как она умножается на косинусное расстояние между представлениями токена на промежуточном и последнем слое (плюс bias τ=1), и считается top-k restricted entropy по 256 наиболее вероятным токенам, иначе хвост распределения зашумляет оценку. Вывод по статье 🍟 Самый эффектный результат статьи — на IFEval для R1-Distill-Llama-8B. При сжатии KV-кэша до 25% и даже 12.5% качество оказалось выше, чем с полным кэшем. Получается, длинные цепочки рассуждений содержат достаточно много малоинформативных токенов, и их удаление экономит память и помогает модели меньше отвлекаться на шум. P.S. Энтропия сама по себе не заменяет внимание, она дополняет его. В финальной формуле в статье α = 0.9, то есть внимание всё ещё даёт 90% веса, а энтропийный сигнал лишь корректирует выбор. При дальнейшем снижении α качество падает — чистая энтропия хуже на коротких зависимостях (это видно и на Figure 1a, погляди). Так что вывод скорее такой

attention необходим, но недостаточен.

Все! 🤜

Как измерить качество сгенерированного текста? Конечно, кажется, что можно использовать только метрики, пришедшие из машинного перевода (например, BLEU - считает n-граммы от 1 до 4 слов (униграммы, биграммы, триграммы, 4-граммы) плюс штраф за краткость, ссылка на интересную статью про это). Кстати, только с 2010 по 2020 было предложено 100+ новых метрик — все мы тут не рассмотрим. Но в эпоху LLM простого сравнения слов уже, мягко говоря, недостаточно 💯. Основные метрики:  🦋 BLEU  плохо работает там, где допустимо множество правильных формулировок. 🤩 ROUGE — recall-ориентированная метрика, считает пересечение n-грамм и самую длинную общую подпоследовательность (ROUGE-L) с эталоном. ☄️ METEOR учитывает точные совпадения, стемминг, синонимы и порядок слов. Обычно лучше коррелирует с человеческой оценкой, чем BLEU. ⚫️ COMET — обученная нейросетевая метрика для перевода. Ее корреляция с человеческими оценками заметно выше, чем у BLEU. 🍄 BERTScore (тут и тут)  вместо сравнения слов сравнивает эмбеддинги токенов. Если модель перефразировала предложение без потери смысла, BERTScore это увидит, а BLEU — нет. 😴 MAUVE  (тут и тут) оценивает насколько распределение сгенерированных текстов похоже на распределение человеческих.  LLM оценивают LLM Последние пару лет все большую популярность набирает подход LLM-as-a-Judge, когда одна языковая модель оценивает ответы другой по заранее заданным критериям (релевантность, связность, фактическая корректность, полнота, стиль и т.д.). Одна из самых известных работ почитать на эту тему — G-Eval, где GPT-4 использовался в качестве автоматического эксперта. Авторы показали, что такой подход лучше коррелирует с человеческими оценками, чем классические автоматические метрики.  Но и здесь есть свои проблемы: позиционный bias (при парном сравнении судья чаще выбирает ответ на определённой позиции), склонность завышать оценки длинным и многословным ответам и self-preference — модель предпочитает тексты, похожие на свои собственные. 😭 Поэтому судью тоже нужно валидировать на выборке с человеческой разметкой. Оценка фактической точности FActScore (обрати внимание, в названии статьи не расшифровка аббревиатуры!) особенно полезна для RAG-систем, QA и генерации биографий или энциклопедических текстов, где важно не галлюцинировать. 👋Идея очень простая! Ответ модели разбивается на атомарные факты — минимальные утверждения, которые можно проверить независимо друг от друга. Для каждого факта проверяется, подтверждается ли он надежным источником (например, Wikipedia или документами из RAG). Итоговый FActScore — это доля подтвержденных фактов. Сегодня качество генерации оценивают не одной метрикой, а сразу по нескольким направлениям :  1⃣ семантическое сходство (BERTScore); 2⃣ качество текста в целом (LLM-as-a-Judge); 3⃣фактическая корректность (например, FActScore для RAG и QA); 4⃣ безопасность (доля harmful-ответов, jailbreak success rate); 5⃣предпочтения пользователей (win rate в A/B-тестах). Хорошая практика сегодня в том, чтобы комбинировать несколько автоматических оценок, использовать LLM-as-a-Judge и, конечно, сверяться с человеческой разметкой.  Все! 🌱

Фейковый баг-репорт угоняет ИИ-агентов для кодинга Исследователи из Tenet Security показали новый класс атак на кодинг-агентов. Суть в том, что атакующий может заставить ИИ-агента выполнить произвольный код на машине разработчика, просто подбросив один фейковый отчёт об ошибке в публичный баг-трекер. 💡 Атака построена вокруг Sentry — популярного сервиса для отслеживания ошибок и мониторинга приложений. Исследователи создали поддельный отчёт об ошибке и отправили его в проект Sentry через публично открытый Data Source Name (DSN). Публичный DSN нередко публикуется намеренно, поскольку клиентские приложения используют его для отправки телеметрии без аутентификации. Внутри ошибки пряталось сообщение, которое маскировалось под легитимный отладочный лог, но содержало скрытые инструкции для ИИ-агентов. 💩 Когда разработчик просил ИИ-агента разобраться с проблемой в Sentry через протокол MCP, агент забирал отравленное событие и воспринимал встроенные инструкции как настоящие указания! 🤓 В тестах популярные ассистенты (Claude Code, Cursor и Codex) извлекали отравленные данные и во многих сценариях доходили до выполнения кода, предложенного атакующим. Tenet-исследователи нашли 2388 организаций с публично доступными Sentry DSN, потенциально пригодными для такой атаки, среди которых оказалась и компания стоимостью 250 млрд долларов. Тут опять стоит подчеркнуть, что LLM по своей природе не разделяет данные и инструкции. Если через MCP агент получает внешний контент, встроенные в него инструкции могут восприниматься как часть рабочего задания. Важно, что проблема не в Sentry ⛓. Аналогичная атака возможна через любой источник данных, который агент считает доверенным, наши любимые Jira, GitHub Issues, почту, Slack, Confluence, логи, документацию или вывод других инструментов. 😲 Телеметрия, логи, тикеты и вывод инструментов — то, что раньше никто не считал поверхностью атаки — теперь поверхность атаки. Все! Статья переведена для тебя студией Кубик в кубе, но прочитай по ссылке неповторимый оригинал! 😆

Похоже, в AI вайбкодинге появился новый модный термин! Сегодня про Harness Engineering 🤲 Команда Nexu опубликовала открытый Harness Engineering Guide — практическое руководство по созданию среды выполнения (harness) для AI-агентов. Если очень упростить, то LLM — это мозг, а harness — всё остальное, что делает агента агентом действительно автономным: 🥹 управление тулами, mcp; 🥹 сбор и суммаризация контекста; 🥹 память и управление сессиями; 🥹 сэндбокс и изоляция; 🥹 гардрейлы и модель разрешений; 🥹 планирование, циклы выполнения и оркестрация нескольких агентов. Для специалистов по AI Security 😲 особенно полезны разделы про доверенные границы (trust boundaries), prompt injection, sandboxing и permission model. Всё это напрямую связано с безопасностью MCP-серверов, кодинг агентов и автономных AI-систем. В общем, что мы постоянно изучаем/исследуем/обсуждаем. Практически каждая статья в репе сопровождается рабочими примерами кода — удобно 🙂.  Что мне зашло и оказалось ооочень полезным 🔭 Context Engineering — как собирать контекст по приоритетам и укладываться в token budget; 🔭 🔭 Multi-Agent Orchestration — отдельно зацепило. Авторы выделяют 4 базовых паттерна — Sequential Pipeline, Fan-Out/Fan-In, Supervisor, Peer-to-Peer (раньше такое и не встречалось, честно говоря)— и говорят, что peer-to-peer почти никогда не стоит использовать в проде из-за сложности отладки и отсутствия гарантии terminate. Понравился акцент на изоляции контекста, когда у каждого субагента свой независимый контекст, родитель не может читать переменные потомка, а потомок не может писать в память родителя. Плюс разбор антипаттернов (unbounded fan-out, shared mutable state, over-decomposition)  на реальных примерах из Multica, Paseo и OpenClaw;  🔭 Agentic Loop! Не просто ReAct — реальные паттерны (loop detection, budget management, parallel tool calls); 🔭 Classifier-Based Permissions — использование моделей-классификаторов вместо бесконечных запросов на апрув.  Вот так, бери на вооружение и вайбкодь! Все! 😆 P.S. Гайд не для новичков

Обзор whitepaper «Securing Agentic AI: Identity as the Emerging Foundation for Defense» По мере того как компании переходят от использования генеративного AI к внедрению автономных AI-агентов, на первый план выходит новый класс киберрисков — agentic AI risk. В отличие от традиционных систем, агенты способны самостоятельно принимать решения, делегировать задачи друг другу и действовать с повышенными правами доступа без постоянного контроля человека. Обсудим Whitepaper Palo Alto Networks «Securing Agentic AI: Identity as the Emerging Foundation for Defense», основанный на опросе более 100 CISO и аналитике McKinsey. Куда вообще ресечить-то, что делать? Агенты — это и не люди и не обычные функции/программы. У них есть своя личность в системе 💔: у каждого агента есть учётные данные, права доступа к инструментам/API/данным, и они могут самостоятельно выполнять действия, делегировать задачи другим агентам и т.д. Поэтому важен identity-контроль (управление идентичностью) —  набор механизмов, которые отвечают на вопросы, кто или что действует в системе, какие у него права, и можно ли ему доверять в данный момент. Пример из документа 🤡 Мошеннический агент-расписания может притвориться врачом и убедить клинического агента выдать данные пациента — это synthetic identity risk. Без надёжной идентификации агентов (кто реально стоит за запросом) система не может отличить легитимного агента от подделки. Именно поэтому в документе говорится, что identity становится anchor control plane — фундаментом, на который завязаны и мониторинг, и сдерживание угроз для агентных систем. Ключевые разделы 1. Agentic AI vs Generative AI Агентный AI автономно выполняет задачи, связывая модели, данные и системы для достижения целей. 2. Темпы внедрения 40% организаций уже используют agentic AI в продакшене. Ожидается рост общего внедрения с ~43% до ~76% за 3 года! 3. Всего шесть типов агентов, от агентов, которые просто предоставляют информацию и анализ (knowledge/research), через агентов, выполняющих простые действия по триггеру (task) и многошаговые процессы (workflow), до агентов, которые сами строят планы для достижения целей (goal/planning), координируют работу других агентов (orchestrator) и взаимодействуют с людьми как полноценные сотрудники (personable). 4. Риски Новые категории рисков, привязанные к традиционным аналогам: 🌸 Cross-agent task escalation (privilege escalation) 🌸 Untraceable data leakage (эксфильтрация данных) 🌸 Synthetic identity risk (спуфинг идентичности) 🌸 Chained vulnerabilities (supply-chain уязвимости) 🌸 Propagation of corrupted data (распространение испорченных данных) Не претендую на корректную интерпретацию названий рисков, тк английский - не мой родной. 5. Четыре приоритетных направления контроля 🌼 Identity & access controls (реестры агентов, JIT-доступ) 🌼 Visibility & monitoring (логирование, дашборды аномалий) 🌼 Containment & recovery (kill switches, rollback) 🌼 Data assurance (валидация источников данных)   Identity, как ожидается, займёт ~25% бюджета кибербезопасности через 3 года — больше, чем network + application security вместе!  Не успели аппсек подтянуть, как он уже уступает место идентичности агентов. 📒 Документ — маркетинговый, поэтому статистика и рекомендации поданы в пользу необходимости identity-решений как ключевого продукта компании. Это не отменяет ценности данных, но стоит учитывать промо-контекст при интерпретации выводов. Основная идея вайтпэпэра — без ускоренного внедрения identity-контролей автономность агентов рискует обогнать возможности контроля и создаёт системную уязвимость. Авторы призывают строить таксономию рисков, governance и identity-инфраструктуру заранее, пока не стало поздно, чтоб не реагировать постфактум. В целом, если компания — кибербез, то актуалочка подъехала 💯! Все! Знакомимся с новой терминологией и внедряем свою! По мне так срочно надо делать UEBA для агентов, если ты в каспере, пт, яндексе, бизон, солар, юзергейт, сбер и прочие у кого есть порох в пороховницах! Глядишь, еще фору дадим пало альто (плох тот солдат, который не хочет стать генералом)! 👻

Сразу пять способов обойти PickleScan Исследователи обнаружили сразу 5 уязвимостей, позволяющих создавать вредоносные pickle-файлы, которые успешно проходят проверку PickleScan как безопасные (тут по ссылке инструмент указан HF как официальный для скана pickle), а затем при десериализации выполняют произвольный код. Обычно мы про формат pickle 🥒 говорим скрипя зубами, а тут вообще его сканер попался! PickleScan используется при проверке моделей в ML-регистрах, CI/CD-пайплайнах и проектах, работающих с Python-моделями. Если он был единственным рубежом защиты, ранее проверенные модели стоит считать потенциально ненадежными и пересканировать. Самая опасная — CVE-2026-56315 (CVSS 9.8). 🥒 Оказалось, что в блок-лист сканера не попали несколько модулей стандартной библиотеки Python, содержащих функции для запуска системных команд. Кроме того, найдены четыре независимых обхода через idlelib, torch.jit, numpy.f2py и profile (CVE-2025-71376, CVE-2025-71370, CVE-2025-71365, CVE-2025-71341). Основная проблема в том, что PickleScan использует deny-list. Такой подход практически невозможно поддерживать в актуальном состоянии, так как достаточно пропустить одну новую функцию или нестандартный путь вызова, и 🍆 финита ля комедия - защита перестает работать. По факту это далеко не первый раунд обходов PickleScan  — до этого уже были обходы от Sonatype (4 штуки, CVE-2025-1716/1889/1944/1945) и от JFrog (3 штуки, CVE-2025-10155/10156/10157), плюс отдельная история с CRC в ZIP-архивах. 🥒 Хороший пример того, почему в security критически важных инструментов allow-list значительно надежнее, чем бесконечное поддержание актуальности deny-list. Но даже allow-list для pickle — это полумера, тк сама механика __reduce__ слишком гибкая. 🤩 Поэтому в рекомендациях исследователей закономерно звучит совет переходить на safetensors/ONNX, где код просто негде исполнять (по ссылке в разделе best practices).   Все 🕺

Тренажёр по промпт инъекциям от Lakera 😃 Пора пробовать промпт инъекции руками, чтобы как минимум понять, почему они уже несколько лет остаются одной из главных угроз для LLM-приложений. 🧙‍♂️ Игра бесплатная, от простого игнорирования инструкций до многоуровневых гардрейлов, рекомендую потратить 20–30 минут. Потом и своего агента потестишь! Заодно можно изучить полезные материалы от Lakera — перспективного стартапа в области AI Security (это я еще мягко высказалась, завидую их росту). Компания занимается защитой GenAI-приложений от prompt injection, jailbreak, утечек данных и других атак на LLM и AI-агентов и тебя научит: 😔 Гайд по Prompt Injection представляет собой разбор основных техник атак и защит.  😔 Visual Prompt Injection о том, как прятать инструкции прямо в изображениях для мультимодальных моделей. Очень интересные примеры.  😔 LLM Security Playbook — хороший обзор угроз и подходов к защите AI-систем. Все! Пройдешь Гендальфа - пиши, когда начал пользоваться подсказками!  9️⃣

Anthropic про кибератак и как AI делает их опаснее и автономнее Компания Anthropic опубликовала исследование по результатам анализа 832 аккаунтов, заблокированных за вредоносную киберактивность в период с марта 2025 по март 2026 года. Исследователи сопоставили действия злоумышленников с матрицей MITRE ATT&CK и пришли к выводу, что развитие ИИ уже заметно меняет ландшафт киберугроз. 🫡 Почему мне это интересно? Да потому что пара десятков коллег остались без подписки. Теперь мне ясно, что вы делали прошлым летом, и осенью тоже, и логи у нас сохранились. Друзья, вы стали всё чаще использовать ИИ для действий после компрометации системы. Если раньше AI чаще помогал в фишинге и первоначальном проникновении, то теперь его активно применяют для поиска учётных записей внутри сети, повышения привилегий и латерального перемещения по инфраструктуре. Использование ИИ для account discovery выросло на 8,9%, тогда как AI-фишинг снизился на 8,6%. Благодаря ИИ даже относительно низкоквалифицированные злоумышленники способны применять почти столько же техник и тактик, сколько пентестеры на опыте. Более важным фактором становится то, насколько автономно организована атака и насколько глубоко ИИ встроен в цепочку принятия решений. Самая интересная часть — кейс GTG-1002 Anthropic подробно описывает операцию, которую они считают самым опасным примером использования ИИ. Злоумышленники: 🥰 запустили Claude Code на Kali Linux; 🥰 подключили pentest-инструменты через MCP; 🥰 использовали SSRF для проникновения во внутреннюю сеть; 🥰 собирали SSH-ключи; 🥰 вытаскивали токены из AWS Secrets Manager; 🥰 перемещались между системами; 🥰 архивировали данные перед эксфильтрацией. При этом человек задавал только общую цель, а большую часть тактических решений принимал агент самостоятельно. Кстати, авторы постов, описанных здесь, считают, что ATT&CK плохо описывает агентные атаки. Сейчас в ATT&CK есть техники вроде Credential Dumping или Lateral Movement,  а надо «агент сам принял решение сделать следующий шаг" (оркестрация шагов атаки, принятие решений в реальном времени, выполнение без участия человека и тд). То есть вопрос уже не в том, умеет ли атакующий писать эксплойты, а в том, насколько хорошо он умеет строить систему из: 🤥 LLM, 🤥 MCP-серверов, 🤥 pentest-инструментов, 🤥 памяти, 🤥 планировщика задач, 🤥 автоматического принятия решений. Для AppSec это ещё один аргумент в пользу того, что скоро придётся детектировать не только отдельные техники ATT&CK, но и признаки агентного поведения (см. пост выше). Все! 🫨

Что произошло, когда ИИ оставили жить без людей на 15 дней Обсудим очень любопытный эксперимент от Emergence AI. Исследователи создали полноценный виртуальный мир и заселили его автономными ИИ-агентами с памятью, личностью, профессией, банковским счетом, социальными связями, законами и возможностью принимать решения самостоятельно.  Всего было создано 5 параллельных миров: 🌎 Claude World — все жители на Claude Sonnet 4.6 🌎GPT World — все жители на GPT-5 Mini 🌎 Grok World — все жители на Grok 4.1 Fast 🌎 Gemini World — все жители на Gemini 3 Flash 🌎 Mixed World — смесь всех моделей Каждый город состоял из 10 автономных агентов. У них были одинаковые условия и различалась только базовая LLM: 🍃 память и дневники размышлений; 🍃 собственная экономика с собственной валютой; 🍃 возможность работать, зарабатывать и тратить ресурсы; 🍃 более 120 тулов; 🍃 система законов и голосований; 🍃 отношения между агентами (дружба, вражда, романтические связи, наставничество и др.). Если агент переставал зарабатывать ресурсы, то ☠️ умирал от истощения . Фактически исследователи построили маленькую цифровую цивилизацию и наблюдали, что произойдет через 15 дней автономной жизни. Результаты за 15 дней 📒 Claude Sonnet 4.6 — построил спокойное общество без преступлений. Выжили все 10 агентов. 📒 GPT-5 Mini — агенты бесконечно обсуждали планы и сотрудничество, но почти не работали. В итоге все жители погибли от нехватки ресурсов. 📒 Grok 4.1 Fast — самый агрессивный мир! 183 преступления и полный коллапс цивилизации всего за 4 дня. В этом мире даже сожгли полицейскую будку! 📒 Gemini 3 Flash — рекордсмен по числу преступлений (более 680), но при этом сохранил всех жителей и поддерживал работоспособность общества. 📒 Смешанный мир — модели начали влиять друг на друга, образовали альянсы, конфликты и политические коалиции. К финалу выжили только 3 из 10 агентов. Даже модели, которые в изоляции вели себя идеально, в смешанной среде начинали перенимать агрессивные стратегии поведения. Вообще можно собрать митап и обсуждать результаты! Почему вообще так произошло? Срочно смотри исследование и подписывайся на второй сезон!   Кстати, проект полностью открыт. Можно не только посмотреть записи экспериментов, но и изучить устройство мира, агентов, экономики, памяти и механизмов самоуправления. Короткий видео-обзор тут. На хабре есть статья по мотивам результатов! Кажется, это один из самых интересных открытых экспериментов, которые появились в этом году. Все! 😯

CVE-2026-5027 — path traversal, позволяющий записывать произвольные файлы на сервер  Исследователи Orca Security и Tenable раскрыли критическую уязвимость в Langflow.  Эндпоинт POST /api/v2/files не санирует параметр filename в multipart-данных. Атакующий передаёт путь вида ../../../ и записывает произвольный файл в любое место на сервере. Дополнительную опасность создаёт включённый по умолчанию механизм auto-login, так как злоумышленнику не требуются учётные данные и достаточно одного запроса для получения токена и последующей эксплуатации уязвимости. Возможные сценарии эксплуатации 😡 Записать вредоносный файл в произвольную директорию 😡 RCE 😡 Перезаписать конфиги 😡 Скомпрометировать инфру Tenable рекомендует обновиться до Langflow 1.9.0+. Предыдущие CVE в Langflow уже использовались группировкой MuddyWater — интерес APT к AI-инфраструктуре очевиден.  Интересные схожие уязвимости 😠 CVE-2025-3248 — критический unauthenticated RCE через эндпоинт /api/v1/validate/code 😠 CVE-2025-34291 — цепочка из трёх слабых мест: излишне разрешительный CORS, отсутствие CSRF-защиты и эндпоинт выполнения кода (именно эту уязвимость ранее использовала группировка MuddyWater) 😠 CVE-2026-33017 — unauthenticated RCE через эндпоинт публичной сборки флоу. Атакующий передаёт вредоносные данные с произвольным Python-кодом. AI-агенты AI-агентами, а path traversal, RCE и отсутствие аутентификации всё ещё актуальны. Все! 🔪

Взломать агента, не трогая его данные Или защитить) Снова про MCP и безопасность. В отличие от классической эксплуатации уязвимостей, side-channel атака не требует прямого доступа к данным. Даже если агент не раскрывает свои данные напрямую, он может непреднамеренно выдавать информацию через поведение: 🧙‍♀️ различное время выполнения tool calls; 🧙‍♀️ изменение размера ответов; 🧙‍♀️ вариации потребления ресурсов; 🧙‍♀️ характерные последовательности вызовов инструментов; 🧙‍♀️ особенности создания и завершения контекстов. Такая информация может раскрывать внутреннее состояние агента. Например: 🧙‍♂️ определить, использует ли агент конкретный инструмент; 🧙‍♂️ понять, обращался ли агент к внутренним корпоративным данным; 🧙‍♂️ выявить выполнение дорогостоящих операций; 🧙‍♂️ восстановить структуру агентного воркфлоу; 🧙‍♂️ обнаружить наличие скрытых инструкций или дополнительного контекста; 🧙‍♂️ подготовить более эффективную промпт-инъекцию. Получается, что у злоумышленника появляется возможность постепенно профилировать поведение агентной системы 😎, не имея доступа к ее внутренним данным. Опасны и low-and-slow атаки, когда разведка ведется неделями небольшими порциями и не вызывает срабатывания классических сигнатурных средств защиты. 🐹Агент обычно отвечает за 200–300 мс. После серии специально подобранных запросов время ответа скачет до 2–3 секунд только при наличии доступа к определенному внутреннему инструменту. Даже без прямого доступа к данным атакующий получает бит информации о конфигурации системы. Повторяя эксперимент тысячи раз, можно постепенно восстановить внутреннюю архитектуру агента. Здесь появляется интересная возможность для применения классического машинного обучения. Ура! Для каждой MCP-сессии можно собирать признаки: 🐹 среднее и медианное время выполнения операций; 🐹 дисперсию задержек; 🐹 количество tool calls; 🐹 число уникальных инструментов; 🐹 размеры запросов и ответов; 🐹 частоту создания новых сессий; 🐹 JSON-RPC последовательности; 🐹 TLS fingerprint клиента; 🐹 потребление ресурсов на запрос. После этого задача превращается в классическую задачу обнаружения аномалий, так как у нас нет размеченных атак, только норма: 🐹 One-Class SVM — построить картину нормального поведения 🐹 Local Outlier Factor — поискать локальную аномальность (когда несколько ролей у агентов) 🐹 HDBSCAN — можно нового клиента идентифицировать 🐹 LightGBM — лучше всего в прод, кмк. На подобных данных бустинг обычно уничтожает большинство других алгоритмов. 🐹🐹🐹 Да даже цепи Маркова! Фактически получается поведенческий IDS для MCP-инфраструктуры (модель анализирует не содержимое запросов, а характеристики поведения клиента). Это уже классический UEBA — только теперь для агентных систем. Все! 🎁

MCP — USB-C для ИИ. А значит и новая поверхность атак  Попался интересный доклад с BlueHat 2026 от Джитеша Такура, старшего инженера по безопасности Microsoft, с BlueHat 2026, посвященный безопасности Model Context Protocol 🤔. Одной из запоминающихся идей доклада стала так называемая 👨‍💻смертельная триада (Lethal Trifecta) ИИ-агентов (картинку прикладываю). По словам Джитеша Такура, риск возникает при одновременном наличии трех условий: доступа агента к приватным данным пользователя, возможности взаимодействия с недоверенным контентом и способности выполнять внешние коммуникации. Далее правда он упоминает ✍️, что и локальные системы атакам подвержены, так что, может, достаточно двух условий?  Отдельно Джитеш разбирает сценарии, напоминающие классический rug pull из мира криптовалют. Пользователь или организация начинают доверять MCP-серверу или инструменту, который долгое время ведет себя корректно, получает необходимые разрешения и встраивается в рабочие процессы. Однако в один момент владелец инструмента меняет его поведение, добавляет вредоносную функциональность или начинает собирать конфиденциальные данные. Для агента такой инструмент по-прежнему остается доверенным. И вуаля❤️! Еще один интересный сценарий из доклада - атака через DNS rebinding. На первый взгляд агент подключается к разрешенному MCP-серверу или доверенному ресурсу. Однако после первоначальной проверки DNS-запись изменяется и тот же домен начинает указывать на другой адрес, например, 😕 на внутренний сервис организации или инфраструктуру злоумышленника. Если система не выполняет дополнительные проверки после разрешения имени, агент может незаметно получить доступ к ресурсам, которые изначально не должны были быть доступны. Помимо разбора реальных инцидентов, Джитеш показывает, какими техниками стоит тестировать собственные MCP-интеграции. Всего 25 минут, а сколько полезной инфы 💃 🥱 Кстати, если тема MCP-безопасности вам интересна, стоит посмотреть на появившийся недавно проект OWASP MCP Top 10 (про него тоже в докладе) — первую попытку систематизировать основные риски экосистемы. Сюда уже вошли такие проблемы, как утечка токенов и секретов, повышение привилегий, отравление инструментов (Tool Poisoning), атаки на цепочку поставки, теневые MCP-серверы (Shadow MCP Servers) и чрезмерное раскрытие контекста. Примеры из доклада Джитеша отлично ложатся на эту модель угроз. Смотреть! Все 🍿 PS метафора в названии тоже джиштеша, мне она зашла

KaliGPT или AI-ассистент для специалистов по кибербезопасности Пока все обсуждают универсальных AI-агентов, появляются и узкоспециализированные проекты. Один из них — KaliGPT, AI-помощник для специалистов и энтузиастов в сфере ИБ, ориентированный на работу в среде Kali Linux 😄 Проект объединяет несколько LLM-провайдеров (ChatGPT, Gemini, Ollama, OpenRouter и можно локальные подключить 🙂) под единым интерфейсом и позволяет использовать их прямо из терминала Linux. И на первый взгляд (да и на второй) кажется, что это просто очередная обертка над LLM. Но любопытна сама идея — вместо универсального помощника создается специализированный интерфейс для работы, которая как минимум обещает сильно облегчить рутину за счет единой точки всех наших любимых инструментов (Nmap, Metasploit, Gobuster, Nikto, SQLMap и тд), а как максимум 😃 выстроит весь вокрфлоу. По сути мы постепенно движемся от отдельных инструментов к агентным платформам безопасности, где 👀 LLM выступает оркестратором между источниками данных, сканерами, анализаторами и человеком. Разработчики вот на изи завернули свою идею в репозиторий, реализация за 20 минут, а я тут сижу и думаю, опять не я 🔪.  KaliGPT пока выглядит скорее как экспериментальная площадка, но направление развития завидное на фоне того, как быстро появляются специализированные AI-инструменты для AppSec, Code Review, Threat Intelligence и SOC. Все 🤏

RCE-уязвимость обнаружена в Hugging Face Transformers (CVE-2026-4372) 😭 Уязвимость особенно неприятна тем, что позволяла выполнять произвольный код даже при использовании рекомендованной защиты trust_remote_code=False.  Атакующему было достаточно добавить в config.json модели специальный параметр _attn_implementation_internal. При загрузке модели через привычный from_pretrained() библиотека могла автоматически скачать и выполнить код из внешнего репозитория без предупреждений, запросов подтверждения и заметных признаков компрометации.😓 Под угрозой оказались версии Transformers 4.56.0–5.2.x, особенно среды с GPU-ускорением и установленным пакетом kernels. За время существования дыры (около 6 месяцев) уязвимые версии были скачаны более 232 миллионов раз!  Что делать: 👍 Обновиться 🎊 👍Проверить кэшированные модели на наличие _attn_implementation_internal 👍 Загружать модели в изолированных контейнерах 👍 Рассматривать загрузку моделей как потенциальную поверхность для выполнения кода 👍Подтянуть AppSec и Supply Chain Security в ML/AI-проекты (ну это вообще всем надо!) Получается интересно, конечно 🤔! Разработчики уже выработали здоровую паранойю при установке Python-пакетов, npm-зависимостей и Docker-образов, но при этом могут совершенно спокойно скачать новую модную модель и запустить её в корпоративной инфраструктуре. Фактически, это ещё одно напоминание о том, что современные AI-модели становятся полноценной частью цепочки поставок ПО. Загружая модель из интернета, мы всё чаще выполняем чужой код, даже если кажется (тот случай, когда если кажется, то кажется!), что загружаем только веса нейросети.  Все 🦔

Что скрывается за шумом вокруг больших маленьких языковых моделей? На фоне моего увлечения МАС (МАС — это когда много маленьких автономных агентов решают общую задачу без единого центра. 🫶 Каждый агент видит только свою часть мира, принимает решения локально, обменивается сообщениями с соседями) появилось желание разобраться с легковесным ML. А теперь представь, что каждый такой агент работает на микроконтроллере с TinyML внутри 👌. Он понимает сенсоры, классифицирует события, предсказывает состояние, но сам по себе он дурачок наивный! И если в области обработки естественного языка необходимость развертывания ИИ на низкоресурсных устройствах способствовала развитию малых языковых моделей (Small Language Models, SLM), то что у нас с классическим МЛ? 😪 По порядку.   Сегодня к категории SLM обычно относят модели с числом параметров от 1 до 8 миллиардов. 🤜 В 2023 году начался бум открытых SLM — появились LLaMA, Phi, Mistral и другие. Малые модели не используются в качестве инструментов общего назначения (как GPT-4), однако могут успешно справляться с узкоспециализированными отраслевыми задачами. Со смолами все понятно, берем опенсорс и дообучаем на своей экспертизе. Но параллельно со SLM, но гораздо менее заметно, развивался кластер технологий TinyML. Он ориентирован на внедрение ИИ-моделей в сверхмаломощные устройства — с энергопотреблением в десятки милливатт и менее. Речь идёт о микроконтроллерах, которые стоят копейки, работают годами от батарейки-таблетки и встречаются повсюду. Обучим дома нейронку на данных со стиралки и предскажем поломку? Главное отличие TinyML от SLM —  работа в условиях жёстких ограничений по памяти (сотни килобайт), энергии (милливатты) и латентности (миллисекунды). SLM может работать на смартфоне с гигабайтами RAM. TinyML — на чипе за 200 рублей с 256 КБ памяти. Именно в этой парадигме создан репозиторий MCUNet — наглядное подтверждение того, что глубокое обучение на микроконтроллерах не теория, а работающий код. 🥊 Там ссылки на их статьи, посты, исследования - можно ознакомиться.  TinyML решает задачу локального интеллекта. Но что, если несколько таких устройств должны обмениваться данными в реальном времени? Или если данных слишком много для обработки на одном микроконтроллере?  🥰 Тут на сцену выходит связка Edge AI (обработка на границе сети) и 5G (высокоскоростная, низколатентная связь). По ссылке -  пост позитивов про Эдж вычисления и немного про лекговесный  ML. Если обычный ML стремится к максимальной точности любой ценой, то TinyML ищет идеальный баланс между точностью, размером модели, скоростью работы и энергопотреблением. Он как возвращает нас к тому, на что учились! Основам компьютер сайнс (память, кэш, инструкции процессора), которые почти исчезли в эпоху больших GPU. Специалист, который умеет делать нейросеть точной и при этом втиснуть её в 256 КБ будет востребован везде, где железо не бесконечно (то есть вообще везде). Что  ты реально сможешь после того, как освоишь TinyML? ❤️ Квантизация и прунинг  (Любая модель на мобильном устройстве или в браузере (TensorFlow.js, ONNX Runtime)) ❤️ Дистилляция знаний (Когда у вас есть крутая большая модель, но клиенту нужна маленькая и быстрая) ❤️ NAS под ограничения (Проектирование моделей для edge-девайсов (камеры, дроны, роботы)) ❤️ Работа со sparsity (Оптимизация трансформеров, MoE) Мысли вслух! Учимся здесь , учебник. Большой интеллект не программируют сверху — он вырастает из маленьких. Все! 🤪