Агентные ассистенты: безопасные интеграции календаря и Gmail

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

ПРОЕКТИРОВАНИЕ РАЗРЕШЕНИЙ ДЛЯ АГЕНТНЫХ АССИСТЕНТОВ

Начните с OAuth на уровне пользователя и с минимального объема разрешений. Используйте OAuth, привязанный к пользователю, а не общий сервисный аккаунт, за исключением случаев, когда администратор явно требует делегирования домена. Документация Google по детализированным разрешениям, это базовый уровень; сопоставьте каждую возможность агента с одним объемом OAuth и задокументируйте понятие намерения для этого объема. Держите токены вне подсказок. Храните их в хранилище и вводите учетные данные только в момент вызова внутри сервиса выполнения, который обеспечивает соблюдение политики.

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

ПЛАНИРОВАНИЕ И ДЕЙСТВИЕ

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

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

ТЕСТЫ, ЖУРНАЛЫ И ВОССТАНОВЛЕНИЕ

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

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

КОНТРОЛЬНЫЙ СПИСОК ДЛЯ ПРОДУКТА И ИНЖЕНЕРИИ

1. OAuth на уровне пользователя с минимальными объемами и явным текстом согласия. 2. Хранилище токенов и сервис выполнения, который вводит учетные данные во время выполнения. 3. Разделение планировщика и исполнителя с проверками политик. 4. Эскалация с участием человека для чувствительных действий. 5. Неизменяемые журналы аудита и воспроизводимый формат действий. 6. Процессы отката и компенсации с четкими возможностями интерфейса.

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

Попробуйте сами. Подсказки ниже демонстрируют вывод планировщика и безопасные инструкции исполнителя. Ожидайте кратких планов в формате, похожем на JSON, от планировщика и короткие подтверждения от исполнителя.

Эта подсказка просит модель создать ограниченный план возможных временных слотов для встречи и обоснование; используйте его в качестве планировщика. Ожидайте 2-3 временных слота-кандидата и однострочное обоснование.

Вы планировщик встреч. У пользователя есть 3 свободных временных слота сегодня: 10:00, 14:30, 16:00. Верните ровно три возможных времени встречи в формате ISO с однострочным обоснованием для каждого и однострочной заметкой о конфиденциальности, указывающей, касается ли приглашение внешних электронных писем.

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

Исполнитель: при наличии токена подтверждения пользователя X и плана планировщика Y, вызовите Calendar.CreateEvent с полями {start,end,attendees,summary} только в том случае, если policy_check(policy_id:calendar_write) возвращает пас. Если policy_check не проходит, верните код ошибки и требуемое действие от человека.

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