---
title: "Na czyich uprawnieniach działa Wasz agent?"
url: "https://predictes.com/pl/blog/na-czyich-uprawnieniach-dziala-wasz-agent"
description: "Większość agentów działa na tokenie konkretnej osoby albo na wspólnym koncie serwisowym. W obu przypadkach nikt nie zaprojektował ich zasięgu, a log mija się z prawdą."
---

# Na czyich uprawnieniach działa Wasz agent?

23 maja 2026·3 min czytania·predictes

Zapytajcie, kim jest agent z punktu widzenia Waszych logów dostępu, a odpowiedź zwykle będzie jedną z dwóch. Albo działa jako osoba, która go uruchomiła, z jej tokenem wklejonym do pliku konfiguracyjnego, albo jako konto serwisowe założone w pośpiechu i wyposażone w szerokie uprawnienia, żeby „nic go nie blokowało”.

Obie odpowiedzi są zrozumiałe i obie są błędne w ten sam sposób. Zasięg agenta staje się czymś, czego nikt nie zaprojektował, a log zaczyna mówić nieprawdę.

## Dwie typowe odpowiedzi

**Agent działający jako człowiek.** Dziedziczy wszystko, co ta osoba może zrobić, łącznie z tym, czego jego zadanie nigdy nie potrzebuje. Log przypisuje działania agenta komuś, kto ich nie wykonał. Gdy ta osoba zmienia stanowisko albo odchodzi, agent albo przestaje działać, albo — co gorsze — zachowuje dostęp, który powinien był stracić razem z nią.

**Agent na wspólnym koncie serwisowym.** Jedna tożsamość obsługuje wszystkich użytkowników. Agent sięga do rekordów każdego klienta w imieniu dowolnego klienta, więc użytkownik, który go przekona, albo treść, która go zmanipuluje, dociera do danych, do których ten użytkownik nigdy nie miał prawa. To stary problem znany jako „confused deputy”: program z własnymi uprawnieniami wykonuje prośbę kogoś, kto ma ich mniej.

Żaden z tych problemów nie jest nowy i żaden nie wymaga do naprawy niczego specyficznego dla AI. Nowe jest to, że program pośrodku da się teraz do czegoś namówić.

## Jak powinna wyglądać tożsamość agenta

**Własna tożsamość z właścicielem.** Zarejestrowana, nazwana i przypisana do odpowiedzialnej osoby; w logach agent występuje pod nią, a nie pod cudzym nazwiskiem. Jeśli nie da się wyłączyć agenta bez wyłączenia człowieka, agent własnej tożsamości nie ma.

**W imieniu, a nie zamiast.** Dla każdego zadania efektywne uprawnienie jest częścią wspólną tego, co wolno agentowi, i tego, co wolno obsługiwanemu przez niego użytkownikowi. System docelowy widzi oba — ten agent, dla tego użytkownika — i sprawdza oba. Mechanizmy delegowania w popularnych platformach tożsamości istnieją dokładnie po to.

**Zawężona do zadania i krótkotrwała.** Token do odczytu jednej skrzynki przez najbliższy kwadrans, a nie klucz do systemu pocztowego ważny, dopóki ktoś nie przypomni sobie o rotacji. Gdy poświadczenie wycieknie, jego termin ważności wyznacza rozmiar incydentu.

**Poświadczenia nigdy w kontekście.** Model nie widzi żadnego sekretu. Środowisko narzędzi przechowuje poświadczenia i dołącza je do wywołań; model jedynie prosi o operację. Klucz w promptcie to klucz w każdym śladzie wykonania, w każdym logu i w każdej odpowiedzi, którą model da się namówić napisać.

**Odwoływalna w jednym miejscu.** Wyłączenie agenta to jedno działanie na jednej tożsamości, a nie poszukiwanie kluczy skopiowanych do pięciu plików konfiguracyjnych.

Wspólne konto adminaToken konkretnej osobyWłasne konto agentaTożsamość z zakresem użytkownikaKrótki token na zadanie

Cudze uprawnieniaDelegowane, wąskie

Każdy krok w prawo zmniejsza to, do czego sięgnie zmanipulowany agent.

## W łańcuchu uprawnienia mogą tylko maleć

Gdy agenci wywołują agentów, to samo pytanie wraca na każdym kroku. Orkiestrator powinien przekazać agentowi podrzędnemu najwęższe uprawnienia potrzebne do jego części zadania, wciąż powiązane z pierwotnym użytkownikiem, a nie swoje pełne. Agent, który tylko streszcza dokumenty, nie powinien móc niczego wysłać, o cokolwiek poprosi go orkiestrator.

Prośba od innego agenta nie jest też poleceniem użytkownika. Nie niesie więcej uprawnień niż treść, z której powstała. Jeśli orkiestrator przed delegowaniem przeczytał niezaufaną stronę, to ta strona ukształtowała delegowanie, a uprawnienia niżej w łańcuchu powinny to zakładać.

## Od czego zacząć

Od listy. Dla każdego agenta na produkcji albo w pilotażu zapiszcie, jako kto działa, do czego ta tożsamość sięga, czego agent faktycznie używa i kto może go wyłączyć. Różnica między drugą a trzecią kolumną to Wasza ekspozycja. Czwarta kolumna to Wasza reakcja na incydent.

To krótkie ćwiczenie. Często takiej listy jeszcze nie ma — i to już jest wynik. Potem weźcie agenta z największą różnicą i zacznijcie od niego; wzorzec zbudowany dla niego stanie się szablonem dla pozostałych.

## Tanio teraz, drogo później

Tożsamość agenta kosztuje niewiele, jeśli ustali się ją na etapie projektu, i bardzo dużo, jeśli trzeba ją dorabiać, bo wtedy od skrótu zależą już inne systemy. Przy [inżynierii agentów AI](https://predictes.com/pl/services/ai-agents-engineering) tożsamość i jej uprawnienia są częścią definicji granicy: rozstrzygane, zanim powstanie pierwsze narzędzie, a nie odkrywane przy pierwszym incydencie.

-   agenci AI
-   tożsamość
-   najmniejsze uprawnienia
-   zarządzanie dostępem

## Czytaj dalej

-   [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem)
-   [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)