Безопасность навыков ИИ-агентов: проверяйте цепочку

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

Материал предназначен для CTO, CISO, владельцев процессов и команд, которые подключают агентам skills, плагины, MCP-серверы и бизнес-системы. Он объясняет архитектурную проверку цепочек; аудит конкретного продукта, юридическая оценка и обещания полной защиты в scope не входят.

Содержание

Что показало исследование CompoSkill
Почему безопасные навыки не образуют безопасную систему
Модель источник — мост — эффект
Какие цепочки искать в бизнес-процессе
Метод ЦЕПОЧКА для проверки маршрута
Какие контроли ставить в runtime
Почему approval и сканер недостаточны
Как провести безопасный пилот
Что измерять
Ограничения исследования
Частые вопросы
Как AI рассвет помогает проверить агентный маршрут
Вывод

Что показало исследование CompoSkill

17 августа 2026 года на arXiv опубликован препринт CompoSkill: Compositional Skill Chain Attacks from Individually Scanner-Passing LLM Agent Skills. Его главный тезис: статус «прошёл сканер» относится к одному навыку, но риск может появиться только после объединения нескольких навыков в маршрут.

Авторы собрали CompoSkill-Bench из 1 140 записей: 380 профессиональных задач в чистой, явной и неявной атакующей версии. Набор охватывает пять типов угроз, шесть рабочих сценариев и 76 ролей на двух агентных средах — OpenClaw и Nanobot. В экспериментах частота формирования рискованной цепочки достигала 83,3% в white-box и 80,6% в black-box режиме. Это показатели конкретного бенчмарка, а не оценка вероятности атаки в компании.

Особенно важен black-box сценарий: атакующий не называл идентификаторы навыков. Он формулировал правдоподобную рабочую задачу, а агент сам находил подходящую комбинацию. В примере с DevOps один навык читал конфигурацию, второй оформлял её как аудиторский отчёт, третий отправлял отчёт наружу. Каждый компонент мог выглядеть нормальным по отдельности.

Исследование сравнило три сканера в строгом режиме блокировки. После удаления отмеченных пакетов частота формирования цепочек в одной конфигурации снизилась с 63,2% до 36,8–40,8% для двух сканеров и до 31,6% для третьего. Авторы интерпретируют это как сохранение 50–65% композиционной способности атаки. Вывод не в том, что сканеры бесполезны: они уменьшают поверхность риска, но не наблюдают весь путь, который агент построит во время выполнения.

Почему безопасные навыки не образуют безопасную систему

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

Это похоже на транзитивное разрешение, которого никто явно не выдавал:

прочитать конфигурацию
  → собрать отчёт
  → отправить подрядчику

локальные разрешения: допустимы
сквозной эффект: секрет покинул доверенную зону

Поэтому инвентаризация пакетов отвечает лишь на вопрос «что установлено?». Для безопасности нужны ещё три вопроса:

Какие состояния может прочитать каждый компонент?
Во что его выход может превратиться на следующем шаге?
Какой внешний, постоянный или привилегированный эффект завершает маршрут?

Тот же принцип уже виден в официальных рекомендациях. Google Cloud отдельно называет insecure tool chaining риском agent-only режима и советует выделенную identity с least privilege. Спецификация MCP запрещает token passthrough и требует привязывать токен к целевому ресурсу, чтобы не создавать confused deputy. NIST NCCoE ставит в центр идентификацию, авторизацию, аудит и неотказуемость действий агентов. Это независимые подтверждения архитектурного направления, а не подтверждение процентов CompoSkill.

Модель источник — мост — эффект

Для первичной проверки удобно разложить маршрут на три роли.

Роль	Что делает	Типичные возможности	Главный вопрос
Источник	получает чувствительное или управляющее состояние	файлы, config, база данных, память, почта	какие данные могут выйти из доверенной зоны?
Мост	нормализует, суммирует, архивирует или превращает данные в команду	отчёт, скрипт, таблица, вложение, prompt	скрывает ли преобразование риск исходного состояния?
Эффект	создаёт внешний, постоянный или привилегированный результат	сеть, shell, сообщение, запись в память, изменение прав	можно ли остановить или откатить действие?

Мост особенно опасен не потому, что он вредоносный. Он делает переход естественным. В CompoSkill частота формирования цепочки утечки выросла с 64,9% для двух навыков до 80,6% для трёх; для повышения привилегий — с 65,8% до 71,1%. Средняя attack success rate в расширенном опыте выросла с 35,2% на двух шагах до 55,4% на трёх, а затем снижалась до 37,8%, 33,6% и 21,8% на четырёх, пяти и шести шагах. Авторы называют это bridge-bonus-then-hop-decay.

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

