4 секрета Roboduck. Как Theori взяли AIxCC и бустанули хакеров х10 🚀🚀🚀

Что ты представляешь, когда слышишь о системе, которая способна обнаруживать уязвимости, создавать эксплоиты, а также сразу выпускать патчи, устраняющие дыры прошлого? Theori, команда участвовавшая в соревновании AI Cyber Challenge попыталась решить эту сложную задачу, представив автономную CRS(Cyber Reasoning System) - RoboDuck. В этой системе используются агенты, но не как аддон, а как основа.

Почему система оказалась эффективной и почему получилось дополнить основу революции агентов в кибербезе?

🧩Секрет № 1. Разбивайте задачу на части, как пазл.

Главная идея - не тащить все одним супер-агентом. Делим на подзадачи и даем разным агентам. Представьте лабиринт: чем он больше, тем больше тупиков, логично? А теперь, что вместо одного огромного лабиринта у вас есть серия маленьких? Шансы найти выход резко возрастают!

Для генерации Proof of Vulnerability(PoV) команда выделила три подзадачи:

1. Анализ fuzz-harness и написание кода для преобразования семантики в бинарщину.
2. Ответы на точечные вопросы по коду.
3. Отладка готового PoV, чтобы понять почему эксплоит не срабатывает.

Каждую подзадачу вёл отдельный агент, а главный агент собирал результат в цельную картину.

⚒️Секрет №2. «Не все инструменты сразу - только нужные»

В ходе разработки решения команда обнаружила, что если агенту дозволено делать абсолютно всё, начинается хаос:

1. Агент может запустить прожорливую команду, которая съест все ресурсы (грепанём по всему коду в Линуксе 🙃)
2. Контекст засоряется - фокус теряется.
3. Простые задачи вдруг начинают требовать множества шагов 🤢..

Что сделали Theori ??? Они создали узкоспециализированные тулы: для поиска строки, для чтения фрагмента кода и для извлечения отдельных символов из кода. Плюс сами инструменты имели guardrails, которые могли сужать промпт в случае получения большого количества результатов.🤔

⛓️Секрет №3. Структурированный вывод от эксперта.

Как получить из агента не «простынь», а структурированный вывод/результат. Theori делится с нами двумя способами:

- Сперва дайте агенту схему вывода в XML и прямо попросите, чтобы он оформлял ответ в XML тегах. Модели хорошо их понимают.

- Далее создайте отдельный тул, который будет завершать работу агента, - своеобразная кнопка "Готово" с полями для заполнения😕. Когда параметры вызова совпадают с финальным результатом — агент аккуратно завершает работу без болтовни.

🎚️Секрет №последний, 4: Подстраивайтесь под особенности моделей 😮

Игнорирование факта что все LLM разные = неудача = ловить одни и те же фейлы. Команда обнаружила, что если агент делает одну и ту же ошибку, то лучше добавить в промпт запрещалку. Claude отлично следует этим запрещалкам 😎 - он любит когда ему что-то запрещают. Если агент застревает, то надо попросить его «подумать иначе» и сменить стратегию.

В соревновании это выстрелило, когда агент PoVProducer не смог создать пригодный эксплоит, но правила смогли дать нужный результат.

Как пишут в Theori: "Хотя ИИ ещё не заменит хакера, он уже делает его в 10 раз эффективнее".

🧨А с этими секретами го разрабатывать агентов для своих задач!😺

🧩 Принципы и паттерны безопасной разработки: SRP

Хоть это и не вполне очевидно, но разработка безопасных приложений может (а, возможно, и должна) начинаться, отнюдь не с моделирования угроз, внедрения в код механизмов защиты, ревью безопасности, пентестов, внедрения SCA/SAST/DAST, или, тем более, чего-то, вроде хантовского «Hack Yourself First» ✝️ В лучших традициях Shift Left Security, начинать стоит с базовых принципов разработки, таких, как SOLID, YAGNI, DRY, KISS, чистый код с архитектурой и т.п. Именно они позволяют заложить в архитектуру и реализацию приложения правильный фундамент, на котором будет гораздо проще и дешевле реализовывать прочие решения и этапы внедрения DevSecOps.

