Агентні асистенти: безпечні інтеграції календаря та 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) повертає pass. Якщо policy_check не пройшла, поверніть код помилки та дії людини, які потрібні.

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