Agentne asystenty: bezpieczne integracje z kalendarzem i Gmail

Moje stwierdzenie: budowanie bezpiecznych i użytecznych agentów asystujących, którzy działają na kalendarzach, Gmailu i połączonych aplikacjach, wymaga zaprojektowania runtime'u z pierwszeństwem dla uprawnień, oddzielenia planowania od działania oraz wbudowania procesów audytu i cofania w warstwę wykonawczą od samego początku. Artykuł ten przedstawia ścisłą listę kontrolną dla inżynierów oraz gotowe promptery, aby to osiągnąć.

PROJEKTOWANIE UPRAWNIEŃ DLA AGENTÓW ASYSTUJĄCYCH

Rozpocznij od OAuth per użytkownik i najmniejszych możliwych zakresów. Używaj OAuth powiązanego z użytkownikiem zamiast wspólnego konta serwisowego, chyba że administrator wyraźnie wymaga delegacji domeny. Dokumentacja Google dotycząca szczegółowych zakresów stanowi bazę; przyporządkuj każdą zdolność agenta do pojedynczego zakresu OAuth i udokumentuj czytelny dla ludzi zamiar tego zakresu. Trzymaj tokeny z dala od promptów. Przechowuj je w skarbcu i wstrzykuj dane uwierzytelniające tylko w momencie wywołania w usłudze wykonawczej, która egzekwuje politykę.

Zauważyliśmy, że zespoły, które traktują uprawnienia jako UX produktu, z jasnymi ekranami zgody i podglądami zakresów, otrzymują o wiele mniej zgłoszeń do wsparcia. Jeden problem, z którym się spotkaliśmy, to proliferacja tokenów z powodu naiwnej logiki odświeżania; centralizuj odświeżanie i regularnie rotuj tokeny odświeżające.

PLANOWANIE A DZIAŁANIE

Podziel asystenta na planistę i wykonawcę. Planista produkuje wyraźny plan działania: przeczytaj ostatnie wątki, zaproponuj dwa terminy spotkania, skonstruuj szkic e-maila. Wykonawca dokonuje realizacji tylko po sprawdzeniu polityki i, w przypadku wrażliwych działań, po potwierdzeniu przez człowieka. Taki schemat zapobiega improwizacji przez model uprawnionych operacji i czyni autoryzację audytowalną.

Praktyczny kompromis: dłuższy czas oczekiwania na zatwierdzenie przez człowieka w kontraście do niższego ryzyka. W przypadku wielu działań związanych z kalendarzem i e-mailem, 30-60 sekundowa przerwa z udziałem człowieka jest akceptowalna. W przypadku działań o wysokiej częstotliwości, zbiorcze zatwierdzenia działają lepiej niż kliknięcia dla poszczególnych działań.

TESTY, LOGI I ODZYSKIWANIE

Każda akcja musi generować niezmienny wpis kontrolny zawierający żądany zamiar, wynik planisty, decyzję o polityce, wywołanie aktora i odpowiedź API. Utrzymuj format rozkazów, który można powtórzyć, abyś mógł odtworzyć i cofnąć. Zapewnij jednoczesne cofnięcie ostatnich N działań oraz proces odzyskiwania, który tworzy kompensujące zdarzenia, na przykład anulowanie wydarzenia i wysłanie poprawiającego e-maila.

Zauważyliśmy, że zabezpieczenia na poziomie promptów zawodzą bez zewnętrznego silnika polityki. W praktyce modele będą sugerować zmiany, które wyglądają na prawdopodobne, ale są w sprzeczności z polityką. Brama wymiany, która odmawia jakiegokolwiek zapisu, gdy pewność jest poniżej skalibrowanego progu, zmniejsza te incydenty.

LISTA KONTROLNA DLA PRODUKTU I INŻYNIERII

1. OAuth per użytkownik z minimalnymi zakresami i wyraźnym tekstem zgody. 2. Skarbiec tokenów i usługa wykonawcza, która wstrzykuje dane uwierzytelniające w czasie rzeczywistym. 3. Oddzielenie planowania/wykonywania oraz kontrole polityki. 4. Eskalacja z uczestnictwem człowieka dla wrażliwych działań. 5. Niepodważalne logi audytu i format działań do powtórzenia. 6. Procesy cofania i kompensacji z jasnymi elementami UI.

Połącz UX produktu z opisaną w Projektowaniu przepływów pracy człowieka i AI i wykorzystaj wstęp na temat różnic agentów w Agenci AI vs chatboty do uzasadnienia podziału planista/wykonawca.

Spróbuj sam. Poniższe promptery ilustrują wyniki planisty w porównaniu do bezpiecznych instrukcji wykonawcy. Oczekuj zwięzłych planów w formacie podobnym do JSON z planisty oraz krótkich potwierdzeń od wykonawcy.

Ten prompt prosi model o wygenerowanie ograniczonego planu potencjalnych terminów spotkań i uzasadnienia; użyj go jako planisty. Oczekuj 2 do 3 potencjalnych terminów oraz uzasadnienia w jednej zdaniu.

Jesteś planistą spotkań. Użytkownik ma 3 wolne sloty dzisiaj: 10:00, 14:30, 16:00. Zwróć dokładnie trzy potencjalne terminy spotkań w formacie ISO z uzasadnieniem w jednej linijce dla każdego oraz w jednej linii informację o prywatności, czy zaproszenie dotyka zewnętrznych e-maili.

Ten prompt jest dla wykonawcy. Oczekuje tokenu potwierdzenia od człowieka i przejścia kontroli polityki przed utworzeniem wydarzenia.

Wykonawca: mając token potwierdzenia użytkownika X i plan planisty Y, wywołaj Calendar.CreateEvent z polami {start, end, attendees, summary} tylko wtedy, gdy policy_check(policy_id:calendar_write) zwraca pass. Jeśli policy_check nie przechodzi, zwróć kod błędu i wymagane działanie człowieka.

Przeciwwagą jest to, że surowe kontrole spowalniają adopcję. Moja szacunkowa ocena jest taka, że gdy zespoły egzekwują te wzorce, początkowa retencja użytkowników poprawia się, ponieważ wzrasta zaufanie, nawet jeśli początkowa aktywacja jest wolniejsza. Kompromis jest jasny: szybsze wprowadzenie bez tych kontroli wiąże się z mierzalnym ryzykiem i wyższymi kosztami naprawy.