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

Моят аргумент: изграждането на безопасни, usable агентни асистенти, които действат в календарите, Gmail и свързаните приложения изисква проектиране на runtime с разрешения в основата, разделяне на планирането от действието и вграждане на потоци за одит и възстановяване в слоя на изпълнение от самото начало. Тази статия предоставя стегнат инженеринг списък и работещи команди, за да достигнете до там.

ДИЗАЙН НА РАЗРЕШЕНИЯ ЗА АГЕНТНИ АСИСТЕНТИ

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

Забелязахме, че екипите, които третират разрешенията като UX на продукта, с ясни екрани за съгласие и прегледи на обхвата, получават много по-малко заявки за поддръжка. Един проблем, с който се сблъскахме, е разпространението на токени от наивна логика за обновление; централизирайте обновлението и редовно ротирайте обновяващите токени.

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

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

Практическа търговия: по-дълго закъснение за човешко одобрение срещу по-нисък риск. За много календарни и имейл действия времето за пауза от 30 до 60 секунди с участието на човек е приемливо. За задачи с висок принос, одобренията на партиди работят по-добре отколкото одобрения на всеки отделен клик.

ТЕСТОВЕ, ЛОГОВЕ И ВЪЗСТАНОВЯВАНЕ

Всяко действие трябва да генерира неизменяема одитна записка, съдържаща исканията за намерение, изхода на планировщика, решенията за политика, обаждането на актора и получените API отговори. Поддържайте формата на командата, който може да се възпроизвежда, така че да можете да я възпроизведете и върнете обратно. Осигурете еднократно отнемане за последните N действия и поток за възстановяване, който създава компенсаторни събития, например отменяне на събитие и изпращане на корекционен последващ имейл.

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

СПИСЪК ЗА ПРОДУКТА И ИНЖЕНЕРИНГА

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

Свържете UX на продукта с работните модели, описани в Проектиране на работни процеси между хора и AI, и използвайте наръчника за разликите между агентите в AI агенти спрямо чатботове, за да обосновете разделението на планиращ/изпълнител.

Опитайте сами. Командите по-долу демонстрират изхода на планираща срещу безопасни инструкции на изпълнителя. Очаквайте стегнати планове в 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. Ако проверката на политиката не успее, върнете кода за неуспеха и изискваното действие от човек.

Контрааргументът е, че строгите контролни мерки забавят приемането. Моята оценка е, че когато екипите налагат тези модели, ранната задържане на потребителите подобрява, защото доверието расте, дори и ако началната активация е по-бавна. Търговията е ясна: по-бързо внедряване без тези контролни мерки създава измерим риск и по-високи разходи за възстановяване.