Начнём с принципа единственной ответственности (Single Responsibility Principle, SRP — первая буква в SOLID), утверждающему, что каждый класс или модуль должен иметь единственную ответственность (только одну причину для изменения). С точки зрения безопасности SRP способствует изолированности компонентов и чётким границам доверия в коде, что существенно облегчает последующую работу с моделью угроз. Когда компонент сконцентрирован на одной задаче, его легче проверять на уязвимости и логические ошибки. Это снижает риск скрытых багов, возникающих при смешении разных обязанностей (например, проверка прав доступа вперемешку с бизнес-логикой). Как отмечают эксперты, соблюдение SRP «ограничивает случайную эскалацию привилегий и упрощает поиск ошибок», а также уменьшает общую поверхность атаки за счёт уменьшения сложности компонентов.

Тривиальный пример: допустим, класс UserAuth одновременно проверяет пароль пользователя и создаёт сессию при входе.

Нарушение SRP может выглядеть так:

class UserAuth {
    public Session Authenticate(string username, string password) {
        // Фрагмент, работающий с новыми пользователями
        if (!PasswordChecker.IsStrong(password)) {
            throw new Exception("Weak password");
        }

        var user = userRepository.CreateUser(username, password);
        return sessionManager.StartSession(user);
    }
}

В этом коде смешаны проверки безопасности (надежность пароля) и бизнес-логика сессии. Если разработчик решит изменить логику создания сессии, есть риск ненароком ослабить или обойти шаг проверки пароля. Правильнее разделить эти обязанности на отдельные классы (например, PasswordChecker, UserRepository, SessionManager), а UserAuth сделать оркестратором. Тогда код станет понятнее и безопаснее: каждая часть легко проверяется и тестируется отдельно.

Забавно, что «живым» примером последствий нарушения SRP является одна из наиболее нашумевших уязвимостей в библиотеке логирования Apache Log4j 2 CVE-2021-44228, известная как Log4Shell. Логирование — это задача записи сообщений, но Log4j помимо этого выполнял ещё и роль интерпретатора/поисковика ресурсов (JNDILookup). Фактически, в библиотеку логирования «просочилась» функциональность, выходящая за рамки её единственной ответственности — она не только записывала логи, но и могла выполнять сетевые запросы и загружать код. Если бы Log4j ограничился исключительно записью логов, без вычисления каких-либо lookup-выражений, уязвимость бы не возникла. И действительно, исправление проблемы заключалось в отключении/удалении функции JNDI Lookup из Log4j.

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

В целом, SRP укрепляет принцип «secure by design»: мелкие простые модули легче защитить и проверить.

Абстрактная интерпретация и символьное выполнение: в чем разница?

В любой непонятной ситуации, когда станет совсем скучно — заводи спор о терминологии...

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

При символьном выполнении код интерпретируется, или выполняется, в соответствии с подмножеством семантики целевого языка, заменой всех неизвестных значений (входных данных) символьными переменными и вычислением формул в модели памяти, вместо конкретных значений. Подмножеством — потому что, невычислимые и сложно-вычислимые конструкции (вроде циклов и рекурсии, инварианты которых включают символьные переменные) упрощаются различными способами, про которые в академическом мире пишут целые диссертации. В реальном же мире SAST, как правило, просто ограничиваются «прокруткой» таких конструкций фиксированное количество раз или охапкой эвристик.

Основной челлендж разработчиков SAST, работающих в парадигме символьного выполнения: приемлемая аппроксимация семантики языка и эффективное решение проблемы экспоненциального роста путей выполнения или множества значений. Короче, долго, «дорого» (в плане сложности реализации), но относительно точно.

Абстрактная интерпретация же — это размен точности на скорость, при примерно той же «стоимости». Вместо неизвестных значений берутся их приближения: «переменная x в [0..10]», или «переменная y чётная», или (в продвинутых техниках) «переменная s определяется конечным автоматом [a-zA-Z]+». Это формирует т.н. домен интерпретации. И далее осуществляется интерпретация кода в соответствии с определенным доменом. Анализ завершается в куда более приемлемое время, и охватывает все пути, но ценой роста процента ложных срабатываний.

