hachiflow.com
Bezpieczeństwo

Płatności agentów, które można prześledzić

Gdy agent może wydawać pieniądze, pierwsze pytanie osoby odpowiedzialnej za bezpieczeństwo jest proste: czyj agent co zrobił i kto to zatwierdził? Tak odpowiada na nie pełny ślad zdarzeń, które części istnieją dziś, które dopiero budujemy i jak poprosić model, by odczytał ślad na głos.

To pytanie dotyczy ludzi, nie agentów

Gdy agent dostaje możliwość płacenia, zmienia się spotkanie przeglądowe. Nikt nie pyta, jak sprytny jest agent. Pytają, czyj jest, co zrobił, co mógł zrobić i kto się zgodził.

To pytania o odpowiedzialność, a odpowiedź musi dać się sprawdzić po fakcie, a nie odtwarzać z pamięci. Do tego służy ślad.

Jeden ślad, od żądania do wyniku

W Waggle każda akcja jest zdarzeniem na szynie zdarzeń. Zdarzenie niesie identyfikator, czas, źródło, typ, workspace, podmiot i identyfikator śladu. Podmiot wskazuje po id, który człowiek lub który agent to zrobił. Zdarzenia łączą się w łańcuchy przez identyfikator śladu.

Ślad pokazuje każdą turę agenta: workspace, agenta, konto, do którego agent należy, co ją wywołało, wynik, użyte narzędzia i dane uwierzytelniające oraz zatwierdzenia wraz z tym, kto o nich zdecydował. Idąc za jednym łańcuchem, można odczytać kawałek pracy od prośby człowieka, przez turę agenta, wydzierżawione dane uwierzytelniające i zatwierdzenie, aż do wyniku.

To istnieje dziś dla pracy agentów w ogóle. Część dotycząca płatności, czyli zakup jako osobny rodzaj zdarzenia, to to, co budujemy dalej.

Prośba pyta człowiek Tura agenta który agent i konto Dzierżawa nigdy wartość Zatwierdzenie kto zdecydował Wynik co się stało trace_id jeden identyfikator śladu zdarzenia na szynie, każde z podmiotem
Jeden kawałek pracy jako łańcuch zdarzeń. Tak dziś śledzi się pracę agentów. Zakup jako osobny rodzaj zdarzenia, z kwotą i limitem wydatków, jest planowany.

O co zwykle pytają recenzenci bezpieczeństwa płatności

Recenzenci opierający się na standardach kart płatniczych, takich jak PCI DSS, ogólnie pytają o podobne rzeczy. Każda osoba odpowiada indywidualnie. Dane uwierzytelniające nigdy nie są ujawniane temu, co ich używa. Istnieją limity tego, ile można wydać. A dzienniki wiążą każdą akcję z jednym człowiekiem.

Nie twierdzimy, że spełniamy jakikolwiek standard. Możemy za to jasno powiedzieć, jak nasz projekt odpowiada na te pytania. Odpowiedzialność: każde zdarzenie wskazuje swój podmiot po id. Dane uwierzytelniające: leżą w escrow, a agent trzyma dzierżawę, nigdy wartość. Dziennik: zdarzenia dzielą identyfikator śladu, więc akcja prowadzi z powrotem do osoby, która o nią poprosiła lub ją zatwierdziła.

Limity wydatków to jedyna rzecz, która jeszcze nie istnieje. Będziemy to mówić za każdym razem, gdy temat wróci.

Co działa dziś i co budujemy

Działa dziś: zdarzenia z podmiotem i identyfikatorem śladu, ślady dla każdej tury agenta, zatwierdzenia zapisujące, kto zdecydował, oraz dane uwierzytelniające w escrow z dzierżawami dla agentów. Nic związanego z płatnościami nie działa. Agent nie może dziś wydawać pieniędzy przez Waggle.

Budujemy zdarzenia płatności na tej samej szynie: kto autoryzował zakup, który agent wydał, limit wydatków dla każdego agenta i zatwierdzenie podwyższone powyżej progu. Do tego dziennik płatności odporny na manipulacje oraz redakcję numerów kart na wejściu, żeby numer karty wklejony do wiadomości nie trafił do dziennika.

Powiedzmy jasno, jak wygląda dziennik teraz. Dziennik zdarzeń nie jest podpisany ani powiązany łańcuchem skrótów i domyślnie jest przechowywany 90 dni, dłużej, gdy skonfigurowano archiwum. Recenzent, który potrzebuje dziennika, w którym nikt nie zmieni wpisu po cichu, przechowywanego rok lub dłużej, potrzebuje więcej, niż mamy. Trzeba by dodać podpisywanie lub łańcuch skrótów dla dziennika płatności oraz dłuższe przechowywanie.

Poproś model o odczytanie śladu

Ślady są narzędziami w endpoincie MCP, więc można skierować na nie asystenta. Wystarczy dodać https://api.hachiflow.com/mcp do klienta, zalogować się i zapytać zwykłym językiem, co zrobili agenci.

Asystent wywołuje hachi_traces_ls, żeby wypisać tury agentów, wybiera jedną i wywołuje na niej hachi_trace_get. To zwraca cały powiązany łańcuch zdarzeń dla tej pracy, a model odczytuje go jako krótką relację: kto prosił, który agent działał, jakich danych uwierzytelniających użył, kto zatwierdził, co się stało.

Dziś odpowiada to na pytanie, kto zatwierdził to, co zrobił agent. Zdarzeń płatności jeszcze nie ma. Gdy będą, budujemy je tak, by to samo pytanie obejmowało wydatki, z kwotą i obowiązującym limitem.

assistant
# pytasz zwykłym językiem > what did my agents do yesterday and who approved the spend? # wypisuje tury agentów, potem otwiera jedną $ hachi_traces_ls $ hachi_trace_get # i odczytuje ci łańcuch

Pytanie i dwa narzędzia, których używa. Odpowiedź pochodzi ze śladu, nie z pamięci modelu.

Ślady pokazują też, o co przestać prosić model

Czytanie śladów ma drugie zastosowanie. Gdy to samo zadanie wraca tura po turze, z tymi samymi narzędziami w tej samej kolejności i z tym samym wynikiem, to już nie jest decyzja oparta na ocenie. To rutyna.

Takie zadania warto zamienić w deterministyczny kod. Model zostaje do pracy, która się zmienia, a zwykły skrypt robi to, co się nie zmienia. Ślad mówi, co jest czym, bo zapisuje, co się wydarzyło, a nie to, co ktoś pamięta.

Gdzie nas to zostawia

Odpowiedzialność za pracę agentów działa: podmioty, łańcuchy śladów, zatwierdzenia i dzierżawy danych uwierzytelniających. Odpowiedzialność za wydatki agentów jest planowana: zdarzenia płatności, limity wydatków, zatwierdzenie podwyższone i dziennik odporny na manipulacje. Wolimy powiedzieć, co jest czym, niż sugerować, że jedno pokrywa drugie.

← Wszystkie notatki