Agenci AI na smyczy. Jak realnie ograniczyć to, co agent może zrobić

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ą, wyciekiem sekretów, sięgnięciem po cudze dane albo nieautoryzowanym requestem. Najczęstsza odpowiedź to dziś zdanie 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ą: od tego, jakie operacje agent w ogóle dostaje, przez uprawnienia po stronie systemów, po zasady egzekwowane całkowicie poza modelem.

Do tego miejsca, w których ten temat najczęściej się rozjeżdża: odcięcie agenta na poziomie systemu operacyjnego, sekrety, realna izolacja kontra izolacja z nazwy i dane wrażliwe, których agent nie powinien zobaczyć. Będą też trade-offy. Każda warstwa zabiera trochę wygody i 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ń. Agent potrzebuje tam dużo kontekstu, a nie może dostać dostępu do wszystkiego.