Проще пояснить на примере вычисления цикла:

def g(x):
    while x < 100:
        x = x + 2
    return x

Символьное выполнение (один из подходов):

– принимает число итераций за неизвестную переменную k;

– выводит через интерпретацию уравнение x0 + 2k = 100 и ищет его решения;

– находит, например, x0 = 0, k = 50;

– крутит цикл k раз.

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

Абстрактная интерпретация (интервальный домен):

– начнём с x ∈ [0..50];

– каждую итерацию добавляем 2: [0..52] → [0..54] → …;

– рост бесконечный, поэтому применяем widening («перепрыгиваем» через растущие приближения, чтобы гарантировать быстрое достижение фиксированной точки, пусть и грубым образом) и прыгаем к границе [0..+∞);

– потом применяем narrowing (уточняем полученное приближение, чтобы вернуть часть точности, которую потеряли на шаге widening) и условие выхода из цикла уточняют результат до [100..+∞).

Интервалы говорят: «на выходе точно x ≥ 100», но теряют информацию о чётности.

Если взять домен «чёт/нечет», анализ сохранит инвариант: x ≡ x0 (mod 2). Это уже лучше, чем только интервалы, но и дороже.

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

Но вообще, отвечая на вопрос, является ли одно подмножеством другого... если у абстрактной интерпретации отрезать все ограничения на входные данные, и основанные на них техники вычисления циклов и рекурсии, но пришить при этом упрощение семантики языка, то из дедушки возможно и получится бабушка🤷‍♂️

В разы быстрее, на порядок опаснее: исследование безопасности ИИ-разработки от Apiiro

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

Однако, в общую картинку почему-то хочется верить. Даже если допустить, что выводы там существенно искажены в удобную компании сторону, упоминаемая ими тенденция размена ИИ-ассистентами простых багов на более опасные и трудноуловимые архитектурные и логические уязвимости, в целом — очень похожа на правду:

AI assistants are good at catching the small stuff. Our analysis shows trivial syntax errors in AI-written code dropped by 76%, and logic bugs fell by more than 60%.

But the tradeoff is dangerous: those shallow gains are offset by a surge in deep architectural flaws. Privilege escalation paths jumped 322%, and architectural design flaws spiked 153%. These are the kinds of issues scanners miss and reviewers struggle to spot – broken auth flows, insecure designs, systemic weaknesses.

Чудес не бывает. На чем LLM обучили, на том она и хороша. А в сети — тьма открытого кода с пока ещё не найденными уязвимостями этих и аналогичных им hardcase-классов 😕 С помощью ИИ-ассистентов можно получать хороший, стабильный и безопасный код. Но для этого его нужно уметь писать и без них, формулируя соответствующие требования на входе, и проводя ревью результатов на выходе. Ну, и иметь в качестве fallback'а за спиной выстроенные и работающие процессы тестирования и безопасной разработки.

И тут было бы уместно завершить пост красивой установкой, прозвучавшей в исследовании: «внедряете ИИ-кодеров, внедряйте и ИИ-аппсеков», если бы не одно но...

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

Видимо аргумент о «чудес не бывает» — пока ещё актуален по обе стороны баррикад 🤷‍♂️

Принял участие в подкасте DevOps Deflope. Поболтали чуть за безопасную разработку и смежные с ней темы 😍

Уязвимости в дата-репозиториях. Обзорно главное

Репозитории для анализа данных и ML - зона повышенного риска ⚠️. Быстрое прототипирование, работа с чувствительными данными и специфичные инструменты создают уникальные векторы атак.
Вот ключевые из них:

1. 🤫 Секреты в коде.
Самая распространённая и критичная уязвимость. Хардкод API-ключей (например, к AWS S3, OpenAI, базам данных), токенов доступа и даже паролей прямо в Jupyter Notebook, конфигурационных файлах и скриптах. При попадании такого кода в публичный репозиторий злоумышленники получают прямой доступ к платным сервисам и данным.

