Agentic assistenten: veilige integraties voor agenda en Gmail

Mijn bewering: het bouwen van veilige, gebruiksvriendelijke agentic assistenten die werken met agenda's, Gmail en verbonden apps vereist het ontwerpen van een permission-first runtime, het scheiden van plannen van handelen, en het integreren van audit- en terugrolflows in de uitvoeringslaag vanaf de eerste dag. Dit artikel biedt een strikte engineering checklist en uitvoerbare prompts om daar te komen.

PERMISSIEONTWERP VOOR AGENTIC ASSISTENTEN

Begin met per-gebruiker OAuth en least-privilege scopes. Gebruik gebruikerseigen OAuth in plaats van een gedeeld serviceaccount, behalve wanneer een beheerder expliciet domeindelegatie vereist. De documentatie van Google over granular scopes is de basislijn; koppel elke agentcapaciteit aan een enkele OAuth-scope en documenteer de voor mensen leesbare intentie voor die scope. Houd tokens uit prompts. Bewaar ze in een kluis en injecteer inloggegevens alleen op call-tijd binnen een uitvoeringsservice die het beleid afdwingt.

We hebben geobserveerd dat teams die toestemming behandelen als product-UX, met duidelijke toestemmingsschermen en scope-voorbeelden, veel minder support tickets krijgen. Een probleem dat we tegenkwamen is token proliferatie door naïeve verversingslogica; centraliseer verversing en draai verversingstokens regelmatig.

PLANNEN TEGEN HANDHAVEN

Splits de assistent in een planner en een actuator. De planner produceert een discrete actieplan: lees recente threads, stel twee vergadertijden voor, stel een concept-e-mail op. De actuator voert alleen uit na een beleidcontrole en, voor gevoelige acties, een menselijke bevestigingsstap. Dit patroon voorkomt dat het model improviserend bevoegde operaties uitvoert en maakt autorisatie controleerbaar.

Praktische afweging: langere latentie voor menselijke goedkeuring versus lager risico. Voor veel agenda- en e-mailacties is een pauze van 30 tot 60 seconden met een mens in de lus acceptabel. Voor taken met een hoge frequentie werken batchgoedkeuringen beter dan per-actie klikken.

TESTEN, LOGS EN HERSTEL

Iedere actie moet een onveranderlijke auditentry produceren met de gevraagde intentie, de uitvoer van de planner, de beleidsbeslissing, de actoroproep en de geretourneerde API-reactie. Houd een herhaalbare opdrachtindeling zodat je kunt terugspelen en terugrollen. Bied een een-click intrekking voor de laatste N acties en een herstelflow die compenserende gebeurtenissen creëert, bijvoorbeeld het annuleren van een evenement en het verzenden van een corrigerende opvolging.

We hebben geobserveerd dat promptniveau guardrails falen zonder een externe beleidsengine. In de praktijk zullen modellen wijzigingen voorstellen die er plausibel uitzien maar het beleid schenden. Een uitvoeringspoort die elke schrijfactie weigert wanneer het vertrouwen onder een gekalibreerde drempel ligt, vermindert deze incidenten.

CHECKLIST VOOR PRODUCT EN ENGINEERING

1. Per-gebruiker OAuth met minimale scopes en expliciete toestemmings tekst. 2. Tokenkluis en uitvoeringsservice die inloggegevens injecteert tijdens runtime. 3. Scheiding van planner/actor met beleidcontroles. 4. Mens-in-de-lus escalatie voor gevoelige acties. 5. Onveranderlijke auditlogs en herhaalbare actievorm. 6. Terugrol- en compenserende flows met duidelijke UI-voorzieningen.

Koppel product-UX aan de werkpatronen die zijn beschreven in Designing human-AI workflows en gebruik de primer over agentverschillen in AI agents vs chatbots om de scheiding tussen planner en actuator te rechtvaardigen.

Probeer het zelf. De prompts hieronder demonstreren de uitvoer van de planner tegen actuator-veilige instructies. Verwacht beknopte JSON-achtige plannen van de planner en korte bevestigingen van de actuator.

Deze prompt vraagt het model om een beperkte planning van mogelijke vergadertijden en een verklaring; gebruik het als de planner. Verwacht 2 tot 3 mogelijke tijdslots en een zin als verklaring.

Je bent een vergaderplanner. Gebruiker heeft 3 vrije slots vandaag: 10:00 AM, 2:30 PM, 4:00 PM. Geef precies drie kandidaat vergadertijden in ISO-formaat terug met één regel verklaring voor elk, en een privacyopmerking van één regel waarin staat of de uitnodiging externe e-mails aanraakt.

Deze prompt is voor de actuator. Het verwacht een menselijke bevestigingstoken en een expliciete beleidscheck voordat het evenement wordt gemaakt.

Actuator: gegeven gebruikersbevestigingstoken X en plannerplan Y, bel de Calendar.CreateEvent aan met velden {start,eind,deelnemers,samenvatting} alleen als policy_check(policy_id:calendar_write) pass retourneert. Als policy_check faalt, retourneer de foutcode en de menselijke actie die vereist is.

Een tegenargument is dat strikte controles de acceptatie vertragen. Mijn schatting is dat wanneer teams deze patronen afdwingen, de vroege gebruikersretentie verbetert omdat het vertrouwen groeit, zelfs als de initiële activatie trager is. De afweging is duidelijk: snellere implementatie zonder deze controles creëert meetbaar risico en hogere herstelkosten.