Agentické asistenti: bezpečné integrácie kalendára a Gmailu

Môj názor: budovanie bezpečných, použiteľných agentických asistentov, ktorí interagujú s kalendármi, Gmailom a pripojenými aplikáciami, si vyžaduje navrhnúť runtime so zameraním na povolenia, oddeliť plánovanie od konania a integrovať auditné a reverzné toky od prvého dňa do vykonávacej vrstvy. Tento článok poskytuje presný inžiniersky kontrolný zoznam a spustiteľné výzvy na dosiahnutie tohto cieľa.

NÁVRH POVOLENÍ PRE AGENTICKÝCH ASISTENTOV

Začnite s OAuth pre každého používateľa a minimálnymi rozsahmi práv. Používajte OAuth viazaný na používateľa miesto zdieľaného servisného účtu, pokiaľ správca výslovne nevyžaduje delegáciu domény. Google dokumentácia o jemne rozlíšených rozsahoch je miery; mapujte každú schopnosť agenta na jeden OAuth rozsah a zdokumentujte čitateľný zámer pre tento rozsah. Uchovávajte tokeny mimo výziev. Uložte ich do trezora a injikujte ich len v čase volania v rámci vykonávacej služby, ktorá vynucuje politiku.

Pozorovali sme, že tímy, ktoré sa zaoberajú povoleniami ako UX produktu, s jasnými obrazovkami súhlasu a náhľadmi rozsahu, dostávajú oveľa menej podporných tiketov. Jeden problém, ktorému sme čelili, je proliferácia tokenov z naivnej logiky osvieženia; centralizujte refresh a pravidelne otáčajte refresh tokeny.

PLÁNOVANIE VERSUS KONANIE

Rozdeľte asistenta na plánovača a vykonávateľa. Plánovač vytvára diskrétny akčný plán: prečítajte si nedávne vlákna, navrhnite dve termíny stretnutí, vypracujte návrh emailu. Vykonávateľ vykonáva akciu až po kontrole politiky a, pre citlivé akcie, po kroku potvrdenia človekom. Tento vzor zabraňuje modelu improvizovať privilégiované operácie a robí autorizáciu auditovateľnou.

Praktická obchodná bilancia: dlhšia latencia pre schválenie od človeka verzus nižšie riziko. Pre mnohé akcie kalendára a emailu je akceptovateľná 30 až 60 sekundová prestávka s človekom v procese. Pre úlohy s vysokou frekvenciou fungujú hromadné schválenia lepšie ako kliknutia na jednotlivé akcie.

TESTY, ZÁZNAMY A OBNOVA

Každá akcia musí vytvoriť nemenný auditný záznam obsahujúci požadovaný zámer, výstup plánovača, rozhodnutie politiky, volanie vykonávateľa a vrátenú API odpoveď. Uchovávajte opakovateľný formát príkazov, aby ste mohli opakovať a zvrátiť akciu. Poskytnite jednoklikovú možnosť zrušenia pre posledné N akcií a tok obnovy, ktorý vytvára kompenzačné udalosti, napríklad zrušenie udalosti a zaslanie opravných následných správ.

Pozorovali sme, že strážne mechanizmy na úrovni výziev zlyhávajú bez externého politikového enginu. V praxi modely navrhujú zmeny, ktoré sa zdajú byť plausibilné, ale porušujú politiku. Vykonávací brána, ktorá odmieta akékoľvek zápisy, keď je dôvera pod kalibrovaným prahom, znižuje tieto incidenty.

KONTROLNÝ ZOZNAM PRE PRODUKT A INŽINIERSTVO

1. OAuth pre každého používateľa s minimálnymi rozsahmi a explicitným textom súhlasu. 2. Trezor tokenov a vykonávacia služba, ktorá injikujem poverenia v čase behu. 3. Oddelenie plánovača/vykonávateľa s kontrolami politiky. 4. Postup eskalácie s človekom pre citlivé akcie. 5. Nemenné auditné záznamy a opakovateľný formát akcií. 6. Reverzné a kompenzačné toky s jasnými užívateľskými rozhraním.

Prepojte UX produktu s pracovnými vzormi popísanými v Návrh human-AI pracovných tokov a použite základný dokument o rozdieloch agentov v AI agenti vs chatboti na obhajobu rozdelenia plánovača/vykonávateľa.

Vyskúšajte to sami. Následujúce výzvy demonštrujú výstup plánovača oproti bezpečným inštrukciám vykonávateľa. Očakávajte stručné plány v podobe JSON od plánovača a krátke potvrdenia od vykonávateľa.

Táto výzva žiada model, aby vytvoril obmedzený plán kandidátskych termínov stretnutí a zdôvodnenie; používajte to ako plánovača. Očakávajte 2 až 3 kandidátske sloty a jednozdrovnické zdôvodnenie.

Ste plánovač stretnutí. Používateľ má dnes 3 voľné sloty: 10:00, 14:30, 16:00. Vráťte presne tri kandidátske termíny stretnutí v ISO formáte s jednodňovým odôvodnením pre každý a jedným riadkom poznámky o súkromí, ktorá hovorí, či pozvánka zasahuje vonkajšie emaily.

Táto výzva je pre vykonávateľa. Očakáva token potvrdenia od človeka a explicitný prechod cez kontrolu politiky pred vytvorením udalosti.

Vykonávateľ: ak je token potvrdenia používateľa X a plán plánovača Y, zavolajte Calendar.CreateEvent s poliami {start,end,attendees,summary} len vtedy, ak policy_check(policy_id:calendar_write) vráti povolenie. Ak policy_check zlyhá, vráťte kód zlyhania a požadovanú akciu od človeka.

Protiargument spočíva v tom, že prísne kontrola spomaľuje prijatie. Môj odhad je, že keď tímy vynucujú tieto vzory, skoré udržanie používateľov sa zlepšuje, pretože dôvera rastie, aj keď počiatočná aktivácia je pomalšia. Obchodná bilancia je jasná: rýchlejší rollout bez týchto kontrol vytvára merateľné riziko a vyššie náklady na nápravu.