Лечение
‘git grep’ + ‘truffleHog’, ротация ключей, менеджер секретов.

2. 🧑‍💻 RCE через десериализацию
Библиотеки pickle и joblib - стандарты для сохранения ML-моделей в Python - небезопасны. Десериализация файла из ненадёжного источника может привести к выполению произвольного кода на машине.

Лечение
yaml.safe_load(), ONNX, sandbox.

3. 💻 Открытые ноутбуки
Юпитер ноутбуки, развёрнутые с настройками по умолчанию, часто остаются доступными для всех в сети (особенно в облаках). Пароли, токены и результаты запросов с конфиденциальными данными могут быть видны в интерфейсе.

Лечениеты в коде.
‘nbstripout’ аудит перед коммитом. Регулярно аудить права доступа (IAM) к S3-бакетам, базам данных и другим ресурсам. Принцип наименьших привилегий - база 🤭.

4. 🙈

DoS через загрузку моделей. 
Эндпоинт для загрузки моделей без проверки размера файла может быть атакован путём отправки огромного файла, что приводит к переполнению диска и отказу в обслуживании (Denial-of-Service).

Data Poisoning. Злонамеренное изменение обучающих данных для подрыва работы модели (например, добавление в выборку для классификации спама писем с определённым словом, помеченных как "не спам").

Adversarial Attacks. Специально сконструированные входные данные, предназначенные для обмана модели (например, незаметные для человека изменения в изображении, заставляющие модель видеть не то, что есть на самом деле)

Лечение
Pre-commit хуки, сканирование в CI/CD, обучение DS основам безопасности.Менеджеры секретов, безопасные форматы сериализации, инструменты для мониторинга (Evidently AI, WhyLabs).

#DataSecurity #MLSecurity #PickleRCE #SecretsManagement #DevSecOps

🔗 Полезные ссылки:
1. TruffleHog— сканер секретов
2. nbstripout — очистка ноутбуков
3. OWASP Top 10 — главные уязвимости

Два «питомца» для ИИ-пентеста: CAI и PentAGI

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

CAI

Открытый фреймворк, реализующий функциональность ассистента пентестера.

• Сканы, поиск уязвимостей (SQLi, XSS, LFI) и базовая эксплуатация — всё в режиме автономного агента.

• Дружит с 300+ LLM (от OpenAI до Ollama), логирует действия через Phoenix и ставит guardrails, чтобы бот не сломал сам себя.

• В CTF-замерах оказался в среднем в 11 раз быстрее человека, а на отдельных задачах — в 3600 раз.

• Уже отмечен в TryHackMe и Hack The Box: находит бреши, читает /etc/passwd, но пока далёк от идеала — цепочки атак увы ещё не особо осиливает. Кожаный мешок с соответствующей экспертизой где-то рядом всё же нужен — агент далеко не всегда безошибочен и не во всем автономен.

PentAGI

По-настоящему автономный ИИ-пентестер со встроенными тулзами и собственной «долгой памятью»

• Более 20 классических инструментов (nmap, Metasploit, sqlmap и т.п.) прямо из коробки.

• Встроенный браузер и поиск (Google, DuckDuckGo, Tavily) для разведки.

• Векторная база знаний (PostgreSQL + pgvector), чтобы помнить свои прошлые результаты и выстраивать сложные цепочки последовательных атак в рамках одного дерева.

• Отчёты и метрики в Grafana/Prometheus, всё в Docker, разворачивается относительно легко.

• Ориентирован на топовые облачные LLM и весьма прожорлив до токенов (но оно того стоит).

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

...или пугать, это уж как посмотреть 😬

Как разработчику быстро вкатиться в тему LLM? Часть 5 (заключительная)

Часть 4

5. Мультиагентные системы и протоколы взаимодействия

