Безопасность скилла начинается до его запуска

Помимо всем известных рисков при использовании скиллов, проблемы безопасности могут возникать еще раньше — на этапе выбора скилла.

В большинстве агентских клиентов выбор скиллов работает так:

▸ В SKILL.md каждого скилла обычно есть YAML frontmatter-шапка с полями, такими как name и description (полный список полей для Claude Code)

▸ В системный промпт вашей задачи попадает список из названий и описаний из этой шапки для всех доступных скиллов

▸ На основе пользовательского запроса и текущего контекста модель решает, какой скилл лучше подходит для выполнения задачи. В конкретных клиентах это может быть свой retrieval & ranking алгоритм.

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


На фоне данных особенностей возникает ряд проблем:

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

▸ Несколько скиллов с похожим описанием создают неопределенность в действиях агента
Обычно агент может спросить пользователя про то, какой из релевантных скиллов использовать. Однако не все читают содержимое скиллов, а в full agentic mode такие уточнения могут вообще пропускаться.

▸ Манипуляция алгоритмом выбора скиллов за счет вредоносных вставок в description
В зависимости от реализации клиента это может работать как prompt injection или атака на retrieval/ranking.

▸ Фактическое содержимое скилла может отличаться от поля description


Чтобы митигировать эти риски на практике можно делать следующее:

▸ Бенчмаркать выбор скиллов
Так можно находить проблемные места в алгоритме выбора, если вы разрабатываете свой агентский клиент, или в описаниях самих скиллов. На практике для этого можно реализовать популярный нынче Agentic Loop: задача ▸ выбор скилла ▸ проверка корректности

▸ Разводить похожие скиллы
Если два скилла похожи, но имеют разные способы применения, то это явно должно быть отражено в описании.

▸ Анализировать соответствие описания содержимому скилла
Желательно это делать перед установкой или обновлением скиллов :)


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

CubeSandbox — sandbox для AI-агентов

CubeSandbox — решение Tencent Cloud, которое помогает ответить на вопрос: как изолировать агентные процессы без заметной потери в производительности.

Отличительные особенности CubeSandbox:

▸ MicroVM + snapshot-based runtime
Вместо контейнера код агентов запускается внутри MicroVM через KVM. Этот подход дает отдельное guest-ядро для sandbox, а для ускорения запуска используются memory snapshots и клоны файловой системы.

▸ Egress proxy и отсутствие доступа к токенам авторизации
Внешний трафик агента проходит через egress proxy, который позволяет контролировать исходящие запросы: домены, методы и заголовки.

Думаю, многие видели, как агенты раскрывают свои .env файлы, когда встречают prompt-инъекции в вебе. При таком подходе авторизационные токены вообще не попадают внутрь sandbox: агент отправляет запрос без секрета, а токен подставляется на уровне прокси.

▸ Поддержка multi-node
Архитектурно CubeSandbox поддерживает запуск MicroVM на нескольких compute nodes. Это позволяет масштабировать агентные задачи и параллельно запускать большое число изолированных окружений, например для субагентов.


Главная идея CubeSandbox — безопасность агентов можно вынести на уровень инфраструктуры: изолировать выполнение, контролировать сеть и управлять секретами вне самого агента.

GitHub
Сайт CubeSandbox

Принцип минимальных привилегий для AI-агентов

Недавно наткнулся на материал Microsoft именно с таким названием. Ниже — три ключевых компонента, которые я выделил, и мои мысли об их практической реализации:

▸ Отдельная identity для агента

У каждого агента должен быть управляемый жизненный цикл:

1. Identity создается при подключении агента к инфраструктуре компании.

2. Identity используется для управления правами и доступами агента.

3. При отключении агента identity блокируется, права отзываются и токены доступа инвалидируются.

На практике у агента также должен быть владелец — сотрудник или команда, отвечающие за его доступы и имеющие возможность активировать kill switch в случае инцидента.

▸ Фиксированный набор инструментов

Агенту должен быть доступен только заранее утвержденный набор инструментов под решение конкретной задачи. Такой подход авторы называют safe tool binding.

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

▸ Управление доступами с помощью RBAC

