Agent, który ma realnie pomagać, potrzebuje dostępu do systemów, danych i poleceń. Ten sam dostęp sprawia, że jedna źle zinterpretowana instrukcja albo treść wstrzyknięta z zewnątrz może skończyć się skasowaną bazą, sięgnięciem po dane, do których agent nigdy nie miał mieć dostępu, wyciekiem sekretów albo requestem, którego nikt nie autoryzował. Większość odpowiedzi na ten problem sprowadza się dziś do zdania w prompcie: „nie rób X”. To nie jest zabezpieczenie, tylko prośba.
Opowiem o wzorcu, który stosuję projektując systemy agentowe i korzystając z gotowych środowisk. Pięć niezależnych warstw, z których każda działa nawet wtedy, gdy pozostałe zawiodą. Pierwsza decyduje o tym, jakie operacje agent w ogóle dostaje do dyspozycji, kolejne pilnują uprawnień po stronie systemów, a ostatnie egzekwują zasady całkowicie poza modelem.
Do tego kwestie, na których ten temat najczęściej się rozjeżdża: odcięcie agenta na poziomie systemu operacyjnego, obsługa sekretów, realna izolacja kontra izolacja z nazwy oraz dane wrażliwe, które przechodzą przez system, choć agent nie powinien ich zobaczyć.
Opowiem też o trade-offach. Każda warstwa zabiera trochę wygody i część możliwości agenta, więc pokażę, gdzie ta cena się zwraca i z czego sam zrezygnowałem.
Przykładem przewodnim będzie warstwa semantyczna nad danymi firmy: CRM, poczta, zadania, transkrypcje spotkań. Miejsce, w którym agent potrzebuje dużo kontekstu i jednocześnie nie może dostać dostępu do wszystkiego.
Wyjdziesz z listą kontrolną do zastosowania przy własnych narzędziach dla agentów i z rozróżnieniem między tym, co naprawdę ogranicza agenta, a tym, co tylko wygląda na zabezpieczenie.