Работая над нетривиальном агентом, разработчик может столкнуться с ситуацией, когда реализуемая им логика перестает укладываться в концепцию агента-соло. Например, когда разделение ролей, параллелизм, изоляция рисков или масштабируемость дают измеримую выгоду по качеству, времени или стоимости. Иногда перестает хватать контекстного окна, или промпт оказывается переусложненным из-за разнородности задач, или возникает необходимость использовать несколько различных моделей. В таких случаях переходят от одноагентных систем к мультиагентным (MAS), где каждый из агентов решает часть общей задачи. В такой системе нет единого центра – координация происходит либо за счёт прямого общения агентов, либо через некоторую общую среду. Основные концепции MAS неплохо описаны в этой статье.

Вот лишь некоторые возможные паттерны ролей агентов в MAS:

• Planner → Executors: планировщик дробит задачу, исполнители — узкоспециализированные агенты.

• Critic/Verifier: независимая проверка фактов/ограничений, «красные команды», контрафактуальная проверка.

• Tool-specialists: агенты-обёртки над конкретными инструментами (Bash, Snowflake, Jira).

• Memory/RAG-агенты: отдельный агент управление знанием (индексация, извлечение, цитирование).

О проектировании MAS неплохо написано тут.

Агентам в MAS нужно как-то взаимодействовать с окружением и друг-другом. С этой целью были созданы протоколы A2A от Google, и MCP от Anthropic. Поверхностно ознакомиться с ними поможет эта статья. Вкратце:

• MCP – представляет собой «универсальный разъём a-la USB» между LLM-агентом и внешними инструментами. Протокол вводит три роли участников: Host (основное приложение/интерфейс, где работает агент), Client (компонент-встроенный коннектор при модели) и Server (поставщик инструментов или данных). Фактически, Host координирует диалог и хранит общую память, Server предоставляет реализацию какого-то действия (например, доступ к базе знаний или вызов внешнего API), а Client-соединение позволяет модельному агенту запрашивать у Host доступные инструменты и вызывать их. За счёт этого агент может использовать произвольные инструменты через единый протокол, не требуя от разработчика писать для каждого API свой код обработки.

• A2A же — протокол «агент-агент», дополняющий MCP: если MCP фокусируется на подключении инструментов, то A2A стандартизирует коммуникацию между независимыми агентами (каждый из которых может быть отдельным сервисом). Агент в A2A публикует свой «карточку» с описанием возможностей, а другие агенты могут посылать ему задания через HTTP. В сочетании, MCP и A2A покрывают разные уровни: MCP – подключение одного агента к инструментам и контексту, A2A – связь между разными агентами.

Для начала работы с MCP неплохо также ознакомиться и с этой статьей.

Разумеется, изобретать заново архитектуры MAS и реализовывать протоколы взаимодействия особой необходимости нет — существуют специализированные фреймворки, в которых «всё уже украдено до нас». Наиболее популярным из них является CrewAI: Python-фреймворк, упрощающий создание и оркестрацию группы агентов. В нём вводятся основные сущности – Agent (автономный агент с определённой ролью и целями), Task (задача для агента), Crew (группа агентов, объединённых общей целью), Tool (внешний инструмент, которым могут пользоваться агенты). Фреймворк берёт на себя маршрутизацию задач между агентами и сбор результатов. Стартовать с ним поможет эта статья.

Более подробный обзор доступных открытых решений для разработки ИИ-агентов представлен здесь.

Задачка на потренироваться:

Доработать coding-агента из предыдущего задания, добавив к нему verifier-агента на базе другой reasoning-модели, верифицирующего полученные результаты.

———

На этом, серия постов про вкатывание в разработку для LLM подошла к концу. Но не рубрика «LLM для разработчиков». Stay tuned, как говорится☺️

Awesome AI Apps - технический гид по созданию LLM-приложений

🦙 Репозиторий awesome-ai-apps - коллекция продакшен-примеров для построения приложений на базе LLM. Внутри — проекты на LangChain, LlamaIndex + habr, CrewAI, Agno, Mastra, Nebius AI Studio, GibsonAI и много других полезных!..

