--- title: "Jedna tożsamość dla ludzi i agentów: kto co może" url: "https://hurukan.com/pl/blog/jedna-tozsamosc-dla-ludzi-i-agentow" description: "Agenci na wspólnym koncie serwisowym czynią każde działanie anonimowym. Dlaczego agent potrzebuje własnej tożsamości, delegowanej od człowieka, z wygasającym zakresem." --- # Jedna tożsamość dla ludzi i agentów: kto co może 22 października 2026·4 min czytania·Redakcja Rząd identycznych białych kart dostępu na biurku w czystym biurze, jedna z nich podświetlona cienką niebieską linią wzdłuż krawędzi, dłoń administratora sięgająca po nią, w tle laptop z abstrakcyjną niebiesko-szarą listą, mała głębia ostrości W czwartek po południu w danych podstawowych zmienia się numer konta bankowego dostawcy. Piątkowy przelew idzie na nowe konto. W następny wtorek dostawca dzwoni z pytaniem, gdzie są pieniądze, a dział finansów otwiera dziennik audytu, żeby sprawdzić, kto zrobił zmianę. Dziennik mówi: INTEGRATION\_SVC. To konto należy do warstwy pośredniczącej. Przechodzi przez nie synchronizacja sklepu, łącznik magazynu, zaplanowany skrypt porządkujący i, od wiosny, dwaj agenci aktualizujący dane podstawowe, gdy potwierdzony dokument mówi, że powinni. Sześć procesów, jedna nazwa, jedno hasło przechowywane w trzech miejscach. Zmianę zrobił któryś z nich, w czyimś imieniu, z jakiegoś powodu, a rekord nie umie powiedzieć który, dla kogo ani dlaczego. To nie jest naruszenie bezpieczeństwa. Każdy proces zrobił to, do czego go skonfigurowano. To problem tożsamości: firma dała swojemu oprogramowaniu jedną wspólną twarz, a wspólnej twarzy nie da się zadawać pytań. Gdy agenci zaczynają działać, liczba działań tej twarzy rośnie, a każde z nich jest anonimowe z założenia. ## Co ukrywa wspólne konto serwisowe **Sprawcę.** Sześć procesów pod jedną nazwą oznacza, że dziennik zapisuje, że coś się stało, a nie co to zrobiło. Pomyłka człowieka, błąd skryptu i zły osąd agenta wyglądają identycznie i są poprawiane tak samo: powoli. **Mocodawcę.** Agent aktualizuje dostawcę, bo poprosiła o to czyjaś rola albo pozwolił na to proces. Konto serwisowe nie niesie śladu tego łańcucha, więc pytanie „dla kogo to zrobiono” też nie ma odpowiedzi. **Zakres.** Konto serwisowe kumuluje prawa. Każda integracja potrzebowała jeszcze jednej tabeli, jeszcze jednego punktu końcowego, a nikt nie odebrał tych, których już nikt nie używa. Agent dodany w zeszłym roku odziedziczył wszystkie, w tym prawo do zmiany konta bankowego, którego nigdy nie potrzebował. **Czas.** Konto jest ważne od chwili założenia. Dostęp człowieka kończy się, gdy odchodzi; delegowane zadanie kończy się, gdy jest zrobione. Wspólne konto nie kończy się nigdy, więc hasło, które wyciekło raz, wyciekło na zawsze. **Granicę między odczytem a zapisem.** Konto, które czyta zamówienia do raportu, jest tym samym, które zapisuje plik przelewów. Jeden przejęty skrypt, jeden źle ustawiony prompt, i ścieżka odczytu staje się ścieżką zapisu. Dlaczego zapis jest tą niebezpieczną połową, wyjaśnia [Agent, który pisze do ERP](https://hurukan.com/pl/blog/agent-ktory-pisze-do-erp). **Uprawnienia przypięte do tabel.** Rola bazodanowa daje dostęp do tabeli, nie do klienta. Agent, któremu wolno czytać tabelę zamówień, czyta każde zamówienie, także te grupy klientów, której jego rola nigdy nie powinna widzieć. Ekran je ukrywał; agent nie używa ekranu. ## Jak musi wyglądać tożsamość agenta **Własna nazwa.** Każdy agent jest podmiotem w katalogu, jak człowiek, a nie jak hasło w pliku konfiguracyjnym. Dziennik nazywa wtedy agenta, a sporną zmianę można przypisać jednemu procesowi, a nie puli sześciu. **Delegowana od człowieka albo roli.** Agent nie ma praw własnych; działa dla kogoś. Agent zakupowy działa w roli zakupów, w granicach tego, co tej roli wolno, a rekord pokazuje agenta i rolę razem. Gdy człowiek stojący za rolą odchodzi, delegacja odchodzi z nim. **Zakresy, które wygasają.** Delegacja jest na zadanie, dziedzinę i okres. Odczyt otwartych faktur przez najbliższe trzydzieści dni to zakres; odczyt wszystkiego na zawsze to konto serwisowe pod inną nazwą. Gdy zakres wygasa, agent prosi ponownie, a prośba zostaje zapisana. **Uprawnienia na obiektach biznesowych, nie na tabelach.** Tu ontologia zarabia na swoje miejsce. Model definiuje klienta, zamówienie, dostawcę, konto bankowe i działania, które na każdym z nich istnieją: odczyt, propozycja, zmiana, zatwierdzenie. Uprawnienie mówi wtedy, że agent serwisowy może czytać reklamacje klientów jednego regionu i proponować odpowiedzi, a nie że może wybierać z trzech tabel. Ta sama reguła dotyczy ludzi, więc człowiek i agent w tej samej roli widzą dokładnie to samo. **Egzekwowane na serwerze, czytelne dla każdego.** Uprawnienie mieszka poniżej agenta, w warstwie, która sprawdza każde żądanie, a nie w instrukcjach agenta. Prompt nie może nadać sobie dostępu, a człowiek czytający model widzi, co każdemu agentowi wolno, bez czytania kodu. **Ta sama odpowiedź dla człowieka i agenta.** „Kto to zrobił, dla kogo, na jakiej podstawie i kto zatwierdził” ma tę samą odpowiedź niezależnie od tego, czy sprawcą był pracownik, czy proces. Jeśli rekord umie odpowiedzieć dla pracowników, a nie umie dla agentów, agenci są dziurą w audycie, a nie jego częścią. ## Test, który możecie zrobić dziś Otwórzcie dziennik audytu Waszego ERP albo programu księgowego i przefiltrujcie ostatni miesiąc po kontach technicznych: użytkownik integracyjny, użytkownik API, cokolwiek z „svc”, „sync” albo „system” w nazwie. Policzcie zmiany. Potem weźcie losowo pięć z nich i spróbujcie dla każdej odpowiedzieć, który proces zrobił zmianę i dla którego człowieka albo roli. Jeśli nie umiecie odpowiedzieć w kilka minut z samego rekordu, bez pytania działu IT, każda z tych zmian jest anonimowa. Teraz spiszcie procesy, które dzielą każde konto techniczne, i prawa, które konto ma. Różnica między tym, czego każdy proces potrzebuje, a tym, co konto ma, to powierzchnia ataku, z którą pracowaliście do tej pory, i to ją agent odziedziczyłby pierwszego dnia. W Hurukanie każde żądanie dociera do serwera z tożsamością: człowiek, agent działający dla człowieka albo procesu, albo sam system. Uprawnienia są sprawdzane tam, na serwerze, względem ról i reguł, które [ontologia](https://hurukan.com/pl/system/ontologia) definiuje na obiektach biznesowych, a każda zmiana jest zapisywana z typem autora, tym, co się zmieniło, i tym, kto zatwierdził. To właśnie pozwala rozliczyć agenta w tym samym zdaniu co pracownika i jest warstwą bazową [Hurukana](https://hurukan.com/pl), opisaną w [Suwerenność to decyzja architektoniczna](https://hurukan.com/pl/blog/suwerennosc-to-decyzja-architektoniczna). - tożsamość - uprawnienia - agenci - ślad audytowy - ontologia ## Czytaj dalej - [Stan bieżący i zapis: dwie pamięci systemu operacyjnego firmy](https://hurukan.com/pl/blog/stan-biezacy-i-zapis-dwie-pamieci-systemu-operacyjnego-firmy) - [Agent, który pisze do ERP: granica między odczytem a zapisem](https://hurukan.com/pl/blog/agent-ktory-pisze-do-erp)