Agentní asistenti: bezpečné integrace kalendáře a Gmailu

Můj názor: budování bezpečných, použivatelných agentních asistentů, kteří pracují s kalendáři, Gmailem a propojenými aplikacemi, vyžaduje navrhování runtime s prioritou na oprávnění, oddělení plánování od jednání a zapracování auditních a návratových procesů do vrstvy provádění od prvního dne. Tento článek poskytuje úzký inženýrský checklist a spustitelné výzvy, jak toho dosáhnout.

NÁVRH OPRÁVNĚNÍ PRO AGENTNÍ ASISTENTY

Začněte s OAuth pro jednotlivé uživatele a oprávnění s minimálním přístupem. Použijte OAuth vázanou na uživatele místo sdíleného servisního účtu, pokud to správce výslovně nevyžaduje. Dokumentace Google o granulárních oprávněních je základem; namapujte každou schopnost agenta na jedno OAuth oprávnění a zdokumentujte lidsky čitelný záměr pro toto oprávnění. Držte tokeny mimo výzvy. Uložte je do trezoru a vkládejte přihlašovací údaje pouze v okamžiku volání uvnitř služby provádění, která vynucuje politiku.

Pozorovali jsme, že týmy, které se na oprávnění dívají jako na UX produktu, s jasnými obrazovkami souhlasu a náhledy oprávnění, dostávají mnohem méně vstupních tiketů. Jeden problém, který jsme zaznamenali, je proliferace tokenů z naivní logiky obnovení; centralizujte obnovu a pravidelně otáčejte obnovovacími tokeny.

PLÁNOVÁNÍ VERSUS JEDNÁNÍ

Rozdělte asistenta na plánovače a aktora. Plánovač produkuje diskrétní akční plán: číst nedávné vlákna, navrhnout dva termíny schůzky, sestavit koncept e-mailu. Aktor provádí akci až po kontrole politiky a pro citlivé akce je potřeba krok s lidským potvrzením. Tento vzor brání modelu v improvizaci privilegovaných operací a činí autorizaci auditovatelnou.

Praktický obchod: delší latence pro lidské schválení versus nižší riziko. U mnoha akcí v kalendáři a e-mailu je 30 až 60 sekundová pauza s lidmi v loopu přijatelná. Pro úkoly s vysokou frekvencí fungují hromadné schválení lépe než individualizované klikání.

TESTY, LOGY A OBNOVENÍ

Každá akce musí vytvořit neměnný auditní záznam obsahující požadovaný záměr, výstup plánovače, rozhodnutí politiky, zavolání aktora a navrácenou odpověď API. Držte formát příkazu, který lze přehrávat, abyste mohli akce znovu přehrát a vrátit zpět. Poskytněte jedno kliknutí pro zrušení posledních N akcí a proces obnovy, který vytváří kompenzační události, například zrušení události a odeslání korektivního následného kroku.

Pozorovali jsme, že stavební zábrany na úrovni výzev selhávají bez externího řídicího enginu. V praxi modely navrhují změny, které vypadají věrohodně, ale porušují politiku. Brána pro provedení, která odmítá jakékoliv zápisy, když je důvěra pod kalibrovaným prahem, snižuje tyto incidenty.

CHECKLIST PRO PRODUKT A INŽENÝRSTVÍ

1. OAuth pro jednotlivé uživatele s minimálními oprávněními a explicitním textem souhlasu. 2. Trezor pro tokeny a služba provádění, která vkládá přihlašovací údaje při běhu. 3. Oddělení plánovače/aktora s kontrolami politiky. 4. Eskalace s lidmi v loopu pro citlivé akce. 5. Neměnné auditní logy a formát akce, který lze přehrát. 6. Návratové a kompenzační procesy s jasnými uživatelskými rozhraními.

Spojte UX produktu s pracovními vzory popsanými v Navrhování pracovních postupů mezi lidmi a AI a použijte základní vzor odlišností agentů v AI agenti vs chatboti k ospravedlnění rozdělení plánovače/aktora.

Vyzkoušejte to sami. Výzvy níže ukazují výstup plánovače oproti bezpečným instrukcím aktora. Očekávejte stručné plány podobné JSON od plánovače a krátká potvrzení od aktora.

Tato výzva žádá model, aby vytvořil omezený plán kandidátských časů schůzky a odůvodnění; použijte ji jako plánovače. Očekávejte 2 až 3 kandidátské sloty a jednou větu odůvodnění.

Jste plánovač schůzek. Uživatel má dnes 3 volné sloty: 10:00, 14:30, 16:00. Vraťte přesně tři kandidátské časy schůzek v ISO formátu s jednou-liniovým odůvodněním pro každý, a jednou-liniovou poznámku o soukromí uvádějící, zda pozvánka obsahuje externí e-maily.

Tato výzva je určena pro aktora. Očekává token lidského potvrzení a explicitní kontrolu politiky před vytvořením události.

Aktor: s potvrzovacím tokenem uživatele X a plánem plánovače Y zavolejte Calendar.CreateEvent s poli {start,end,attendees,summary} pouze pokud policy_check(policy_id:calendar_write) vrátí úspěch. Pokud policy_check selže, vrátí kód selhání a požadovanou lidskou akci.

Protiargumentem je, že přísné kontroly zpomalují adopci. Můj odhad je, že když týmy vynucují tyto vzory, raná retenční uživatelů se zlepšuje, protože důvěra roste, i když počáteční aktivace je pomalejší. Obchod je jasný: rychlejší nasazení bez těchto kontrol vytváří měřitelné riziko a vyšší náklady na nápravu.