Agentinės asistentai: saugios kalendoriaus ir Gmail integracijos

Mano teiginys: saugių, naudojamų agentinių asistentų, kurie veikia kalendoriuose, Gmail ir prijungtose programose, kūrimas reikalauja leisti pirmiausia teises, atskirti planavimą nuo veikimo ir nuo pirmos dienos integruoti audito bei grąžinimo srautus į vykdymo sluoksnį. Šiame straipsnyje pateikiama glausta inžinerinė kontrolinė lista ir vykdytini komandos, kad pasiekti šiuos tikslus.

LEIDIMŲ DIZAINAS AGENTINIAMS ASISTENTAMS

Pradėkite nuo individualaus OAuth ir mažiausių teisių apimčių. Naudokite OAuth, susietą su vartotoju, o ne dalijamąją paslaugų paskyrą, jei administratorius aiškiai nereikalauja domeno delegavimo. „Google“ dokumentacija apie granularias apimtis yra bazinis lygis; susiekite kiekvieną asistento funkciją su vienine OAuth apimtimi ir užfiksuokite that scope'o aiškiai skaitomą ketinimą. Laikykite tokenus už prompts. Saugojimas seife ir kredencialų injekcija tik iškvietimo metu vykdymo paslaugoje, kuri privalo laikytis politikos.

Pastebėjome, kad komandos, kurios traktuoja leidimus kaip produkto UX, su aiškiais sutikimo ekranais ir apimties peržiūromis, gauna žymiai mažiau palaikymo užklausų. Viena iš problemų, su kuria susidūrėme, yra tokenų proliferacija iš naivios atnaujinimo logikos; centralizuokite atnaujinimą ir reguliariai keiskite atnaujinimo tokenus.

PLANAVIMAS PRIEŠ VEIKIMĄ

Atskirkite asistentą į planuotoją ir vykdytoją. Planuotojas parengia atskirą veiksmų planą: perskaityti naujausias temas, pasiūlyti dvi susitikimo laikus, parašyti projekto el. laišką. Vykdytojas vykdo tik po politikos patikrinimo ir, jautriems veiksmams, žmogiškojo patvirtinimo žingsnio. Šis modelis neleidžia modeliui improvizuoti privilegijuotų operacijų ir daro autorizaciją audito galimybėmis.

Praktinis kompromisas: ilgesnis laukimo laikas žmogiškam patvirtinimui prieš mažesnį riziką. Daugeliui kalendoriaus ir el. pašto veiksmų 30-60 sekundžių žmonių įsikišimo pauzė yra priimtina. Didesnio darbo dažnio užduotims grupinės patvirtinimo procedūros veikia geriau nei veiksmų paspaudimai.

TESTAVIMAI, ŽURNALAI IR ATKŪRIMAS

Kiekvienas veiksmas turi sukurti nekintamą audito įrašą, kuriame yra prašomas ketinimas, planuotojo išvestis, politikos sprendimas, veikėjo iškvietimas ir grąžinta API atsakymas. Išlaikykite atkuriamą komandų formatą, kad galėtumėte pakartoti ir grąžinti atgal. Teikite vienu paspaudimu panaikinimą paskutiniams N veiksmams ir atkūrimo srautą, kuris sukuria kompensacinius įvykius, pavyzdžiui, atšaukiant įvykį ir siųsdami taisomąjį patvirtinimą.

Pastebėjome, kad prompto lygio apsaugos priemonės nesugeba be išorės politikos variklio. Praktikoje modeliai pasiūlo įvykius, kurie atrodo galimi, tačiau pažeidžia politiką. Vykdymo vartai, kurie atsisako bet kokio rašymo, kai pasitikėjimo lygis yra žemiau kalibruoto slenksčio, sumažina šiuos incidentus.

PRODUKTO IR INŽINERIJOS KONTROLINĖ LISTA

1. Individualus OAuth su minimaliais apimtimis ir aiškiuoju sutikimo tekstu. 2. Tokenų seifas ir vykdymo paslauga, kuri injekciją kredencialų vykdymo metu. 3. Planuotojo/vykdytojo atskyrimas su politikos patikrinimais. 4. Žmogaus-in-the-loop eskalacija jautriems veiksmams. 5. Nekintami audito žurnalai ir atkuriamas veiksmų formatas. 6. Grąžinimo ir kompensavimo srautai su aiškiomis vartotojo sąsajos galimybėmis.

Susiekite produkto UX su darbo srautais, aprašytais Žmogaus-AI darbo srautų projektavime, ir naudokite pradinį agentų skirtumų aprašymą AI agentai prieš chatbot'us pagrįsti plokštelės/vykdytojo padalinį.

Išbandykite patys. Žemiau esantis keitimasis iliustruoja planuotojo išvestį ir vykdytojo saugias instrukcijas. Tikėtina, kad planuotojo pateiktos glaustos JSON formato planavimo ataskaitos ir trumpi patvirtinimai iš vykdytojo.

Šis promptas prašo modelio sukurti apribotą planą kandidato susitikimo laikams ir rationale; naudokite jį kaip planuotoją. Tikėkitės 2-3 kandidatų laikų ir viena sakinio rationale.

Jūs esate susitikimo planuotojas. Vartotojas šiandien turi 3 laisvas vietas: 10:00, 14:30, 16:00. Grąžinkite tiksliai tris kandidatų susitikimų laikus ISO formatu su vienas eilutės rationale už kiekvieną, ir vienos eilutės privatumo pastaba, ar kvietimas liečia išorinius el. paštus.

Šis promptas skirtas vykdytojui. Jis tikisi žmogiško patvirtinimo tokeno ir aiškaus politikos tikrinimo praeinamumo prieš kuriant renginį.

Vykdytojas: duoto vartotojo patvirtinimo token X ir planuotojo plano Y, iškvieskite Calendar.CreateEvent su laukais {start,end,attendees,summary} tik jei policy_check(policy_id:calendar_write) grąžina praeiti. Jei policy_check nepavyksta, grąžinkite nesėkmės kodą ir reikiamą žmogiškąjį veiksmą.

Prieštaravimas yra tas, kad griežtos kontrolės lėtina priėmimą. Mano vertinimas yra toks, kad kai komandos laikosi šių modelių, ankstyva naudotojo išlaikymo gerėja, nes pasitikėjimas auga, net jei pradiniam aktyvavimui prireikė daugiau laiko. Kompromisas aiškus: greitesnis diegimas be šių kontrolės priemonių sukelia išmatuojamą riziką ir didesnes taisymo išlaidas.