📖
RU | EN
Выпуск #7 · 11 мая 2026
RUENТекст17 минВидео32 мин

Новый способ запускать калькулятор

Переход на главу выполнен. Запустите видео вручную, чтобы начать просмотр главы.
Содержание видео
Содержание текста
Источники

Источники

Первоисточники: сами уязвимости

Kubernetes-параллель и архитектурный контекст

Что шипнули большие вендоры на той же неделе

Наука: открытые research-агенты и AlphaEvolve

Регуляторика: EU AI Act Omnibus (бонус)

AI SLOPCAST #7: Новый способ запускать калькулятор

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

А пока — таймлайн. Понедельник, четвёртое мая: Цзяотун из Шанхая публикует ARIS — опенсорсную обвязку для исследований, которая структурно конкурирует с тем, что Anthropic продаёт за деньги. Вторник, шестое число: AWS объявляет о выходе в общий доступ AWS MCP Server. В тот же день Anthropic выпускает свой managed runtime, Cursor добавляет per-agent context observability, как говорят у нас в русских деревнях. Среда, седьмое число: Microsoft Security Blog публикует две CVE в Semantic Kernel, демонстрирующие, что если у тебя на машине работает агент, то в дефолтной конфигурации взломщик всего одним промптом может запустить калькулятор на вашем компьютере. Без хитрых манипуляций с браузером, без сложных настроек, без хаков с выходом за пределы памяти. Просто пишешь текстовую строку в чат — и на экране появляется калькулятор. Без всяких подтверждений и ограничений.


Часть первая: новый способ запускать калькулятор

Начнём с Microsoft, потому что это самое наглядное. У Microsoft есть такая штука — Semantic Kernel. Это нейросетевое ядро и набор инструментов, чтобы писать нейросетевых агентов для Windows.

И конечно, его сразу же расковыряли (CVE-2026-26030). Механизм взлома: промпт-инжекшен в дефолтной конфигурации Semantic Kernel. Даже ничего настраивать не надо. Допустим, у вас есть агент с плагином для поиска в векторном хранилище — стандартная схема, прописанная в туториалах Microsoft. Атакующий встраивает некий незаметный payload в текст, и агент его случайно читает и выполняет. Этот текст может быть на веб-странице, в каком-то вордовском документе, в электронной почте. У агента, теоретически, есть защита от плохих промптов, но конкретно на этот промпт она не срабатывает. Вредоносный кусочек текста доходит до механизмов исполнения команд, где есть что-то типа стратегии для выполнения кода, что-то типа eval на произвольную строку. Вот и всё, это выполнение произвольного кода на хосте, где работает агент.

Microsoft сама сделала демку с калькулятором. Калькулятор — это такой почти археологический культурный артефакт. Калькулятор в демонстрациях чего-то про безопасность — это стандартный способ показать, что у тебя получилось запустить нечто на атакуемом компьютере. Это идёт ещё со времён Stuxnet. Когда вы видите калькулятор в демонстрации эксплойта — это нужно читать как «это демка запуска произвольного кода на Windows, она реально работает, и поэтому к ней нужно отнестись серьёзно». Microsoft не случайно решила такое продемонстрировать. Они как бы говорят: это не очередной баг в чатботе. Это новый способ делать атаки с выполнением произвольного кода.

И конечно, это не уникальный баг семантического ядра Windows. Тут видна конкретная схема: у тебя в системе должен быть плагин для поиска, плюс векторное хранилище, плюс возможность эвалить, то есть выполнять, произвольную строку. И так случилось, что базовая архитектура всех современных агентных фреймворков такова. LangChain. CrewAI. AutoGen. LangGraph. Везде это есть. Microsoft просто первыми решили всё это раскрыть, потому что всё равно найдут, тем более что Semantic Kernel — опенсорс, его читают посторонние люди, когда-нибудь они всё это раскопают. Если Microsoft не сделают это первыми, всё раскопают сторонние security-аналитики, устроят из этого скандал и Microsoft потеряет деньги.

Могу поспорить, что в течение пары месяцев эквивалентные уязвимости будут найдены и опубликованы и для LangChain, и для AutoGen, и для остальных инструментов. Это прямое следствие самой сути проблемы. Если никто про это не напишет — то это будет даже хуже. Это не значит, что в LangChain нет косяков. Это скорее про то, что такие уязвимости находятся, замалчиваются, а потом используются в каких-то целях.


Врезка: немного про науку

Параллельно случилось три академических релиза. Вышел ARIS из Шанхая. На arXiv вышел PARNESS. На Hugging Face появился MinerU2.5.