Какие цепочки искать в бизнес-процессе

Угроза	Источник	Мост	Эффект	Пример бизнес-инварианта
Утечка данных	CRM, почта, секреты, договоры	сводка или экспорт	внешняя почта, webhook, облачный диск	конфиденциальные поля не покидают approved destination
Подмена памяти	policy или память агента	«полезная» инструкция	долговременная запись	внешние данные не меняют policy без отдельного owner
Повышение привилегий	роли и окружение	генератор скрипта	shell, IAM, admin API	выданное право не шире делегированного пользователем
Захват другого агента	handoff и routing state	общая задача	межагентное сообщение	получатель заново проверяет источник и scope
Истощение ресурсов	квота и статус задачи	цикл или retry plan	повторные вызовы	бюджет, глубина и число повторов ограничены policy

Не ограничивайтесь названиями инструментов. report-builder звучит безобидно, но его выход может сохранить секреты в документе. email-sender не знает, что вложение чувствительное. Поэтому полезнее описывать возможности как поток: read:secret → transform:document → send:external.

Для каждого пути зафиксируйте доверенные зоны. Отправка из CRM во внутренний DLP-контур и отправка того же объекта на произвольный адрес — разные эффекты. Запись в временный scratchpad и изменение долговременной памяти агента — разные уровни устойчивости.

Метод ЦЕПОЧКА для проверки маршрута

Предлагаем метод ЦЕПОЧКА. Это редакционный синтез свежего исследования и официальных security-guidance, а не отраслевой стандарт.

Ц — Цель

Запишите исходную бизнес-цель и допустимый конечный результат. Формулировка «подготовить аудит» не должна автоматически включать отправку наружу или чтение всех конфигураций.

Е — Естественный маршрут

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

П — Права

Для каждого вызова укажите identity, ресурс, scope, срок и делегирующего субъекта. Выдавайте токен целевому сервису, не передавайте универсальный пользовательский токен по цепочке.

О — Остановка

Определите контроль до сильного эффекта: policy denial, human approval, two-person rule, allowlist назначения или безопасный fallback. Проверка после отправки обнаруживает инцидент, но не предотвращает его.

Ч — Чувствительные данные

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

К — Канал эффекта

Перечислите терминальные возможности: внешняя сеть, сообщения, shell, database write, изменение IAM, публикация, память. Чем хуже обратимость, тем уже должен быть интерфейс.

А — Аудит

Сохраняйте фактическую траекторию: actor, delegated user, policy version, входные метки, вызовы, аргументы, решение контроля, получателя, результат и rollback handle. Секреты в журнал не копируют; достаточно безопасной ссылки, digest или redacted evidence.

Какие контроли ставить в runtime

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

Запрос пользователя / внешние данные
             ↓
          Planner
             ↓
  Policy engine по всей траектории
      ↙ deny   ↓ allow   ↘ approval
  узкие tool adapters с отдельными identities
             ↓
  Target system повторно проверяет scope
             ↓
  Postcondition verifier + audit event

Минимальный runtime-набор:

Раздельные identities. Агент и пользователь не делят бессрочный супер-токен.
Узкие инструменты. send_approved_report(destination_id, artifact_id) безопаснее универсального SMTP-клиента.
Метки происхождения. Классификация данных переносится через преобразования.
Проверка назначения. Allowlist учитывает домен, tenant, проект и тип получателя.
Запрет опасных сочетаний. Policy оценивает недавний источник данных и запрошенный эффект вместе.
Ограничение бюджета. Лимиты на hops, retries, стоимость, время и объём внешних операций.
Независимая верификация. Результат читается из целевой системы, а не из текста агента.

OWASP AI Agent Security Cheat Sheet рекомендует повторять security testing после существенных изменений prompts, tools, memory, retrieval, policy или model provider и отдельно проверять tool misuse, privilege escalation, memory poisoning, data exfiltration и recursive tool abuse. Это означает, что разрешённый граф нельзя сертифицировать один раз навсегда.

Почему approval и сканер недостаточны

Human approval полезен, когда человек видит содержательное представление эффекта. Запрос «разрешить email-dispatcher?» почти ничего не сообщает. Нужны получатель, классификация вложения, происхождение данных, diff, основание, scope разрешения и возможность отказаться.

Плохой approval становится rubber stamp, если:

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

Сканер и approval решают разные задачи. Сканер оценивает компонент до установки; approval проверяет отдельное действие; policy engine ограничивает маршрут; целевая система защищает собственные инварианты. Удаление любого слоя увеличивает зависимость от остальных.

