Идентичность ИИ-агента: разрешения, аудит и подтверждение инструментов

Зачем агенту действующая идентичность до вызова инструмента

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

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

В рекомендациях NVIDIA по управлению автономными агентами идентичность, политика, проверка, централизованные журналы, отзыв доступа и непрерывная верификация рассматриваются как отдельные элементы управления. Для телефона это переводится на простой язык: вход в аккаунт подтверждает, кто пользователь, но не объясняет, что именно пользователь делегировал агенту. Команда «подготовь ответ» не равна праву читать все будущие сообщения или отправлять их без дополнительного выбора.

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

Как превратить идентичность в ограниченные и отзывные разрешения

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

Такая цепочка полезнее, чем один большой доступ. Агент может иметь право читать видимый экран для текущей задачи, но не право отправлять сообщение. Он может подготовить черновик, но остановиться перед публикацией. Он может запустить приложение, но не менять чувствительную настройку без проверки. Если объем полномочий меняется, например пользователь выбирает другого получателя или приложение показывает новый запрос, агент должен вернуться к политике и контексту, а не расширять полномочия молча.

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

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

Что решать и записывать на границе вызова инструмента

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

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

Критично записывать не только успехи. Отказ политики важен: он показывает, что контроль работает. Отмена пользователем важна: она подтверждает, что у человека был выбор. Ошибка Android-разрешения важна: она помогает восстановить сценарий без угадывания. Частичный результат важен: например, приложение открылось, но сообщение не отправлено. Если в журнале есть только «агент выполнил задачу», он бесполезен для восстановления и доверия.

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

Корпоративная песочница и Android-контроль решают разные задачи

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

Референсный подход NVIDIA к управлению AI factories полезен как общий ориентир: интерфейс и управляемое исполнение разделяются, действия связываются с идентичностью, политикой, проверкой и отзывом доступа. Но переносить корпоративный VM-контроль на телефон дословно нельзя. Android не является корпоративной песочницей агента; это пользовательское устройство с приложениями, разрешениями и интерфейсами, где часть решений должна быть видимой человеку.

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

Как FoneClaw применяет глобальные режимы и настройки инструментов

Теперь перенесем управление в среду выполнения FoneClaw. FoneClaw — Android phone-agent runtime: настроенная совместимая модель помогает понять запрос и построить план, а FoneClaw вызывает поддерживаемые Android-инструменты в рамках политики. Мы не полагаемся на один промпт как на систему полномочий. Контроль строится вокруг режима подтверждения, включенности инструмента, оценки последствий, восстановления разрешений, видимых результатов и обработки неудачных состояний.

В FoneClaw есть три глобальных режима Tool Approval Mode. Auto approve подходит для сценариев, где пользователь осознанно хочет минимизировать паузы и уже сузил набор доступных инструментов. Follow tool policy использует политику инструмента: низкорисковые действия могут идти быстрее, а действия с внешним эффектом или повышенным риском требуют дополнительного подтверждения. Deny all нужен как жесткий стоп: инструменты не выполняются, пока пользователь не вернет другой режим.

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

В FoneClaw доступны 100+ встроенных инструментов для поддерживаемых действий Android: чтения экрана, управления устройством, коммуникаций, локации, workflow, навыков и plugin-сценариев. Подробнее о пользовательских возможностях мы собрали на странице функций FoneClaw. Важнее количества инструментов сама структура контроля: чтение экрана, системные действия, коммуникации и внешние эффекты имеют разные последствия, поэтому должны управляться по-разному. Встроенный инструмент и plugin также требуют разных путей доверия: первый входит в продуктовую среду FoneClaw, второй должен проходить отдельную установку и включение.

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

Практическая таблица подтверждений для действий телефона

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

Эта таблица помогает принять решение до настройки: что можно оставить на Follow tool policy, что отключить в настройках отдельного инструмента, где усилить подтверждение и где использовать Deny all во время теста. Если выбран Auto approve, особенно важно заранее сузить набор включенных инструментов и начать с низкорисковых сценариев.

Надежная политика также различает запланированное действие и наблюдаемый результат. Агент мог планировать открыть правильный контакт, но приложение показало похожее имя. Он мог подготовить сообщение, но отправка не состоялась. Он мог получить отказ Android-разрешения. Все это разные записи, а не один итог «ошибка». Чем точнее журнал, тем проще восстановиться без расширения полномочий.

Аудит, отзыв и восстановление после сбоя или смены полномочий

Управление не заканчивается в момент клика по подтверждению. После действия пользователю нужны аудит, отзыв доступа и восстановление. Аудит показывает, что было запрошено, какой инструмент выбран, какие разрешения использованы, что подтвердил человек, что выполнила среда выполнения и чем закончилась задача. Отзыв позволяет отключить инструмент, изменить режим подтверждения, отозвать Android-разрешение, завершить сессию, убрать учетные данные или остановить plugin-путь. Восстановление объясняет, как продолжить после отказа без тихого расширения полномочий.

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

Отзыв доступа должен быть многоуровневым. Иногда достаточно выключить один инструмент. Иногда нужно сменить глобальный режим на Deny all. В других случаях нужно отозвать Android-разрешение в настройках устройства, завершить модельную сессию, обновить API-учетные данные или отключить plugin. Эти действия не являются наказанием для агента; это нормальная эксплуатация системы, где объем полномочий меняется вместе с задачей.

Когда ресурсы или инструменты приходят из каталогов и механизмов обнаружения, проверка обнаружения и право выполнения также должны оставаться раздельными. Этот контекст раскрыт в статье Agentic Resource Discovery и доверие phone agent: почему каталог не равен разрешению. Для телефонного агента финальная проверка всегда ближе к устройству: кто действует, какой инструмент включен, какое Android-разрешение есть, что пользователь подтвердил и какой наблюдаемый результат попал в журнал.

Источники этого руководства: рекомендации NVIDIA по более безопасным AI-агентам и подход NVIDIA к управлению автономными агентами.