Все три проекта — это опенсорс, и все три — по сути, это улучшение AI-инфраструктуры для учёных и исследователей. ARIS делает то же, что Anthropic Outcomes — но делает это более открыто. А PARNESS — то же, что Anthropic Managed Agents — но его выложили как статью, совершенно бесплатно и открыто.

А MinerU — это такая штука, которая позволяет разные форматы документов превращать в Markdown. То есть, если у вас есть просто фотография какого-то текста или какой-то негуманоидный Excel-файл, который написал твой коллега-шизик, который как бы гений, но общается с внешним миром только в виде Excel-файлов. Весь этот мусор можно превратить в нормальные Markdown-документы и дальше, например, отправить в ИИ-агента.

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

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


Часть вторая: история с Kubernetes повторяется

Дайте я расскажу одну штуку, которая сильно проясняет картину. Если вы работали в DevOps в середине десятых годов (в каком-нибудь 2014-м или 2018-м) — вы это сразу узнаете.

В четырнадцатом году Google делает Kubernetes публичным. Компания Docker Inc. делает Swarm. Mesosphere делает Mesos. Академия публикует статьи про Borg, Omega, Quasar. Появляются альтернативы, например, rkt с pod-as-capability. Лишь через пару лет появляются первые крупные описания уязвимостей и CVE. Например, эскалация привилегий в Kubernetes.

Что случилось дальше — мы все знаем. Kubernetes, конечно, выиграл. Альтернативы, которые копировали его возможности, — почти все умерли. А большие уязвимости продолжали раскрывать годами — даже после 2020 года. Индустрия в принципе привыкла к идее, которая по-английски называется «assume breach»: мы считаем, что компрометация неизбежна, защищаемся через namespaces, RBAC и надеемся на лучшее.

Теперь смотрите. Прямо сейчас с агентными рантаймами происходит всё то же самое, что с Kubernetes в 2014 году. Множество вендоров поставляют какие-то рантаймы: Anthropic Managed Agents, AWS Agent Toolkit, Microsoft Azure Agents, Cursor SDK. Появляются какие-то академические альтернативы: вот сейчас, ARIS, PARNESS. Появляются первые крупные уязвимости — вот как сейчас, в Microsoft Semantic Kernel. Решения, которые бы ограничивали возможности агентов, существуют — например, можно хорошо контролировать безопасность WebAssembly, и Bytecode Alliance в марте этого года предложили специальный профиль для рантайма агентов. И — внимание — никто из крупных вендоров всё это не использует.

Если история Kubernetes повторится — а у нас все сигналы, что повторится — то через год или два мы будем иметь:

Один или два доминирующих коммерческих рантайма для агентов. Альтернативы будут существовать, но они будут крайне маргинальными. Уязвимости продолжат приходить бесконечным потоком. А индустрия в целом просто смирится с моделью assume-breach — мы всегда считаем, что взлом неизбежен. Будет новая категория инструментов безопасности, которая сейчас только нарождается — Microsoft Agent 365 Shadow AI Detection, AWS IAM, Anthropic Cyber Verification — они будут давать внешний периметр защиты, потому что внутри рантаймов защищаться пока никто не научился.

Можно посчитать, что это какой-то очень пессимистичный прогноз. Но по мне, так это просто реальность. Это реальность, в которой мы уже живём, пусть даже массово она игнорируется. Исходя из неё, нужно планировать технические решения. Если вы планируете развёртывание агентов в продакшене в течение этого года — закладывайте в план идею assume-breach и какую-то архитектуру, которая в этой парадигме может работать. Не надейтесь на патчи безопасности. Патчи безопасности для агентов — это оксюморон. Нужно наворачивать безопасность в виде каких-то архитектурных решений. Например, сегментация сети. Обязательная ротация паролей и прочих кредов. Изоляция на уровне конкретных возможностей и привилегий — везде, где это возможно.

Но это, конечно, относится только к продакшену. А если вы просто у себя на компьютере гоняете Claude Code, то штош — включаем bypass permissions и надеемся на лучшее. В крайнем случае, взломанный компьютер всегда можно отформатировать.


Часть третья: наименее жуткая демонстрация

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

Смотрите. Агент в продакшене имеет много привилегий. Имеет доступ к файловой системе — читает и пишет ваши документы и код. Доступ к сети — делает API-вызовы во внутренние сервисы. Доступ к запуску процессов — запускает инструменты для сборки и тесты. Доступ к паролям и прочим кредам — у него есть API-ключи и OAuth-токены, которые наверняка лежат в переменных окружения. Доступ к базе данных — часто у агента есть доступ на запись (!) к любым базам данных ваших приложений. Доступ к SDK облачных провайдеров — обычно у агента есть возможность работать с авторизацией и IAM всей вашей учётки на AWS.

