← Biblioteka · Pojęcie
Tożsamość i uprawnienia agentów — kto naprawdę działa
Agent potrzebuje czegoś więcej niż narzędzi. Potrzebuje własnej tożsamości, ograniczonych uprawnień i audit trail, żeby było jasne, kto stoi za akcją, co wolno mu zrobić i gdzie ma się zatrzymać.
Agent nie jest anonimowym procesem
Kiedy agent wysyła e-mail, czyta Slacka, otwiera pull request albo dotyka systemu wewnętrznego, przestaje być tylko modelem w oknie. Staje się aktorem w procesie pracy. Pytanie brzmi więc nie tylko „co potrafi”, ale też „pod czyją tożsamością działa”.
Wspólny token, prywatne konto developera albo szeroki dostęp przez jeden service key to wygodne skróty. Jednocześnie zacierają granicę między człowiekiem, agentem i automatyzacją. Gdy coś się zepsuje, nikt nie chce zobaczyć w logu odpowiedzi: zrobił to jakiś token.
Tożsamość wyznacza odpowiedzialność
Dobra tożsamość agenta ma jasny zakres: ten agent należy do tego zespołu, działa w tej przestrzeni roboczej, używa tych narzędzi, a jego akcje są oznaczone jako maszynowe lub wspomagane przez maszynę. Nie powinien udawać człowieka. Powinien być rozpoznawalnym uczestnikiem systemu.
To nie znaczy, że każdy agent potrzebuje pełnego profilu pracownika i uroczystego onboardingu. Znaczy to, że system musi odróżnić akcję człowieka, akcję wspomaganą i autonomiczny krok. Bez tego audit zamienia się w śledztwo.
Uprawnienia mają być wąskie, nie wygodne
Agent powinien dostać najmniejsze uprawnienia, z którymi wykona konkretną pracę. Czytanie dokumentów to nie to samo co wysyłanie wiadomości. Zaproponowanie pull requestu to nie to samo co merge. Utworzenie draftu to nie to samo co publikacja. OWASP ostrzega, że nadmierna funkcjonalność, uprawnienia lub autonomia mogą umożliwić szkodliwe działanie nawet po nieoczekiwanym wyniku modelu. OWASP: Excessive Agency
Praktyczny wzorzec to rozdzielenie praw według akcji: czytać, proponować, prosić o zatwierdzenie, wykonać. Im bardziej nieodwracalna akcja, tym wyraźniejszy powinien być ludzki punkt kontrolny albo techniczny hamulec.
Skrzynka odbiorcza, pamięć i narzędzia są powierzchnią ataku
Agent z dostępem do skrzynki odbiorczej, pamięci i narzędzi nie jest już izolowanym chatbotem. Czyta niezaufane wejście, trzyma kontekst i może działać na zewnątrz. To dokładnie miejsce, w którym prompt injection, źle dobrane uprawnienia i zbyt hojnie skonfigurowane narzędzie spotykają się w jednym pożarze.
Dlatego nie wystarczy powiedzieć, że agent „ma dostęp do Slacka” albo „może wysyłać e-mail”. Ważne jest, do których kanałów, pod jaką tożsamością, z jakimi filtrami, limitami, zatwierdzeniami i logami. Integracja bez granic to tylko szybsza droga do incydentu.
Co zapamiętać
Tożsamość agentów nie jest kosmetyką dla architektury enterprise. To podstawowa warstwa bezpieczeństwa i operacji. Agent ma być widoczny w systemie, mieć wąskie prawa i zostawiać ślad, który człowiek zrozumie także po północy podczas incydentu.
Granice
Oddzielna tożsamość i zapis audytowy same nie chronią systemu. Potrzebują ograniczonych tokenów, kontroli narzędzi i zgody człowieka na wrażliwe lub nieodwracalne działania. Log bez decyzji i wyniku działania również nie jest użytecznym śladem audytowym.