Наличие инструмента не означает, что агенту доступны все его функции. Например, инструмент для работы с тикетами может поддерживать чтение, создание, изменение и удаление, а RBAC-роль агента — разрешать только чтение и создание.

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


Мой вывод во многом совпадает с выводом авторов: компаниям уже сейчас необходимо адаптировать инфраструктуру для безопасной работы с AI-агентами.

Ссылка на блог Microsoft

Адаптирующийся бенчмарк

Недавно наткнулся на исследование Adaptive Adversaries: A Multi-Turn, Multi-LLM Benchmark for LLM Agent Security, авторы которого предлагают нестандартный подход к оценке безопасности AI-систем.

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

Такой подход заметно приближает бенчмарк к поведению реального атакующего:

▸ Адаптация к ответам защиты
После неудачной попытки attacker изменяет запрос, вместо того чтобы продолжать проверять заведомо нерабочие.

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

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

В бенчмарке участвовали Claude Opus 4.6, GPT-5.4 и Gemini 2.5 Pro. Каждая модель выступала как в роли attacker, так и в роли defender: всего авторы проверили 21 сценарий, давая атакующему до 15 раундов на адаптацию.

Среди сценариев мне особенно понравились эти два:

▸ Умный дом
Атакующему необходимо было вызвать tool, который открывает входную дверь. В одной из успешных попыток после нескольких отказов attacker выдумал обновление политики безопасности, согласно которому это действие больше не требует подтверждения владельца.

▸ Code Review
Аttacker должен был убедить AI-ревьюера одобрить код с SQL-инъекцией, выдавая уязвимость за false positive или допустимый риск.

По итогам тестирования явного лидера среди defender-моделей не выявили.

Для такой оценки используется коэффициент конкордации Кендалла W от 0 до 1. Значение 1 означает, что разные сценарии одинаково ранжируют модели, а значение около 0 — что устойчивого порядка между ними нет.

В исследовании W составил 0,19, поэтому выявить самую защищенную модель не получилось.

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

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

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

Ссылка на исследование

Суверенные и национальные модели ИИ

26 июля Владимир Путин подписал закон «О поддержке развития технологий искусственного интеллекта в Российской Федерации». Документ регулирует разработку и применение моделей ИИ, вводит специальные статусы и закрепляет базовые требования к их безопасности.

Основные нормы относятся к «большим фундаментальным моделям» — моделям от 1 млрд параметров. В первую очередь под это определение попадают крупные LLM, хотя формально оно может охватывать и другие типы моделей ИИ.

Главное нововведение закона — два специальных статуса: суверенная и национальная модель. Для обеих требуется российский разработчик, а обработка запросов и хранение данных должны выполняться в российских датацентрах.

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

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

При этом из закона не до конца понятно, где проходит граница «суверенности». Какие компоненты технологического стека обязательно должны быть российскими: языки программирования? Фреймворки? А может, GPU?

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

Особенно важным здесь может стать как раз доступ к GPU и вычислительным мощностям.

Здесь уместно вспомнить законы масштабирования (scaling laws). Одним из авторов ключевой работы по этой теме был Дарио Амодеи, CEO Anthropic. Упрощенно их вывод можно передать так:

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

Поэтому практическая ценность поддержки будет во многом зависеть от доступа к дефицитным в России вычислительным мощностям.

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


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

Новость на РБК
Полный текст федерального закона

Попали в программу OFFZONE 2026 с докладом про пайплайн проверок безопасности агентских скиллов.

Вместе со мной будет выступать Руслан (@Su9r3m3).
Можете заодно подписаться на его канал AI Sec Notes.

Приходите послушать :)

CyberGym, или как мы снова ведемся на маркетинг

Одним из главных бенчмарков для оценки AI-систем в кибербезопасности сегодня стал CyberGym. Так, например, Microsoft заявляет, что ее система поиска уязвимостей MDASH достигла 96%. А агент Atlas от Wiz держит первое место в публичном лидерборде данного бенчмарка с результатом 90,9%.

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