Что можно найти:
- минимальные прототипы на базе OpenAI SDK, LangGraph, Camel AI — идеальны для экспериментов,
- готовые сценарии вроде финансового трекера, HITL-агента или бот для веб-автоматизации,
- демонстрации работы с Model Context Protocol (MCP) для репозиториев, документов или бд. Это особенно актуально для стандартизации, взаимодействия между агентами и внешними сервисами. Ну и тем, кто оттягивает знакомство с MCP, еть уже готовые анализ GitHub-репо, QnA по документации, работа с Couchbase и GibsonAI DB. Не оттягивайте 🤪.
- агенты с persistent memory (на Memori), которые позволяют строить более контекстно-зависимые системы (например, arXiv Researcher или Social Media Agent).
- примеры Agentic RAG (они не устарели!!!) с использованием Qdrant, Exa, LlamaIndex. Поддержка работы с PDF, кодом и OCR (Gemma3).
- комплексные пайплайны (например, Meeting Assistant, который конвертирует митинг в задачи и заметки, или Finance Service Agent на FastAPI)

Что под капотом (продублируем для удобства твоего гугл эдвэнсед, большинство ссылок выше) и ждет, когда затащишь себе?
🫰 LangChain + LangGraph для оркестрации агентов.
🫰 Agno как фреймворк для построения agentic workflows.
🫰 CrewAI для мультиагентных исследований.
🫰 LlamaIndex как основа RAG и документных ассистентов.
🫰 Memori для хранения контекста и долгосрочной памяти.
🫰 Nebius AI и Bright Data — как инфраструктурные провайдеры.

Установка (единый паттерн):

git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/<project_name>
pip install -r requirements.txt

🧘‍♀️ Каждый проект снабжен своим README.md, а там можно и сразу стартовать.

Этот репозиторий можно в чистом виде 🏖️ R&D-песочница, быстро тестировать разные стеки, паттерны взаимодействия агентов, интеграции MCP и реализацию RAG. Гении, как известно, воруют 👌

#AI #LLM #RAG #LangChain #LlamaIndex #CrewAI #Agno #Memori #AIagents #opensource #MCP #Python #MachineLearning #GenerativeAI

Давно хотел поделиться этой диаграммой. Впервые появившись в серии публикаций «Six Pillars of DevSecOps», она прошла некоторые эволюционные этапы, один из которых присутствует у вашего покорного слуги в офисе, в качестве подаренного коллегами на ДР визуала на пол стены 🎨

Комментировать тут особо нечего. Идеальный Secure SDLC, к которому надо стремиться. Хотя, тут ещё есть что добавить, как минимум — в плане защиты от supply-chain атак, как по мне.

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

Простая и наглядная иллюстрация, которая будет постоянно напоминать о том, почему у вас в проекте все плохо с безопасностью 😁

UTCP: новая альтернатива MCP

Универсальный протокол вызова инструментов (Universal Tool Calling Protocol, UTCP) представляет собой смену парадигмы взаимодействия ИИ-агентов с внешними инструментами и сервисами. В отличие от традиционных подходов, требующих серверов-обёрток и прокси-слоёв, UTCP обеспечивает прямое взаимодействие между агентами ИИ и инструментами через их собственные эндпоинты.

Сегодня, чтобы подключить ИИ к внешним инструментам, разработчики вынуждены писать обёртки: агент → MCP-сервер → инструмент, и неизбежно сталкиваются с:

• лишними задержками и точками отказа;
• дублированием безопасности;
• необходимости в инфраструктуре ради вторичного посредника.

UTCP убирает необходимость в такой прослойке. В целом, сравнение UTCP и MCP можно свести к следующему: UTCP — это «мануал» (описание инструмента), а MCP — «посредник» (сервер, оборачивающий инструмент). UTCP предполагает архитектуру прямого взаимодействия «агент → инструмент», тогда как MCP — «агент → MCP-сервер → инструмент».

Отсюда вытекают и все преимущества UTCP:

• Инфраструктура: UTCP не требует новых сервисов (достаточно добавить endpoint в существующий API), MCP же нуждается в отдельном сервере(-ах) для каждого набора инструментов.

• Производительность: UTCP выполняет вызов за один шаг (агент сразу обращается к API инструмента), MCP добавляет “двойной прыжок” через посредника, увеличивая накладные задержки.