Сценарий с калькулятором, глобально, означает что? Что один агент имеет все эти возможности сразу. Они и по отдельности-то были опасными, а тут — все и сразу. Реалистичное следствие из этого какое?

Во-первых, утечка и эксфильтрация всех ваших паролей — агент читает переменные окружения и шлёт их на свой endpoint где-то в интернете. Манипуляция базами данных — через соединение агента к вашей БД может записать туда какую-то подложную информацию, например, в электронном магазине добавить дорогой товар за бесценок и тут же сам его купить. Манипуляция с облачными ресурсами — взломщик легко поднимает майнинг биткоина в вашем AWS-кластере, утаскивает коммерческую тайну из S3-бакетов, модифицирует IAM-политики так, что вы никогда не узнаете, что у взломщика теперь есть совершенно легальная и неотслеживаемая учётка админа. Кроме того, у агента есть креды к другим сервисам, с которыми вы работали, — а это значит, что он дальше сможет распространяться и взламывать и эти сервисы тоже. Ну и конечно, компрометация цепочки поставок — если у агента есть доступ на запись в репозиторий, то он добавляет бэкдоры прямо в ваш код, а дальше ваш код уже взламывает сам себя.

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

Что из этого следует. Если вы запускаете Semantic Kernel в продакшене — то патч до версии 1.71 необходим, но недостаточен. Патч закрывает конкретную известную дыру. Архитектурная защита — изоляция привилегий, сегментация, ротация кредов — архитектурная защита закрывает всю категорию. И до тех пор, пока вы не закрыли всю категорию проблем — ваш агент в продакшене имеет такой уровень привилегий, который Microsoft в своей демке побоялась политкорректно показывать.

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


Часть четвёртая: ловушка метрики CVE

Microsoft Semantic Kernel — open-source. Microsoft опубликовала две уязвимости. На сайте — две. В базе CVE тоже две. Через год там, может, будет десять. Кто-то посмотрит на эту цифру и сделает вывод: «Semantic Kernel — небезопасный фреймворк, у него куча CVE».

А теперь Anthropic Managed Agents. Они не опенсорс, они closed source. AWS Agent Toolkit. Как минимум кусок — тоже закрытые исходники. Cursor SDK. Тоже закрытый. Сколько у них публично задокументированных уязвимостей? Ноль. Одна. Может быть, две. Кто-то посмотрит на эту цифру и сделает вывод: «Anthropic — безопасный, потому что у них почти нет CVE».

Это опасно неправильный вывод. Нет ничего более противоположного реальному положению вещей.

У open-source-фреймворков много CVE, потому что у них хорошо настроены процессы поиска уязвимостей. Исследователи их находят, репортят, вендоры патчат продукты, и в конце проект раскрывает и публикует уязвимости. У фреймворков с закрытыми исходниками мало CVE, потому что исследователи не имеют доступа к коду. Те уязвимости, что находятся через тестирование методом чёрного ящика, сначала отправляются в приватные программы bug bounty. Часть уязвимостей фиксится тихо, чтобы никто не узнал. Часть — никогда не доходит до публичной базы CVE. Внутренние находки безопасников вендора в принципе не идут в публичную базу CVE.

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

Как в том анекдоте про чувака, который ночью потерял ключи и искал их не там, где потерял, а под фонарём. Ищем там, где светло, не там, где потеряли. Применительно к AI-агентам это начало быть видно только сейчас. Вся эта категория уязвимостей очень молодая, и CVE-метрика только-только начинает показывать хоть какие-то данные. Но вот этот ранний период — он очень критичный. Потому что именно сейчас пользователи начнут определяться, какие продукты они считают безопасными, а какие нет. И эта репутация будет с ними на годы.

Так что вот ещё одна практическая мысль из этого выпуска подкаста. Не используйте метрику количества CVE как основную для определения безопасности агентных фреймворков. Попросите у вендора документ, в котором он рассказывает про то, какая у них политика раскрытия уязвимостей. Запросите данные о скорости, с которой они патчат эти уязвимости. Запросите процент уязвимостей, найденных внутри сотрудниками компании, — против процента найденного снаружи (клиентами или исследователями). Если вендор не может ответить на эти вопросы — это значит, что у них всё плохо. Просто имаджинируйте лицо вендора, когда вы всё это у него попросите. Если у них всё плохо, его просто разорвёт. Короче. Количество CVE — не основание. Политика разглашения уязвимостей — вот это основание.


