Agentiske assistenter: sikre integrasjoner med kalender og Gmail

Min påstand: å bygge sikre, brukervennlige agentiske assistenter som fungerer på kalendere, Gmail og tilkoblede apper krever utforming av en tillatelses-første kjøreflate, separering av planlegging fra handling, og innbygging av revisjons- og tilbakestillingsflyter i utførelseslaget fra dag én. Denne artikkelen gir en stram ingeniør-sjekkliste og kjørbare kommandoer for å nå dit.

TILLATELSESDESIGN FOR AGENTISKE ASSISTENTER

Start med per-bruker OAuth og minst privilegierte omfang. Bruk bruker-bindende OAuth i stedet for en delt tjenestekonto, med mindre en administrator uttrykkelig krever domenedelegering. Googles dokumentasjon om granulære omfang er grunnlaget; kartlegg hver agentkapasitet til et enkelt OAuth-omfang og dokumenter den menneskelig lesbare intensjonen for det omfanget. Hold tokens ute av kommandoene. Lagr dem i et depot og injiser legitimasjoner kun ved anropstidspunktet i en utførelsestjeneste som håndhever policy.

Vi har observert at team som behandler tillatelser som produktbrukeropplevelse, med klare samtykkeskjermer og omfangsforhåndsvisninger, får langt færre supporthenvendelser. Et problem vi støtte på er token-proliferasjon fra naiv oppdateringslogikk; sentraliser oppdatering og roter oppdateringstokens regelmessig.

PLANLEGGING VERSUS HANDLING

Del assistenten inn i en planlegger og en aktuator. Planleggeren produserer en distinkt handlingsplan: les nylige tråder, foreslå to møtetidspunkter, komponer et utkast til e-post. Aktuatoren utfører kun etter en policy-sjekk og, for sensitive handlinger, et menneskelig bekreftelsestrinn. Dette mønsteret holder modellen fra å improvisere privilegerte operasjoner og gjør autorisasjon reviderbar.

Praktisk avveining: lengre ventetid for menneskelig godkjenning versus lavere risiko. For mange kalender- og e-posthandlinger er en pause med menneskelig involvering på 30 til 60 sekunder akseptabel. For høyfrekvente oppgaver fungerer batch-godkjenninger bedre enn per-handling klikk.

TESTER, LOGGER OG GJENOPPRETTING

Hver handling må produsere en uforanderlig revisjonsoppføring som inneholder den forespurte intensjonen, planleggerens utdata, policybeslutningen, aktøranropet og det returnerte API-svaret. Hold et gjenspillbart kommandoformat slik at du kan gjenspille og tilbakestille. Gi en ett-klikk tilbakekalling for de siste N handlingene og en gjenopprettingsflyt som lager kompenserende hendelser, for eksempel å kansellere et arrangement og sende en korrigerende oppfølging.

Vi har observert at kommando-nivå guardrails mislykkes uten en ekstern policy-motor. I praksis vil modeller foreslå endringer som ser plausible ut, men bryter policy. En utførelsesport som nekter enhver skriveoperasjon når tilliten er under en kalibrert terskel, reduserer disse hendelsene.

SJEKKLISTE FOR PRODUKT OG INGENIØRER

1. Per-bruker OAuth med minimale omfang og eksplisitt samtykketekst. 2. Token-depot og utførelsestjeneste som injiserer legitimasjoner ved kjøretid. 3. Separasjon av planlegger/aktuator med policy-sjekker. 4. Menneskelig-involvering opptrapping for sensitive handlinger. 5. Uforanderlige revisjonslogger og gjenspillbart handlingsformat. 6. Tilbakestillings- og kompenseringsflyter med klare UI-funksjoner.

Knytt produktbrukeropplevelsen til arbeidsflytmønstrene beskrevet i Designing human-AI workflows og bruk primen om agentforskjeller i AI agents vs chatbots for å rettferdiggjøre separasjonen mellom planlegger og aktuator.

Prøv det selv. Kommandoene nedenfor demonstrerer planleggerens utdata versus aktuatorens sikre instruksjoner. Forvent kortfattede, JSON-lignende planer fra planleggeren og korte bekreftelser fra aktuator.

Denne kommandoen ber modellen om å produsere en begrenset plan med kandidatmøtetidspunkter og en begrunnelse; bruk den som planlegger. Forvent 2 til 3 kandidat-tidsluker og en setning som gir en begrunnelse.

Du er en møteleder. Bruker har 3 ledige tidsluker i dag: 10:00, 14:30, 16:00. Returner nøyaktig tre kandidat-møtetidspunkt i ISO-format med en-setnings begrunnelse for hver, og en-setning personvernote som sier om invitasjonen berører eksterne e-poster.

Denne kommandoen er for aktuatoren. Den forventer et menneskelig bekreftelsestoken og en eksplisitt policy-sjekk før opprettelse av arrangementet.

Aktuator: gitt brukerbekreftelsestoken X og planleggerplan Y, kall Calendar.CreateEvent med felt {start,end,attendees,summary} kun hvis policy_check(policy_id:calendar_write) returnerer bestått. Hvis policy_check mislykkes, returner feilkoden og menneskelig handling som kreves.

En motargument er at strenge kontroller forsinker adopsjon. Min vurdering er at når team håndhever disse mønstrene, forbedres tidlig brukerretensjon fordi tilliten vokser, selv om den innledende aktiveringen er tregere. Avveiningen er klar: raskere utrulling uten disse kontrollene skaper målbar risiko og høyere kostnader for utbedring.