• Безопасность: UTCP использует нативную аутентификацию/авторизацию инструмента, MCP вынужден реализовывать и хранить учетные данные на своей стороне, что расширяет поверхность атаки.

• Поддержка протоколов: UTCP гибок (HTTP, WebSocket, CLI, gRPC и т.д. – вплоть до чтения локальных файлов), а MCP ограничен форматом JSON-RPC поверх единственного транспорта.

• Поддержка и масштабирование: UTCP-интеграции практически не требуют поддержки (статический JSON с описанием), масштабируются вместе с существующим сервисом; MCP-серверы же добавляют постоянные заботы (деплой, обновления, мониторинг, масштабирование отдельно от основного API).

Иначе говоря, UTCP выигрывает в простоте, скорости и универсальности, тогда как MCP может дать преимущества только в узких случаях, требующих централизации и унификации ценой дополнительных усилий.

🐍 Пример клиента:

import asyncio
from utcp.client import UtcpClient
from utcp.shared.provider import HttpProvider

async def main():
    # Инициализируем UTCP-клиента
    client = await UtcpClient.create()
    # Определяем HTTP-провайдер (manual endpoint) для сервиса погоды
    manual_provider = HttpProvider(
        name="weather_service",
        provider_type="http",
        http_method="GET",
        url="http://localhost:8000/utcp"  # URL, возвращающий UTCP-описание (manual)
    )
    # Регистрируем инструменты из указанного manual (добавляем описание)
    tools = await client.register_manual_provider(manual_provider)
    print(f"Registered {len(tools)} tools")
    # Вызов инструмента "get_weather" с параметром location
    result = await client.call_tool(
        "weather_service.get_weather",
        arguments={"location": "San Francisco"}
    )
    print(f"Weather: {result['temperature']}°C, {result['conditions']}")

В случае уже имеющейся MCP экосистемы, доступен также адаптер (пока только для Node.js и Python): utcp-mcp, который позволяет подключить свыше 230 существующих MCP-инструментов через единый сервер, использующий под капотом UTCP. Это облегчает постепенный переход на новый протокол без потери доступа к старым интеграциям.

⚠️ TL;DR:

UTCP (Universal Tool Calling Protocol) позволяет ИИ-агентам напрямую обращаться к API и CLI-инструментам — без промежуточных серверов, JSON-RPC и кастомных «прокладок». Поддерживает HTTP, gRPC, WebSocket, CLI и стримы. Есть SDK для Python, Node.js, Go и MCP-адаптер под Node.js и Python.

Поэзия как джейлбрейк: стихи ломают защиту LLM

Авторы исследования «Adversarial Poetry as a Universal Single-Turn
Jailbreak Mechanism in Large Language Models» протестировали 25 моделей (OpenAI, Anthropic, Google, DeepSeek, Mistral, Meta, Qwen и др.), подавая им опасные запросы… в рифму.

Два эксперимента:

1. 20 вручную написанных стихов о кибератаках, CBRN (химическое, биологическое, радиологическое и ядерное оружие), манипуляциях и потере контроля.
2. 1200 «вредных» промптов из открытого бенчмарка MLCommons AILuminate, автоматически превращённых в стихи.

Результаты оценивали LLM-судьи и люди. Метрика — ASR (Attack Success Rate), доля небезопасных ответов.

Результаты

Ручные стихи: 62% средний успех атаки
• gemini-2.5-pro: 100%
• DeepSeek / Mistral / Qwen: 80–95%
• Лишь Claude и GPT-5-nano удержали 0–10%.

Автогенерированные стихи:
• Проза: 8% ASR
• Стихи: 43% ASR → рост в 5 раз

По темам:

• Приватность: +45 п.п.
• Ненасильственные преступления: +39 п.п.
• CBRN: +38 п.п.

Обсуждение кибератак в стихах дало 84% успеха 🤩

Почему поэзия работает