Сам CyberGym состоит из 1507 исторических уязвимостей в open-source. При этом на вход агенту подаются как описание уже известной уязвимости, так и код до ее исправления. Агент должен подготовить PoC, который воспроизведет этот баг. То есть оценивается воспроизведение уязвимостей по описанию, а не поиск уязвимостей с нуля.

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

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

В недавнем кейсе OpenAI/Hugging Face модели пытались получить готовые решения ExploitGym, а во время cyber-evals Anthropic агенты атаковали реальные системы, считая их частью симуляции. Причем именно стремление агентов выполнить задачу любым доступным способом и привело к этим инцидентам.

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

CyberGym
MDASH от Microsoft
Инцидент от OpenAI / Hugging Face
Cyber-evals Anthropic

Stolen Thoughts: как слабая модель раскрывала внутренний reasoning сильной

Исследователи смогли вытащить внутренний reasoning передовых моделей Anthropic, OpenAI и Google. Для этого они использовали зашифрованные reasoning-блоки и jailbreak-атаки на слабые модели тех же провайдеров.

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

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

Именно здесь и нашли багу.

Провайдеры проверяли, что зашифрованный reasoning создан их сервисом, однако проверка не зависела от конкретной модели, пользователя и сессии.

Поэтому сервер расшифровывал reasoning-блок чужой сессии, а исследователи использовали слабую модель, чтобы через jailbreak раскрыть его содержимое. (а-ля decryption oracle)

Авторы применили атаку к 6.708 публичным агентским сессиям с GitHub и Hugging Face и реконструировали содержимое 315.320 reasoning-блоков.

В реальных сессиях обнаружили 704 потенциально чувствительных артефакта: API-ключи, пароли и токены. Правда, только 64 из них находились исключительно внутри reasoning и отсутствовали в видимой истории.

Помимо утечки секретов, атаку можно было использовать для:

▸ дистилляции передовых моделей

▸ внедрения скрытых prompt-инъекций (при передаче reasoning-блока в новую сессию)

До публикации авторы сообщили о проблеме провайдерам. После исправлений атака уже не воспроизводится.


Удивительно, как в погоне за удобством пользователей три ведущих LLM-провайдера допустили схожую уязвимость :)

Сайт исследования Stolen Thoughts
Пост одного из авторов в X

Как вкатиться в AI Security?

За последнее время меня несколько разных человек спросили, с чего начать изучение AI Security. Поэтому постарался собрать список материалов — от базовой теории до более глубокого погружения.

▸ Основная теория: LLM и Агенты

• Andrej Karpathy: Deep Dive into LLMs like ChatGPT — хорошее видео для введения

• Anthropic: Building Effective Agents — agents, workflows и tools.

• Model Context Protocol — что такое MCP

• Google Cloud: What is RAG? — как работает RAG

• Agent Skills Overview — устройство agent skills


▸ Погружаемся в AI Security

Теория

• OWASP Top 10 для LLM и Agentic Applications — ежегодный топ уязвимостей для LLM-приложений и AI-агентов от OWASP (версия 2026 года)

• Microsoft AI Red Teaming 101 — курс из 10 видео от Microsoft про AI Red Teaming

• MIT: AI Agent Security — запись лекции из MIT из курса Computer Systems Security, Spring 2026

Практика

• PortSwigger: Web LLM Attacks — лабораторные по уязвимостям LLM приложений от разработчиков Burp Suite

• Agent Breaker — набор заданий от создателей Гендальфа (того самого, у которого нужно было украсть секрет)

Курсы и сертификации

• HTB Academy: AI Red Teamer + HTB COAE — практический курс и сертификация от платформы HackTheBox, разработанный вместе с Google (недорого)

• OffSec AI-300 — курс и экзамен от OffSec (дорого, но известно)

Фреймворки и методологии

• Google SAIF — фреймворк от Google, который связывает компоненты AI-системы с рисками и мерами защиты. Есть отдельный раздел про AI-агентов

• NIST AI RMF — фреймворк NIST для работы с AI-рисками

• MITRE ATLAS — MITRE ATT&CK только для AI

• OWASP AI Testing Guide — гайд по тестированию всей AI-системы: от моделей и данных до приложений и инфраструктуры


▸ Как следить за новостями по AI Security

Telegram