Для prompt injection действует тот же принцип. Инъекция может доставить вредоносную цель, но ущерб появляется, только если инфраструктура позволяет соединить данные и эффект. Поэтому общие меры защиты ИИ-агентов нужно дополнять path-level контролем. А графовая инженерия помогает сделать зависимости и точки исполнения явными.

Как провести безопасный пилот

Выберите один процесс. Зафиксируйте владельца, baseline, данные, ограничения и критерий приёмки.
Составьте capability inventory. Для каждого навыка опишите read, transform, write, send, execute и persist.
Постройте граф маршрутов. Начните с коротких путей источник → эффект и источник → мост → эффект.
Запишите запрещённые сочетания. Например: customer_pii → external_message без DLP и отдельного подтверждения.
Выдайте минимальные права. Создайте agent identity, resource-bound tokens, allowlists и TTL.
Запустите replay. Прогоните нормальные задачи и пять классов атакующих сценариев на копии данных.
Перейдите в shadow mode. Агент строит маршрут, но сильные эффекты исполняет человек или симулятор.
Откройте ограниченное исполнение. Разрешите только наблюдаемо безопасные пути с kill switch и rollback.
Перетестируйте изменения. Новый skill, версия policy, модель или интеграция создают новый граф.

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

Что измерять

Метрика	Как считать	Что она показывает	Чего не доказывает
Forbidden path rate	запрещённые маршруты / все предложенные маршруты	склонность планировщика собирать рискованный путь	вероятность реального инцидента
Pre-effect block rate	заблокированные до эффекта / все запрещённые маршруты	работа runtime-policy	отсутствие обходных каналов
Approval precision	содержательные отклонения / все запросы approval	качество маршрутизации к человеку	безопасность автоматически разрешённых путей
Utility completion	корректно завершённые чистые задачи / чистые задачи	цена контроля для полезного процесса	экономический эффект внедрения
Evidence completeness	события с actor, scope, inputs и result / все эффекты	расследуемость	корректность решения агента
Recovery success	успешно откатанные тесты / тесты отката	работоспособность recovery	обратимость внешних коммуникаций

Пороговые значения следует задавать по критичности процесса и собственному baseline. Нельзя брать 83,3% или другие показатели CompoSkill как целевой KPI: это характеристики экспериментальной установки.

Ограничения исследования

CompoSkill опубликован как arXiv v1; на дату наблюдения независимое рецензирование не подтверждено. Эксперименты ограничены двумя агентными средами, выбранными моделями, marketplace skills, синтетически собранными атакующими вариантами и судьями исследования. Они показывают существование и воспроизводимость класса риска, но не измеряют распространённость успешных атак в реальных компаниях.

Метрики ASR и CFR различаются: агент может собрать рискованную цепочку, но не довести её до вредного эффекта. Более низкие показатели одной модели в таблице не доказывают её универсальную безопасность. И наоборот, высокое значение в одном сценарии не прогнозирует результат вашей конфигурации.

Официальные рекомендации Google Cloud, MCP, NIST и OWASP подтверждают необходимость least privilege, привязки токена к ресурсу, аудита и проверки цепочек, но не валидируют методологию или проценты CompoSkill. До решения о production нужны собственные replay, adversarial tests и проверка целевых систем.

Частые вопросы

Что такое навык ИИ-агента

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

Достаточно ли проверить каждый skill сканером

Нет. Сканер снижает риск отдельного компонента, но может не увидеть маршрут, который появится только во время выполнения. Нужны capability graph, runtime-policy и контроль сильного эффекта.

Чем композиционная атака отличается от prompt injection

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

Какие цепочки проверять первыми

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

Нужно ли запрещать агенту все внешние действия

Не обязательно. Безопаснее дать узкий интерфейс, отдельную identity, allowlist получателей, TTL, лимиты, проверку классификации данных и approval для исключений, чем универсальный инструмент с широкими правами.

Когда повторять тест безопасности

После изменения навыка, модели, prompt, памяти, retrieval, policy, набора прав, MCP-сервера или бизнес-интеграции. Любое такое изменение может создать новый допустимый путь.

Как AI рассвет помогает проверить агентный маршрут

AI рассвет может встроить path-level контроль в конкретный бизнес-процесс:

Провести аудит процесса, данных, baseline, ограничений и критерия приёмки.
Описать capability graph навыков, MCP-серверов и интеграций с бизнес-системами.
Спроектировать узкие tool adapters, agent identities, policy checks, approvals, журналирование и recovery.
Провести MVP, тестирование, запуск, обучение команды и поддержку изменений.

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

Обсудить задачу

Вывод

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

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