Agyagos asszisztensek: biztonságos naptár és Gmail integráció

A kijelentésem: a biztonságos, használható agyagos asszisztensek létrehozása, amelyek naptárakra, Gmailre és csatlakoztatott alkalmazásokra hatnak, megköveteli egy engedély-első futtatási környezet megtervezését, a tervezés és a cselekvés szétválasztását, valamint a nyomozási és visszaállítási folyamatok beépítését az végrehajtási rétegbe a kezdetektől fogva. Ez a cikk egy tömör mérnöki ellenőrzőlistát és futtatható előírásokat ad meg ehhez.

ENGEDÉLYEZÉS TERVEZÉSE AGYAGOS ASSZISZTENSEK SZÁMÁRA

Kezdjük per felhasználói OAuth és a legkevésbé privát hatókörökkel. Használj felhasználóhoz kötött OAuth-t, nem osztott szolgáltatásfiókot, kivéve, ha egy adminisztrátor kifejezetten szükséges domain delegálást kér. A Google dokumentációja a részletes hatókörökről az alap; minden ügynök képességet egyetlen OAuth hatókörhöz kell térképezni, és dokumentálni kell az adott hatókör ember által olvasható szándékát. Tartsd távol a tokeneket a holmiktól. Tárold őket egy trezorban, és csak akkor injektáld a hitelesítő adatokat a hívás során, amikor egy végrehajtási szolgáltatás érvényesíti a politikát.

Megfigyeltük, hogy azok a csapatok, akik a jogosultságokat termék UX-ként kezelik, világos hozzájárulási képernyőkkel és hatókör-előzetesekkel, sokkal kevesebb támogatási jegyet kapnak. Egy probléma, amivel találkoztunk, a tokenek burjánzása volt naiv frissítési logikából; centralizáld a frissítéseket és rendszeresen cseréld le a frissítő tokeneket.

TERVEZÉS ÉS CSELEKVÉS

Oszt lehetőséget az asszisztensre egy tervezőre és egy végrehajtóra. A tervező egy elkülönített cselekvési tervet készít: olvasd el a legutóbbi szálakat, javasolj két időpontot egy találkozóra, írj egy tervezetet egy e-mailhez. A végrehajtó csak a politikai ellenőrzés és a kényes cselekvések esetében egy emberi megerősítési lépés után hajtja végre. Ez a minta megakadályozza, hogy a modell önállóan végezzen kiváltságos műveleteket, és az engedélyezés audittálhatóvá válik.

Gyakorlati kompromisszum: hosszabb késleltetés az emberi jóváhagyásért, mint az alacsonyabb kockázat. Sok naptári és e-mail cselekvés esetén a 30-60 másodperces emberi közbeavatkozás elfogadható. Magas frekvenciájú feladatok esetén a köteges jóváhagyások jobban működnek, mint az egy cselekvésre kattintás.

TESZTEK, NAPLÓK ÉS VISSZAÁLLÍTÁS

Minden cselekvésnek egy megváltoztathatatlan auditbejegyzést kell létrehoznia, amely tartalmazza a kért szándékot, a tervező kimenetét, a politikai döntést, a végrehajtó hívást és a visszaadott API-választ. Tarts meg egy visszajátszható parancsformát, így vissza tudod játszani és vissza tudod állítani. Biztosíts egy egy kattintásos visszavonást az utolsó N cselekvésre és egy helyreállítási folyamatot, amely kompenzáló eseményeket hoz létre, például egy esemény törlését és egy helyreigazító visszaigazolással.

Megfigyeltük, hogy a promp szintű védőkorlátok kudarcot vallanak külső politikai motor nélkül. A gyakorlatban a modellek javaslatokat fognak tenni, amelyek hihetőnek tűnnek, de sértik a politikát. Egy végrehajtási kapu, amely megtagad minden írást, ha a bizalom egy kalibrált küszöb alatt van, csökkenti ezeket az eseteket.

ELLENŐRZŐLISTA A TERMÉK ÉS MÉRNÖKI SZÁMÁRA

1. Per felhasználói OAuth minimális hatókörökkel és egyértelmű hozzájárulási szöveggel. 2. Token trezor és végrehajtási szolgáltatás, amely a hitelesítő adatokat futtatáskor injektálja. 3. Tervező/végrehajtó szétválasztás politikai ellenőrzésekkel. 4. Emberi közbeavatkozás a kényes cselekvésekhez. 5. Megváltoztathatatlan auditnaplók és visszajátszható cselekvési formátum. 6. Visszaállító és kompenzáló folyamatok világos UI elemekkel.

Kösd össze a termék UX-et a Tervezési ember-AI munkafolyamatok leírt munkafolyamatokkal, és használd az AI ügynökök vs chatbotok közötti különbségekre vonatkozó bevezetőt, hogy megindokold a tervező/végrehajtó szétválasztást.

Próbáld ki magad. Az alábbi példák a tervező kimenete és a végrehajtó-biztonságos utasítások ellentéte. Számíts tömör, JSON-szerű terveket a tervezőtől és rövid megerősítéseket a végrehajtótól.

Ez a prompt arra kéri a modellt, hogy egy korlátozott terveket készítsen a potenciális találkozó időpontokról, egy indoklással; használd ezt tervezőként. Számíts 2-3 jelölt időpontot és egy mondatos indoklást.

Te egy találkozótervező vagy. A felhasználónak 3 szabad időpontja van ma: 10:00, 14:30, 16:00. Térj vissza pontosan három jelölt találkozó-időponttal ISO formátumban, minden esethez egy soros indoklással, és egy soros adatvédelmi megjegyzéssel, amely azt mondja, hogy a meghívó érinti-e a külső e-maileket.

Ez a prompt a végrehajtónak szól. Ezt várja egy emberi megerősítő token és egy explicit politikai ellenőrzés passzálása, mielőtt létrehozná az eseményt.

Végrehajtó: adott felhasználói megerősítő token X és tervezési terv Y, hívd a Calendar.CreateEvent-et a következő mezőkkel {start,end,attendees,summary} csak abban az esetben, ha policy_check(policy_id:calendar_write) passzal tér vissza. Ha a policy_check megbukik, térj vissza a hiba kódjával és a szükséges emberi cselekvéssel.

Egy ellenérv az, hogy a szigorú ellenőrzések lassítják az elterjedést. Saját becslésem, hogy amikor a csapatok érvényesítik ezeket a mintákat, a korai felhasználói megtartás javul, mert a bizalom nő, még ha a kezdeti aktiválás lassabb is. A kompromisszum nyilvánvaló: a gyorsabb bevezetés ezek az ellenőrzések nélkül mérhető kockázatot és magasabb helyreállítási költségeket eredményez.