Безопасность навыков AI-агентов: почему телефону нужны проверки разрешений

Чистая проверка навыка еще не означает доверие

Главная ошибка в оценке AI-agent skills — считать, что прохождение сканера при установке равно безопасности. Пользователь видит аккуратное описание навыка, понятные команды и отсутствие тревожных сигналов в статической проверке. Но если вредоносная логика раскрывается позже, после запуска или при определенном контексте, такой осмотр может не увидеть реального поведения. Поэтому вопрос «безопасны ли навыки AI-агентов?» нельзя закрыть одним зеленым значком.

6 июля 2026 года The Hacker News сообщил о SkillCloak-подходе, где вредоносные навыки AI-агентов могут обходить статические сканеры за счет упаковки и раскрытия поведения позже: сообщение The Hacker News о SkillCloak. Это нужно читать как важный сигнал, а не как повод объявлять все навыки опасными. Смысл в другом: install-time проверка смотрит на внешний вид и код до выполнения, а риск может проявиться уже в процессе работы.

Архитектурный вывод простой: доверять нужно не только описанию навыка, но и его поведению. Если модуль обещает «помочь с календарем», важно проверить, не пытается ли он читать лишние файлы, отправлять данные наружу, запускать непрошеные действия или менять параметры телефона. Для phone AI agent это особенно важно, потому что действие может перейти из текста в реальное изменение на устройстве.

Что нужно проверять во время работы агента

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

В preprint «Cloak and Detonate» исследователи описывают идею обхода сканеров и динамического обнаружения вредоносного поведения агентных навыков: arXiv preprint о Cloak and Detonate. Так как это preprint, результаты исследования нужно формулировать аккуратно: это данные авторов и исследовательская модель угроз, а не универсальная гарантия для всех платформ и всех агентов.

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

Почему телефонные разрешения повышают цену ошибки

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

OWASP GenAI Security Project выделяет категории риска вроде prompt injection, supply-chain vulnerabilities, insecure plugin design, excessive agency и sensitive information disclosure: OWASP Top 10 for LLM Applications. В контексте телефона это переводится на практический язык: навык не должен читать больше, чем нужно; агент не должен запускать действие без понятной причины; личные данные не должны уходить в другой сервис незаметно.

Android-разрешения тоже важно понимать правильно. Это не декоративные переключатели, а системные возможности с разной чувствительностью: уведомления, контакты, камера, микрофон, файлы, местоположение и другие области требуют разных уровней доверия. Android Developers описывает разрешения как управляемые системой возможности, которые пользователь может предоставить или отклонить: Android Developers о разрешениях. Поэтому разговор про облачный и локальный AI-агент должен включать не только место обработки, но и вопрос: какие телефонные данные вообще доступны навыку и зачем.

Практичная модель разрешений для телефонного AI-агента

Безопасная модель начинается с минимально нужного доступа. Навык, который помогает с календарем, не должен автоматически получать контакты, файлы и уведомления. Модуль, который готовит ответ, не должен отправлять сообщение без отдельного подтверждения. Агент, который объясняет настройки, не должен менять их молча. Это правило не новое для безопасности, но для AI-агентов оно становится критичным: модель может убедительно объяснить действие, даже если само действие слишком широкое.

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

Для компаний такие правила обычно входят в более широкую политику: инвентаризация инструментов, контроль доступа, журналирование, разделение сред, проверка поставщиков. Пользовательский телефон не должен копировать весь enterprise-процесс, но принципы похожи. Когда речь идет о корпоративных политиках, безопасность AI-агентов в компаниях шире, чем один запрос разрешения; на телефоне же нужны простые и понятные версии тех же идей: минимум доступа, подтверждение перед последствиями и история действий.

Чеклист для оценки навыков, плагинов и телефонных агентов

Оценивать навыки AI-агентов стоит спокойно, без паники. Первый вопрос: что навык обещает делать и какие данные ему реально нужны? Если модуль для заметок просит доступ к контактам, файлам, уведомлениям и внешней отправке данных, это повод остановиться. Второй вопрос: проверяется ли поведение только до установки или также во время работы? Третий: видит ли пользователь, какие действия навык пытается выполнить?

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

Еще один полезный признак — объяснимый отказ. Безопасный агент должен уметь сказать: «этот навык не получит доступ к уведомлениям», «отправка сообщения требует подтверждения», «действие не выполнено, потому что разрешение не предоставлено». Это не неудобство, а защита. Слишком гладкая автоматизация, которая никогда не показывает границ, часто менее надежна, чем система, честно объясняющая, где ей нельзя действовать.

Что это значит для FoneClaw

FoneClaw нельзя связывать с SkillCloak, The Hacker News, arXiv-авторами, OWASP, Android, Google, Claude Code, OpenAI Codex, OpenClaw или любыми security vendors. Правильная позиция проще: FoneClaw — независимый Android phone AI agent для поддерживаемых операций на телефоне. Он не должен обещать, что гарантирует безопасность, сканирует все сторонние навыки или контролирует каждое приложение.

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

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

Источники: The Hacker News о SkillCloak; arXiv preprint «Cloak and Detonate»; OWASP Top 10 for LLM Applications; Android Developers о разрешениях.