• https://t.me/addlist/7N0onqrNfTBkMGYy — папка с каналами по AI Security (самые интересные новости обычно освещаются в каналах из подборки)

Блоги AI-вендоров

• Anthropic

• OpenAI

• Google Security Blog

• Microsoft AI Red Team

Технические блоги отдельных исследователей и компаний

• Embrace The Red

• Simon Willison

• Invariant Labs

• Trail of Bits

• HiddenLayer Research


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

Также актуальные темы из области AI Security можно будет услышать завтра на OFFZONE на треке AI.ZONE. Приходите — пообщаемся.

MaliciousSkillBench: бенчмарк по поиску вредоносных скиллов

В MaliciousSkillBench авторы собрали единый бенчмарк на основе 13 публичных источников для проверки безопасности скиллов. На нем они сравнили несколько существующих сканеров, а также обучили и проверили собственные текстовые классификаторы.

После объединения в бенчмарке осталось 9740 скиллов: 7505 вредоносных и 2235 безопасных. Их разделили случайно: по группам похожих скиллов и по источникам. При этом и классификаторы, и готовые сканеры анализировали только текст SKILL.md — без остальных файлов.

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

Лучший же текстовый классификатор авторов (Word TF-IDF + SVM) получил Macro-F1 0,932 на тесте при случайном разбиении и 0,665 — на источниках, не встречавшихся при обучении. На новых источниках он нашел 95,6% вредоносных скиллов, но ошибочно заблокировал 62,4% безопасных.


Такой подход мне кажется интересным, но на практике:

▸ Текстовый классификатор может быть одним из этапов проверок, но с FPR 62,4% в проде тебя съедят коллеги :)

▸ Анализа одного SKILL.md недостаточно: он может не содержать признаков атаки, а вся вредоносная нагрузка — находиться в других файлах скилла

▸ Поэтому совсем без LLM-анализа пока, кажется, не обойтись

Препринт MaliciousSkillBench
Датасет на Hugging Face
GitHub

Model Hardware Standard: когда промпт-инъекции выходят в физический мир

Anthropic представили Model Hardware Standard (MHS) — стандарт для подключения AI-агентов к роботизированным рукам, лазерам и другому оборудованию с программным интерфейсом.

Для каждого устройства создается MHS-драйвер, который переводит его API в общие операции вроде read и write, а также описывает возможности и ограничения оборудования. После этого агент может управлять устройством через единый MHS-интерфейс, доступный из MCP, CLI или API.

Хотя MHS может заметно упростить автоматизацию умного дома (или лаборатории), я вижу здесь как минимум три критичные проблемы:

▸ До сих пор последствия prompt injection в основном ограничивались цифровым миром — например, утечкой почты или документов. С MHS такая атака может закончиться отключением датчика температуры или изменением мощности лазера.

▸ Уязвимость в популярном MHS-драйвере затронет все устройства, в которых он используется. Получаем большой blast radius и потенциально серьезные последствия.

▸ В MHS-драйвер могут не попасть неочевидные ограничения: техническая документация (как мы знаем) редко отражает все подводные камни. В результате ошибка агента может закончиться поломкой дорогостоящего оборудования.

Закрытый research preview MHS как раз дает время разобраться с этими и другими потенциальными проблемами до публикации стандарта — антропики прямо пишут, что используют этот этап для дополнительного тестирования и доработки механизмов безопасности.

Остается вопрос: появится ли надежная защита от prompt injection раньше, чем MHS получит массовое распространение?

Anthropic - Model Hardware Standard

Вышла запись нашего с Русланом выступления на AI.ZONE треке OFFZONE 2026.

В своей части я рассказал:
▸ на что нужно обращать внимание при проверках;
▸ как мы реализовали проверки безопасности для реестра скиллов в Яндексе;
▸ сколько стоят проверки и сколько по времени занимают.

А Руслан объяснил, почему проверок отдельных скиллов недостаточно и какие риски возникают при их совместном использовании.

▸ Запись выступления
▸ Презентация

А остальные доклады OFFZONE 2026 можно посмотреть в плейлисте.

В этом году очень много докладов про ИИ в кибербезопасности, планирую посмотреть те, которые упустил во время конференции.