Часть пятая: WASM спешит на помощь

Давайте поиграю в бабку-Вангу и выдам предсказание. В течение года, может через год, кто-то из основных вендоров выпустит рантайм для агентов, который работает на изолированном вебассемблере. WASM-isolated agent runtime как отдельный продукт. Я ставлю на Cloudflare. Ну или, может, я сам это сделаю, это настолько очевидно. Объясняю.

Если мы получим WebAssembly с capability-based security (то есть с безопасностью на основе привилегий и возможностей) — это техническое решение той категории проблем, которую мы видели на примере калькулятора. Принцип простой: агент не имеет полного доступа к ресурсам операционной системы. Ему при запуске явным образом выдают конкретные привилегии. Хочет файловую систему — получает её через явный запрос. Хочет сеть — через явный запрос. Если в агенте есть возможность выполнять произвольную строку, то этот eval не может убежать из клетки, которую вокруг него построили. Потому что у него нет возможности запускать произвольные процессы. Никогда. Независимо от того, что написано в промпте.

Это архитектурно исключает уязвимости, которые мы сейчас обсуждали. Это не какой-то патч, это прямо защита на уровне смыслов.

Реализации уже существуют. Например, Wasmtime, Wasmer, Cloudflare Workers WASM runtime. Никто из крупных вендоров агентов их пока не использует. Производители часто аргументируют тем, что проблема в производительности — вебассемблер не очень быстрый и просаживает минимум процентов пятнадцать на типичных нагрузках.

Но, имхо, реальная причина — не производительность. Реальная причина — vendor lock-in. Производителям очень хочется залочить всех клиентов на свою инфраструктуру. Вебассемблер по своей сути портативен. Такое приложение сможет работать на любом WASM-runtime. Вендор не хочет портативности. Вендор хочет, чтобы вы навсегда остались у него в рабстве.

И вот тут Cloudflare выделяется. Потому что вся их бизнес-модель построена на edge compute с портативными вычислениями. Их Workers AI уже поддерживает inference на устройствах пользователя. У них уже есть AI-агенты в разработке, это объявлено на Birthday Week в 2025 году. Их конкурентная позиция требует портативности — иначе они ничем не отличаются от Amazon. Точнее, отличаются, но в худшую сторону. Если они выпустят изолированный рантайм для агентов, который работает на вебассемблере, — это испортит всем остальным вендорам их игру в залочку и корпоративное рабство. Потому что всем остальным, типа Microsoft, просто нечем ответить. Не будут же они делать продукт, который ломает их же собственный vendor lock-in, который они строили годами.

Я не уверен на сто процентов, что это будет именно Cloudflare. Может быть, Vercel, Fly.io, Modal. Может быть, сюрприз — Replit. А может быть, это будет просто Олег Чирухин, потому что я очень хорошо представляю, что там можно и нужно делать. Но что портативный runtime появится — это очевидно. И когда он появится — это будет первый момент, когда все эти проприетарные фиговые дырявые решения получат ногой под жопу. И это чудесно.


Завершение

Подытожим.

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

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

Два прошлых выпуска подкаста.

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

Следующий эпизод был про интересных мемных персонажей. Маск, Шнайер, Зитрон, Тао. Индустрия ведёт себя как какой-то сериал, у которого уже много-много серий, и даже появились любимые персонажи и актёры.

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

И вот эти три эпизода подкаста — они как бы про конструирование реальности, которой ещё неделю назад не существовало. Про память. Про персонажей. Про инфраструктуру. Это как бы новое пространство, которое будет увеличиваться в размерах и в котором нам теперь жить. Через год, когда мы будем вспоминать эту неделю, мы будем удивляться, как многое из этого стало привычным и обыденным.

Спасибо, что были с нами. До следующего выпуска.

AI нейросети AI агенты AI agents Microsoft Semantic Kernel CVE-2026-26030 CVE-2026-25592 prompt injection промпт-инжекшен LangChain CrewAI AutoGen LangGraph Kubernetes assume breach agent runtime агентный рантайм WebAssembly WASM Wasmtime Wasmer Bytecode Alliance Cloudflare capability-based security Anthropic Anthropic Managed Agents Claude AWS MCP Server Cursor ARIS PARNESS MinerU AI безопасность AI security vendor lock-in подкаст Олег Чирухин Oleg Chirukhin 1red2black GitVerse