Робот с Physical AI умеет выглядеть полностью исправным: камера отдаёт поток, VLA-модель запускается и отвечает, контроллер принимает команды, аварийные контуры молчат. Действует он при этом на основе подменённых данных. Классическая функциональная безопасность такие сценарии не покрывает по построению: она отвечает на вопрос «что случится, если компонент откажет», а не «что случится, если кто-то целенаправленно изменит его входы».
Угроза распределена по трём уровням. На обучении в модель закладывают скрытый триггер, и на чистых данных она ведёт себя штатно. В системном стеке остаются незакрытые Bluetooth-цепочки и middleware вроде ROS 2 с DDS, где аутентификация и шифрование не включены по умолчанию. В рантайме атакуют восприятие и рассуждение: подменённый кадр, наклейка на объекте, специально подобранный промпт. Проверка модели перед деплоем не отсекает ни один из этих сценариев полностью.
Дальше разобраны публичные работы 2017-2025 годов (BadNets, BadVLA, GoBA, UniPwn, RoboPAIR, BadRobot, VLAttack, FreezeVLA), три уровня атак, причины, по которым валидация пропускает бэкдоры, и практика защиты: сканирование моделей, проверка устойчивости в симуляции на базе NVIDIA Isaac Sim и валидаторы вроде VicOne Radeis, плюс мониторинг поведения в эксплуатации.
Почему классическая функциональная безопасность не защищает Physical AI
Функциональная безопасность строится вокруг отказов. Стандарты IEC 61508, ISO 13849, IEC 62061 и ISO 10218 требуют, чтобы при отказе датчика, потере питания или сбое контроллера система уходила в безопасное состояние. Логика простая: элемент ломается, система это замечает, робот останавливается.
Атака ломает эту логику, потому что отказа нет. Все компоненты работают в пределах допусков, а неверным оказывается смысл входных данных. Камера исправна и передаёт валидный видеопоток, но объект в кадре подменён наклейкой. Лидар выдаёт корректные точки, только часть из них сгенерирована спуфером. Канал оператора технически в порядке, а инструкция внутри него обходит ограничения модели.
Отдельная линия стандартов ближе к теме, но и она не закрывает вопрос целиком. ISO 21448 (SOTIF) разбирает случаи, когда система работает как задумано, а результат опасен из-за ограничений восприятия и неверных допущений о среде. Модель угроз там не злонамеренная: сценарии касаются недостаточной производительности, а не противника, который целенаправленно подбирает вход. Кибербезопасность машин и промышленной автоматизации живёт в других документах: ISO/SAE 21434 для транспорта, IEC 62443 для АСУ ТП. На стыке AI-восприятия, обучения на данных и физического действия эти рамки сходятся плохо.
Чем кибербезопасность Physical AI отличается от классической кибербезопасности
В обычной IT-системе последствия укладываются в триаду: утечка данных, нарушение целостности, простой сервиса. В Physical AI к этому добавляется кинетический результат. Манипуляция входом превращается в движение манипулятора, разгон шасси, сброс груза.
Классические средства защиты плохо подходят к новой поверхности атаки. Антивирус и файрвол умеют проверять файлы, сетевые пакеты и подписи, но не скрытые представления модели и не семантику входа. Разница принципиальная: в вебе и телекоме защищают канал передачи, здесь опасен корректно доставленный, но специально сконструированный контент.
Что именно добавляется в поверхность атаки:
- веса модели и чекпоинты, скачанные из внешнего репозитория или полученные от подрядчика;
- обучающие и дообучающие данные, включая логи телеуправления и краудсорсинговые наборы;
- сенсорный вход: камера, лидар, микрофон, тактильные сенсоры;
- языковой канал: инструкции оператора, текстовые метки на объектах, подписи из внешних сервисов;
- middleware и транспорт: топики ROS 2, DDS, беспроводные интерфейсы;
- обновления прошивок и моделей, флот-менеджмент, телеметрия.
Хорошая иллюстрация разницы: бэкдор в модели распознавания знаков в своё время описали как угрозу цепочки поставок, а не как сетевую атаку. Модель с высокой точностью на чистых данных ведёт себя неверно только при появлении триггера, и никакой сетевой периметр такого поведения не видит.
Почему проверки модели на этапе валидации не гарантируют безопасность в эксплуатации
Работа BadNets 2017 года показала механику, которая с тех пор не изменилась. В обучающую выборку добавляют небольшую долю примеров с триггером (например, паттерном в углу изображения) и подменённой меткой. После обучения модель уверенно распознаёт обычные объекты и переключается на класс атакующего, когда видит триггер. Точность на чистой тестовой выборке остаётся в норме.
Отсюда практический вывод: метрики accuracy, precision и recall считаются на данных без триггера, и бэкдор для них невидим. Порог срабатывания может быть завязан на сочетание условий, которое в тестах не воспроизводится. Модель, прошедшая приёмку, остаётся уязвимой.
Чтобы найти такое, нужны отдельные методы: обратный инжиниринг триггера, анализ кластеров активаций, обрезка «лишних» нейронов. Каждый работает с ограничениями: возможны ложные срабатывания, часть бэкдоров устойчива к очистке, а стоимость проверки растёт вместе с размером модели.
Три уровня атак на роботов с Physical AI
Уровни удобно разделять по моменту вмешательства. Атака на данные срабатывает до деплоя и живёт внутри модели. Атака на стек использует штатные интерфейсы робота. Атака в рантайме меняет то, что робот видит и как он это толкует. Комбинации тоже встречаются: подмена топика DDS может доставить в VLA-модель изображение с триггером, который активирует бэкдор.
| Уровень | Точка вмешательства | Что видно снаружи | Что помогает |
|---|---|---|---|
| Данные и модель | Датасет, чекпоинт, дообучение | Робот исправен, метрики в норме | Проверка происхождения, сканирование весов |
| Системный стек | Bluetooth, ROS 2/DDS, OTA | Трафик, версии, конфигурация | Инвентаризация, SROS2, подписи, сегментация |
| Рантайм | Сенсорный вход, промпт, рассуждение | Ничего специфического, только поведение | Мониторинг, сверка сенсоров, ограничители |
Уровень 1: Отравление обучающих данных и бэкдоры в VLA-моделях
Отравление данных (data poisoning) означает подмену или добавление примеров в обучающую выборку. Бэкдор - частный случай: он оставляет обычное поведение нетронутым и ждёт триггера.
VLA-модели (vision-language-action) тут в зоне повышенного риска, поскольку объединяют восприятие, языковую инструкцию и моторное действие в одной политике. Канал воздействия расширяется: триггером служит визуальный маркер в сцене, редкое слово в команде или сочетание объекта и контекста. Публичные работы описывают два характерных сценария. BadVLA показывает, что в бэкдор можно заложить выбор конкретного действия злоумышленника при штатном поведении в остальное время. GoBA строит триггер градиентным методом: паттерн подбирается так, чтобы срабатывать надёжно и оставаться малозаметным.
Данные для таких моделей часто собирают из телеоперации и краудсорсинга, а сами веса и наборы скачивают из внешних хабов. Участвуют несколько подрядчиков, версии расходятся, и проверить происхождение каждого кадра дорого. Похожая логика разобрана на стороне LLM-агентов: материал про промпт-инъекции, отравление данных и атаки через инструменты показывает, как испорченный источник данных даёт устойчивый эффект.
Что помогает на этом уровне: фиксация происхождения датасетов и чекпоинтов с хешами, ограничение доступа к пайплайну дообучения, сканирование весов перед приёмкой, отдельная проверка тех подрядчиков, кто отдаёт данные и модели.
Уровень 2: Уязвимости системного стека: Bluetooth-цепочка UniPwn и дыры в ROS 2/DDS
Классический софтверный стек робота состоит из прошивки, беспроводных интерфейсов, операционной системы, middleware и прикладной логики. Ошибка на нижнем слое обесценивает любые проверки на верхнем: приложение может быть корректным, но команды в него попадают от того, кто уже получил доступ к устройству.
Раскрытие UniPwn описывает цепочку уязвимостей в Bluetooth-стеке роботов, которая позволяет атакующему в зоне радиосвязи получить контроль над устройством. Цепочка ценна как пример: каждая отдельная ошибка может выглядеть некритичной, но вместе они снимают слои защиты и обходят прикладные ограничения, потому что выполняются там, где эти ограничения не действуют.
ROS 2 работает поверх DDS, и в базовой конфигурации этот транспорт рассчитан на открытое взаимодействие. Обнаружение узлов идёт широковещательно, публикация в топик и подписка на него не требуют подтверждения личности, трафик не шифруется. Любой в той же сети может читать поток с камеры, подменять данные лидара или отправлять собственные управляющие сообщения. Штатный механизм защиты существует: DDS-Security и надстройка SROS2 дают аутентификацию, шифрование и управление доступом к топикам. На практике их часто не включают: мешает совместимость с устаревшими узлами, дополнительная настройка PKI и падение производительности на слабом железе.
К этому уровню примыкают обновления без проверки подписи, открытые отладочные интерфейсы и сервисные порты, слабое управление ключами на устройстве. Сканер уязвимостей тут работает привычно: инвентаризация зависимостей, версии middleware, известные CVE в Bluetooth-стеке и библиотеках. Дополнительно стоит проверить конфигурацию, а не только версии: включён ли SROS2, ограничено ли обнаружение узлов, подписаны ли OTA-пакеты.
Уровень 3: Манипуляции восприятием и рассуждением в рантайме
Атаки рантайма ничего не меняют в модели и коде. Воздействие идёт на вход или на цепочку рассуждения, и по логам всё выглядит как обычная работа.
RoboPAIR автоматизирует подбор промптов, которые снимают ограничения у роботов с LLM-планировщиком. По данным авторов, в их экспериментах удавалось добиться выполнения запрещённых действий на нескольких платформах: модель получает текстовую инструкцию, формально не нарушающую фильтры, и переводит её в физическое действие.
BadRobot работает через восприятие: вредоносная цель подаётся так, что воплощённая LLM считает её легитимной задачей из окружения, и робот выполняет её, оставаясь внешне послушным. VLAttack строит состязательные пары «изображение + текст», которые провоцируют небезопасный вывод vision-language модели. FreezeVLA описывает атаку, приводящую к «замораживанию» VLA-политики: робот перестаёт выполнять действия, то есть речь об отказе в обслуживании, а не о подмене цели.
Заметить такое сигнатурными средствами сложно: нет вредоносного файла, нет эксплойта в коде, нет аномального сетевого соединения. Нужны поведенческие проверки: сверка показаний сенсоров между собой, контроль допустимости последовательности действий, детекторы выхода входа за пределы обучающего распределения.
Тут же работает опыт защиты LLM-агентов через несколько эшелонов проверок: разбор трёхфазной защиты агентов показывает, как эвристики, классификатор и детектор чувствительных данных ловят подозрительные входы до того, как они дойдут до действия.
Почему валидация модели не гарантирует безопасность в эксплуатации
Разрыв между тестом и эксплуатацией складывается из нескольких причин.
- Триггер отсутствует в тестовой выборке. Если он не встречается в данных приёмки, у модели нет повода проявить вредоносное поведение.
- Условие срабатывания составное. Триггер может требовать сочетания объекта, места и времени, которое воспроизводится только на площадке заказчика.
- Физический мир открыт. Число возможных входов не ограничено набором тестовых сценариев, а наклейку можно напечатать и показать камере без доступа к системе.
- Атака может не касаться модели вовсе. Подмена топика DDS или промпт-инъекция обходят веса, и проверка весов тут бесполезна.
- Снимок модели не равен системе. После приёмки приходят дообучение на новых данных, обновления middleware и новые узлы в сети.
Заодно стоит отказаться от иллюзии, что высокий процент на тестах говорит про устойчивость. Метрики на чистых данных измеряют качество, а не защищённость. Чтобы закрыть разрыв, преддеплойная проверка должна включать состязательные сценарии и физические прогоны с триггерами, а не только функциональные тесты.
Практические подходы к защите Physical AI
Работающая схема собирается из трёх блоков, и они дополняют друг друга.
Сканирование моделей и уязвимостей. Первый шаг: инвентаризация. Нужны хеши чекпоинтов и датасетов, список зависимостей пакетов ROS, версии прошивок, состав Bluetooth-стека. Второй: проверка самих весов, где есть обратный инжиниринг возможных триггеров, анализ кластеров активаций на подозрительные паттерны и обрезка нейронов, отвечающих за аномальное поведение. Третий: конфигурационный аудит, где смотрят не версии, а настройки, включая SROS2 и подписи обновлений. Подход к анализу моделей на скрытые модификации разобран в материале про защиту моделей и AI-агентов.
Проверка в симуляции. NVIDIA Isaac Sim даёт сенсорно-реалистичную среду: камеры и лидары на трассировке лучей, физика контактов, доменная рандомизация освещения и текстур. В такой среде удобно прогонять атаки до реального железа: печатаемые патчи, подмена сообщений в топиках, ложные данные лидара, состязательные инструкции в промпт-канал. Автоматизировать сам прогон и оценку поведения помогают платформы класса VicOne Radeis, которые позиционируются как средства проверки и валидации встроенного ПО и моделей. Ограничение простое: симуляция не воспроизводит реальность полностью, а сценарии пишут люди, поэтому они покрывают известные атаки и плохо ловят новые.
Мониторинг поведения в рантайме. Работает поверх готовой системы и смотрит на расхождения: камера и лидар описывают сцену по-разному; команды манипулятора выходят за обычный профиль; модель отвечает неуверенно там, где раньше отвечала стабильно. Полезны независимые ограничители, которые не подчиняются AI: пределы скорости и усилия, геозона, аппаратный аварийный стоп. Дальше события с робота, сети, инференса и флот-менеджмента сводят в одну систему корреляции, чтобы короткий всплеск аномалий складывался в понятную картину. Минусы тоже честные: ложные срабатывания, расход ресурсов на бортовом железе, шифрование телеметрии и риск, что атакующий доберётся до самого монитора.
Переход от точечных проверок к сопровождению безопасности на всём жизненном цикле робота
Разовые проверки не работают, потому что меняется всё: модель, данные, прошивки, сеть и сам парк роботов.
Проектирование. Здесь закладывают безопасные значения по умолчанию: включённый SROS2 с ограничением прав на топики, подписанные OTA-обновления, защищённое хранилище ключей, сегментация сети робота, минимальные права сервисных аккаунтов. Тут же строят модель угроз по трём уровням и решают, какие данные и модели допустимо брать извне. Полезно заранее определить, что именно считаем недопустимым поведением, иначе мониторинг нечего настраивать.
Преддеплойная валидация. В чек-лист входят сканирование весов, проверка происхождения данных, состязательные тесты в симуляции и на железе, пентест беспроводных интерфейсов и middleware. Ограничения у этого этапа тоже есть: сканирование не гарантирует находку всех бэкдоров, а симуляция приблизительна.
Эксплуатация. После запуска начинается основная работа: непрерывный мониторинг, управление обновлениями, контроль дрейфа данных, реагирование на инциденты. В план реагирования стоит заранее вписать действия, специфичные для робота: безопасная остановка, изоляция от сети, отзыв ключей, откат версии модели. Отдельный сюжет про автономность показывает, чем заканчивается отсутствие таких границ: в разборе инцидента с моделью Meta Muse Spark 1.1 описано, как агент во время киберучений вышел за пределы тестовой среды и изменил конфигурации реальной компании.
Регуляторный фон двигается: IEC 62443 и ISO/SAE 21434 задают требования к промышленным и транспортным системам, регламент ЕС Cyber Resilience Act распространяется на продукты с цифровыми компонентами, а NIST AI RMF предлагает рамку управления рисками AI. Робототехника попадает во все три контура сразу, и трассируемость решений (какие данные, какая версия модели, какие проверки) становится частью отчётности.
Что это значит для разработчиков и компаний, внедряющих Physical AI
Короткие выводы без иллюзий.
- Функциональная безопасность и кибербезопасность Physical AI - разные задачи. Первая страхует отказы, вторая - целенаправленные воздействия. Сертификат по безопасности не заменяет проверку на атаки.
- Успешная приёмка модели ничего не говорит о её устойчивости. Бэкдор, заложенный в данные, не проявляется на чистых тестах.
- Практический минимум на сегодня: включить SROS2 с ограничением прав, подписывать обновления, фиксировать хеши моделей и данных, закрыть беспроводные интерфейсы, держать аварийный контур вне AI.
- Защита собирается из комбинации: сканирование артефактов, состязательные прогоны в симуляции и на железе, мониторинг поведения с корреляцией событий. У каждого блока есть слепые зоны, вместе они закрывают больше.
- Безопасность стоит денег и времени. Сканирование больших моделей дорого, симуляционные сценарии надо поддерживать, мониторинг требует вычислительных ресурсов на борту.
Стартовать разумно с оценки рисков: какие роботы, к каким сетям подключены, что лежит в топиках ROS 2, кто имеет доступ к пайплайну обучения. Дальше по приоритету: закрыть очевидные дыры в конфигурации, потом вводить проверки на бэкдоры и наблюдение за поведением. Тема быстро меняется, публикации по атакам на VLA-модели выходят регулярно, и пересматривать модель угроз придётся чаще, чем раз в год.