1. Фильтры обучены на прозе, а метафоры и ритм «смещают» текст от ожидаемого распределения.
2. Модели воспринимают стихи как безопасный жанр и снижают строгость отказов.
3. Большие модели уязвимее — лучше понимают переносный смысл, но не успевают применить защитные эвристики.
4. Эффект универсален: наблюдается у всех провайдеров и почти во всех категориях вреда.

Что это значит

• Текущие бенчмарки и сертификация (в духе EU AI Act) переоценивают безопасность — они не проверяют стилистические обходы.
• Нужны новые тесты, где намерение пользователя выражено не только прямым текстом, но и через поэзию, нарратив, юмор и бюрократический стиль.
• Без этого защиты условны: LLM остаются уязвимыми к самым простым «поэтическим» джейлбрейкам.

⚠ TL;DR:

Исследование показало: достаточно переписать вредный запрос в стихах — и защита крупных языковых моделей рушится. Поэтическая форма становится универсальным одностадийным джейлбрейком: для некоторых моделей доля небезопасных ответов превышает 90%, в среднем рост атак-успеха — в 4–5 раз по сравнению с прозой.

Как разработчику быстро углубиться в тему LLM? Часть 1

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

1. Токенизация и эмбеддинги
2. Механизмы внимания
3. Архитектуры трансформеров
4. Популярные архитектуры LLM
5. Проблемы и решения при работе с LLM
6. Обучение моделей
7. Эффективный инференс и деплой

Звучит, как план, правда? ☺️

1. Токенизация и эмбеддинги

Современные большие языковые модели работают на основе векторных представлений и механизма внимания, заложенного в архитектуру трансформеров. Первым шагом в обработке текста является токенизация — разбиение входной строки на токены, которые могут представлять собой слова, части слов или отдельные символы. Компиляторщиков и разработчиков средств анализа кода этот термин может слегка смутить, т.к. в NLP токенами не всегда принято считать то, что является ими в формальных языках. На практике широко используется subword-токенизация, например Byte-Pair Encoding: так, слово unhappiness может быть преобразовано в последовательность «un», «happi» и «ness». Такой подход уменьшает размер словаря и позволяет эффективно работать с редкими или ранее невстречавшимися словами.

Каждый токен получает уникальный идентификатор, по которому модель извлекает его вектор из матрицы эмбеддингов. Эмбеддинг — это высокоразмерный числовой вектор, отображающий семантику токена. После токенизации каждый элемент текста фактически превращается в набор чисел, отражающих его смысловые связи. Чем ближе по смыслу токену друг к другу, тем меньшее расстояние между ними в векторном пространстве. Например, вектор для слова apple окажется ближе к fruit, чем к car.

У моделей типа GPT-3 таблица эмбеддингов может быть очень большой: при словаре ~50 000 токенов и размерности эмбеддинга ~12 288 получается матрица порядка 50 000 × 12 288. Однако в современных крупных MoE-моделях, за счет sparse-архитектуры, эти оценки кратно меньше: 2k для 30B, 4k для 235B, например.

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

Познакомиться с этой темой ближе позволит статья «Глубокое погружение в токенизацию», для более глубокого погружения можно упороться в видеолекции (первая, вторая) от ФКН ВШЭ, или от Стэндфорда (выборочно, из первых 6 лекций), если «глубинное обучение» режет слух, и хочется привычного «deep learning».

Для специализированных задач типа анализа исходного кода, существуют отдельные модели эмбеддингов. Так, jina-embeddings-v2-base-code поддерживает английский язык и около 30 языков программирования, способна обрабатывать последовательности до 8192 токенов и оптимизирована для семантического поиска по коду. В таких моделях принципы токенизации и построения эмбеддингов остаются теми же, но словарь и обучающие данные адаптированы к структурам и паттернам программного кода.

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

• code2vec / code2seq: Path-Attention поверх AST
• GraphCodeBERT: Transformer поверх DFG + элементы GNN
• CuBERT: Transformer поверх фич CFG
• Devign: GNN поверх AST+CFG+DFG
• Code T5 / Code T5+: Transformer поверх AST-токенов

Ну и куда же без изучения тематической awesome-подборки, на правах домашнего задания 🤓