Agentiska assistenter: säkra integrationer med kalender och Gmail

Min påstående: att bygga säkra, användarvänliga agentiska assistenter som agerar på kalendrar, Gmail och kopplade appar kräver att man designar en tillstånds-först körmiljö, separerar planering från utförande och integrerar granskning och återställningsflöden i exekveringsskiktet från dag ett. Denna artikel ger en kompakt teknikchecklista och körbara prompts för att nå dit.

TILLSTÅNDSDESIGN FÖR AGENTISKA ASSISTENTER

Börja med per-användare OAuth och minimala åtkomsträttigheter. Använd användarbunden OAuth istället för ett delat tjänstekonto, utom när en administratör uttryckligen kräver domändelegation. Googles dokumentation om granulerade åtkomsträttigheter är baslinjen; mappa varje agentkapabilitet till en enskild OAuth-omfattning och dokumentera den mänskligt läsbara avsikten för den omfattningen. Håll tokens utanför prompts. Lagra dem i ett valv och injicera legitimationer endast vid anropstid inuti en exekveringstjänst som verkställer policyn.

Vi observerade att team som behandlar behörigheter som produkt UX, med tydliga samtyckesskärmar och omfattningsförhandsvisningar, får betydligt färre supportärenden. Ett problem vi stötte på är token-proliferation från naiv uppdateringslogik; centralisera uppdatering och rotera uppdateringstokens regelbundet.

PLANERING VERSUS UTFÖRANDE

Dela assistenten i en planerare och en aktör. Planeraren producerar en diskret handlingsplan: läs senaste trådar, föreslå två mötestider, skriv ett utkast till e-post. Aktören utför endast efter en policykontroll och, för känsliga åtgärder, ett mänskligt bekräftelsesteget. Detta mönster hindrar modellen från att improvisera privilegierade operationer och gör auktorisering redo för granskning.

Praktisk avvägning: längre latens för mänskligt godkännande kontra lägre risk. För många kalender- och e-poståtgärder är en paus på 30 till 60 sekunder för mänsklig insyn acceptabel. För högfrekventa uppgifter fungerar batchgodkännanden bättre än åtgärdsbaserade klick.

TESTER, LOGGAR OCH ÅTERSTÄLLNING

Varje åtgärd måste producera en oföränderlig revisionspost som innehåller den begärda avsikten, planerarenoutdata, policydomen, aktörens anrop och det returnerade API-svaret. Håll ett uppspelningsbart kommandformat så att du kan återspela och återställa. Tillhandahåll en engångsrubb för de senaste N-åtgärderna och ett återställningsflöde som skapar kompenserande händelser, till exempel att avboka en händelse och skicka en korrigerande uppföljning.

Vi observerade att prompts-nivå skydd inte fungerar utan en extern policy-motor. I praktiken kommer modeller att föreslå förändringar som verkar rimliga men bryter mot policyn. En exekveringsport som vägrar alla skrivningar när förtroendet ligger under en kalibrerad tröskel minskar dessa incidenter.

CHECKLISTA FÖR PRODUKT OCH ENGENJÖRER

1. Per-användare OAuth med minimala omfattningar och tydlig samtyckestext.
2. Tokenvalv och exekveringstjänst som injicerar legitimationer vid körning.
3. Separation mellan planerare/aktör med policytillsyn.
4. Mänsklig insyn för känsliga åtgärder.
5. Oföränderliga revisionsloggar och uppspelningsbart åtgärdsformat.
6. Återställnings- och kompenserande flöden med tydliga UI-möjligheter.

Koppla produkt UX till arbetsflödesmönstren som beskrivs i Designing human-AI workflows och använd primerna om agenternas skillnader i AI agents vs chatbots för att rättfärdiga separationen mellan planerare och aktör.

Prova själv. Prompts nedan demonstrerar planerare resultat kontra aktörens säkra instruktioner. Förvänta dig koncisa JSON-liknande planer från planeraren och korta bekräftelser från aktören.

Denna prompt ber modellen att producera en begränsad plan med kandidatmötestider och en motivering; använd den som planeraren. Förvänta dig 2 till 3 kandidatplatser och en mening som motivering.

Du är en mötesplanerare. Användare har 3 lediga tider idag: 10:00, 14:30, 16:00. Återvänd exakt tre kandidatmötestider i ISO-format med en rad motivering för varje, och en rad integritetsnotering som säger om inbjudan berör externa e-postmeddelanden.

Denna prompt är för aktören. Den förväntar sig en mänsklig bekräftelsetoken och en uttrycklig policykontroll innan händelsen skapas.

Aktör: givet användarens bekräftelsetoken X och planerare planen Y, anropa Calendar.CreateEvent med fälten {start, slut, deltagare, sammanfattning} endast om policy_check(policy_id:calendar_write) ger godkännande. Om policy_check misslyckas, returnera felkoden och mänsklig åtgärd som krävs.

Ett motargument är att strikta kontroller bromsar antagandet. Min uppskattning är att när team genomför dessa mönster förbättras tidig användarretention eftersom förtroendet växer, även om den initiala aktiveringen är långsammare. Avvägningen är tydlig: snabbare utrullning utan dessa kontroller skapar mätbar risk och högre återhämtningskostnader.