Agentiske assistenter: sikre integrationer med kalender og Gmail

Mit krav: at bygge sikre, brugervenlige agentiske assistenter, der handler på kalendere, Gmail og tilknyttede apps, kræver design af en tilladelses-første runtime, adskillelse af planlægning fra handling og indbygning af revisions- og tilbageførsel strømme i udførelseslaget fra dag ét. Denne artikel giver en kompakt ingeniør-checkliste og kørbare prompts for at nå dertil.

TILLADELSESDESIGN FOR AGENTISKE ASSISTENTER

Start med per-bruger OAuth og mindst mulige scopes. Brug bruger-bundet OAuth fremfor en delt servicekonto, undtagen når en administrator eksplicit kræver domæne-delegation. Googles dokumentation om granulerede scopes er basislinjen; kortlæg hver agentkapacitet til en enkelt OAuth scope og dokumenter den menneskeligt læselige hensigt for den scope. Hold tokens ude af prompts. Opbevar dem i et vault og injicer legitimationsoplysninger kun ved kaldtid inden i en udførelsesservice, der håndhæver politik.

Vi har observeret, at teams, der behandler tilladelser som produkt-UX, med klare samtykkeskærme og scope-forhåndsvisninger, får langt færre supportbilletter. Ét problem, vi stødte på, er token-proliferation fra naiv opdateringslogik; centraliser opdatering og rotér opdateringstokens regelmæssigt.

PLANLÆGNING MOD HANDLING

Del assistenten op i en planner og en aktør. Planneren producerer en konkret handlingsplan: læs nylige tråde, foreslå to mødetidspunkter, sammensæt en kladde til e-mail. Aktøren udfører kun efter en politikcheck og, for følsomme handlinger, en menneskelig bekræftelsestrin. Dette mønster forhindrer modellen i at improvisere privilegerede operationer og gør godkendelse reviderbar.

Praktisk afvejning: længere ventetid for menneskelig godkendelse kontra lavere risiko. For mange kalender- og e-mailhandlinger er et 30 til 60 sekunders menneskelig-in-loop-pause acceptabelt. For højfrekvente opgaver fungerer batch-godkendelser bedre end per-handling klik.

TESTER, LOGFILER OG GENSKABELSE

Hver handling skal producere en uforanderlig revisionspost, der indeholder den anmodede hensigt, planner output, politikbeslutning, aktør kald og den returnerede API-respons. Hold et afspilningsbart kommand Format, så du kan afspille og rulle tilbage. Giv en enkelt klik tilbagekaldelse for de sidste N handlinger og et genskabelsesforløb, der skaber kompenserende begivenheder, for eksempel at annullere en begivenhed og sende en korrigerende opfølgning.

Vi har observeret, at prompt-niveau guardrails fejler uden en ekstern politikmotor. I praksis vil modeller foreslå ændringer, der ser plausible ud, men overtræder politik. En udførelsesport, der nægter enhver skrivning, når tillid er under en kalibreret tærskel, reducerer disse hændelser.

CHECKLISTE FOR PRODUKT OG INGENIØR

1. Per-bruger OAuth med minimale scopes og eksplicit samtykketekst. 2. Token vault og udførelsesservice, der injicerer legitimationsoplysninger ved runtime. 3. Planner/aktør adskillelse med politikchecks. 4. Menneske-i-loop-eskalering for følsomme handlinger. 5. Uforanderlige revisionslogger og afspilningsbart handlingsformat. 6. Tilbagetrækning og kompenserende strømme med klare UI-faciliteter.

Link produkt-UX til arbejdsgangsmønstrene beskrevet i Designing human-AI workflows og brug introduktionen til agentforskelle i AI agents vs chatbots til at retfærdiggøre planer/aktør-opdelingen.

Prøv det selv. Prompterne nedenfor demonstrerer planner output mod aktør-sikre instruktioner. Forvent korte JSON-lignende planer fra planner og korte bekræftelser fra aktør.

Denne prompt beder modellen om at producere en begrænset plan for kandidatmødetidspunkter og en begrundelse; brug den som planner. Forvent 2 til 3 kandidatslots og en-sætnings begrundelse.

Du er en mødeplanlægger. Bruger har 3 ledige slots i dag: 10:00 AM, 2:30 PM, 4:00 PM. Returnér præcist tre kandidat mødetidspunkter i ISO-format med en linjes begrundelse for hver, og en linjes privatlivsnotat, der siger, om invitationen berører eksterne e-mails.

Denne prompt er til aktøren. Den forventer et menneske-bekræftelsestoken og et eksplicit politik-check godkendelse før oprettelse af begivenheden.

Aktør: givet brugerbekræftelsestoken X og planner plan Y, kald Calendar.CreateEvent med felter {start,end,attendees,summary} kun hvis policy_check(policy_id:calendar_write) returnerer bestået. Hvis policy_check fejler, returner fejlkoden og den menneskelige handling der kræves.

Et modargument er, at strenge kontroller hæmmer adoption. Mit estimat er, at når teams håndhæver disse mønstre, forbedres tidlig brugerretention, fordi tillid vokser, selvom den indledende aktivering er langsommere. Afvejningen er klar: hurtigere udrulning uden disse kontroller skaber målbar risiko og højere omkostninger ved genoprettelse.