Co wysyła agent programistyczny: audyt telemetrii

Co faktycznie obejmuje telemetria agentów programistycznych

Telemetria agentów programistycznych to cztery odrębne strumienie danych, które dzielą jedną nazwę, a każdy z nich posiada własne mechanizmy kontroli. Wnioskowanie modelu przesyła Twoje prompty oraz kod do podmiotu obsługującego model i żadne ustawienie nie pozwala tego wyłączyć. Analityka produktu oraz raporty o awariach trafiają do dostawcy, a często również do firmy zajmującej się logowaniem, której dostawca płaci. Retencja danych w celu trenowania modeli jest kwestią kontraktową, a nie sieciową. Czwarty strumień jest tym, który najczęściej umyka uwadze: każda dodana integracja może otworzyć połączenie z hostem, którego nigdy nie wybrałeś.

Lista domyślnych ustawień dostawców jest elementem tego zagadnienia, który dezaktualizuje się najszybciej. Nowa wersja oprogramowania może zmienić ustawienie domyślne, a nowa funkcja może dodać miejsce docelowe, którego nie obejmuje żaden istniejący przełącznik. Dlatego trwałą umiejętnością jest audyt, który można powtórzyć dla każdego agenta: przeczytaj dokumentację dostawcy, sprawdź, która konfiguracja faktycznie została zastosowana na danej maszynie, monitoruj proces z poziomu samej maszyny, a następnie wybierz mechanizmy kontroli, za które jesteś gotów zapłacić. Każde poniższe polecenie uruchamiasz na własnej maszynie, w odniesieniu do własnego ruchu sieciowego.

Cztery kategorie i powody, dla których wymagają różnych mechanizmów kontroli

Ruch związany z wnioskowaniem modelu jest nieunikniony. Agent przesyła prompt, odczytane pliki, wyniki wykonanych poleceń oraz wygenerowany przez siebie tekst do punktu końcowego modelu. Jest to działanie zgodne z przeznaczeniem produktu. Jedyną realną decyzją jest wybór odbiorcy: API obsługiwanego przez podmiot zewnętrzny lub modelu uruchamianego samodzielnie. Korzystanie z chmury korporacyjnej (Bedrock, Vertex, Foundry) zmienia odbiorcę, ale nie eliminuje przepływu danych. Żaden z dalszych punktów tego wpisu nie ograniczy ruchu związanego z wnioskowaniem, dlatego należy rozpatrywać go oddzielnie od pozostałych trzech kategorii.

Analityka produktu i raportowanie awarii to odrębny przepływ do innych hostów. Liczniki użycia, dane o opóźnieniach, sprawdzanie flag funkcji oraz ślady stosu (stack traces) zazwyczaj trafiają do nazw hostów niezwiązanych z API modelu, często do zewnętrznych systemów śledzenia błędów. Dostawcy zazwyczaj dokumentują to jako "metryki" i "raporty błędów", udostępniając zazwyczaj jedną zmienną środowiskową dla każdej kategorii. Wolumen danych jest znikomy, więc analiza liczby bajtów nie pozwoli na ich wykrycie. Celem jest identyfikacja nazw hostów, a nie przepustowości.

Retencja i trenowanie to kwestie polityki, a nie pakietów. To, czy dostawca przechowuje prompty, jak długo oraz czy wykorzystuje je do trenowania przyszłych modeli, wynika z warunków umowy przypisanych do planu. Plany konsumenckie i komercyjne zazwyczaj różnią się, a ustalenia dotyczące zerowej retencji wymagają zazwyczaj osobnego porozumienia. Nie można zweryfikować tych kwestii za pomocą tcpdump, ponieważ pakiety wyglądają identycznie w obu przypadkach. Należy zapoznać się z warunkami, a jeśli ma to znaczenie dla pracodawcy, uzyskać potwierdzenie na piśmie.

Integracje po cichu dodają kolejny przeskok. Serwer MCP (model context protocol), rynek wtyczek, sprawdzanie automatycznych aktualizacji, narzędzie wyszukiwania w sieci, mechanizm bezpieczeństwa sprawdzający adres URL przed jego pobraniem: każdy z tych elementów to żądanie do hosta innego niż punkt końcowy modelu. To tutaj kryją się niespodzianki, ponieważ środowisko uruchomieniowe może przekierować pracę, która miała być lokalna, przez własną usługę, a nowa wersja oprogramowania może zacząć to robić bez zmiany ani jednej linii w konfiguracji. Każde dodane narzędzie należy traktować jako nowy cel, dopóki nie zostanie zweryfikowane w ruchu sieciowym.

Krok 1: co zawiera dokumentacja producenta?

Otwórz dokumentację ustawień oraz stronę dotyczącą wykorzystania danych dla swojego agenta i przeanalizuj je, mając pod ręką listę słów kluczowych: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. Każde z tych pojęć zazwyczaj odpowiada osobnemu przełącznikowi. Zapisz dokładne nazwy zmiennych, ponieważ w kroku 2 będą one wyszukiwane za pomocą polecenia grep.

Jedno słowo może wprowadzić w błąd. W przypadku wielu agentów termin "telemetry" w dokumentacji oznacza eksport OpenTelemetry, który konfiguruje się w celu przesyłania metryk do własnego kolektora. Jest to przeciwieństwo przesyłania danych do producenta. Claude Code jest jednym z takich przykładów: ustawienie CLAUDE_CODE_ENABLE_TELEMETRY=1 uruchamia eksport do punktu końcowego określonego w OTEL_EXPORTER_OTLP_ENDPOINT i nie jest powiązane z własnymi mechanizmami analitycznymi producenta, które posiadają odrębną opcję rezygnacji. Przed wprowadzeniem jakichkolwiek zmian ustal kierunek przepływu danych.

Należy spodziewać się istnienia głównego przełącznika oraz faktu, że nie jest on kompletny. Według stanu na sierpień 2026, ustawienie CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC w Claude Code wyłącza jednocześnie metryki, raporty o błędach, polecenie feedback oraz ankiety sesyjne. Ta sama dokumentacja wskazuje jednak, że ustawienie to nie obejmuje kontroli bezpieczeństwa domeny WebFetch, która przesyła nazwę hosta do API producenta i posiada własne, oddzielne ustawienie. Nie jest to zarzut wobec konkretnego produktu, lecz charakterystyka problemu występującego powszechnie: główny przełącznik obejmuje tylko te kategorie, które istniały w momencie jego tworzenia.

Należy również liczyć się z kosztami rezygnacji z przesyłania danych. Ta sama dokumentacja zauważa, że wyłączenie telemetrii dezaktywuje również ocenę flag funkcji (feature-flag evaluation), od których zależą niektóre mechanizmy. W rezultacie przełącznik zmieniony ze względów prywatności może wyłączyć używaną funkcję, nie generując przy tym komunikatu o błędzie wskazującego na powiązanie między tymi zdarzeniami. Należy czytać treść znajdującą się obok flagi, a nie tylko jej nazwę.

Krok 2: która konfiguracja faktycznie została zastosowana?

Zapisane ustawienie nie zawsze jest ustawieniem, które zostało zastosowane. Agenci łączą konfigurację z kilku plików, a jeden z nich znajduje się w repozytorium, które właśnie sklonowano od kogoś innego. Należy zacząć od środowiska własnej powłoki.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Następnie należy wyświetlić każdy plik ustawień odczytywany przez narzędzie, w kolejności podanej w dokumentacji. W przypadku Claude Code, według stanu na sierpień 2026, jest to plik użytkownika, dwa pliki projektu oraz zarządzany katalog polityk w systemie Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

Plik projektu, który został dostarczony wraz z git clone, zawiera konfigurację napisaną przez inną osobę i może on ponownie włączyć to, co plik użytkownika wyłączył. Jeśli agent posiada polecenie statusu, które wymienia załadowane źródła, jest to najszybszy sposób na uzyskanie wiarygodnych informacji: Claude Code wyświetla załadowane źródła ustawień w /status.

Najskuteczniejszą metodą weryfikacji jest odczytanie stanu uruchomionego procesu zamiast sprawdzania plików. Najpierw należy przypisać agentowi własne konto użytkownika w systemie Linux, co skróci każde polecenie w tym wpisie, a następnie odczytać środowisko, z jakim proces został uruchomiony.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ pokazuje zmienne, które proces posiadał w momencie wywołania, dzięki czemu pozwala wykryć przypadek, w którym polecenie .bashrc export nigdy nie dotarło do usługi uruchomionej przez systemd. Jeśli ustawiona zmienna nie znajduje się w tym miejscu, oznacza to, że nigdy nie weszła w życie, niezależnie od zawartości plików konfiguracyjnych (dotfiles).

Krok 3: z jakimi hostami nawiązywane są połączenia?

Należy rozpocząć od otwartych gniazd, przefiltrowanych według konta użytkownika, na którym uruchomiony jest agent.

sudo ss -tnpe state established

-e dodaje pole uid: do każdej linii, co pozwala oddzielić połączenia agenta od połączeń przeglądarki bez konieczności analizy nazw procesów. Należy zanotować adresy zdalne, a następnie uzyskać przypisane do nich nazwy. Najbardziej wiarygodnym źródłem nazw jest uzgadnianie TLS (transport layer security), ponieważ każde nowe połączenie rozpoczyna się od pakietu ClientHello zawierającego pole SNI (server name indication), czyli nazwę hosta, o którą zapytał klient.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Wynikiem jest jedna linia na każde nowe połączenie, co stanowi kompletny wykaz: API modelu, serwer aktualizacji, host analityczny, moduł śledzenia błędów oraz wszelkie elementy dodane przez integracje. Pusta kolumna nazwy oznacza, że klient użył ECH (encrypted client hello), przez co nazwa hosta nie jest widoczna w ruchu sieciowym. W takim przypadku należy oprzeć się na docelowym adresie IP, odwrotnym wyszukiwaniu DNS lub proxy opisanym w kroku 4.

Widok DNS (domain name system) stanowi przydatną weryfikację krzyżową, ponieważ pokazuje nazwy, które agent wyszukał nawet dla połączeń, które nie zostały sfinalizowane.

sudo tcpdump -ni any -l 'udp port 53'

Każda linia zapytania kończy się typem rekordu i nazwą w formacie A? host.example.net. (39). Przechwytywanie należy prowadzić na any, a nie na interfejsie zewnętrznym, ponieważ przy użyciu systemd-resolved aplikacja komunikuje się z lokalnym stubem na 127.0.0.53 i tylko ten stub nawiązuje połączenia zewnętrzne. Jeśli podczas pracy agenta nie widać żadnego ruchu DNS, oznacza to, że środowisko uruchomieniowe samodzielnie wykonuje DNS over HTTPS i tylko krok 4 pozwoli na uzyskanie nazw.

Przechwytywanie należy prowadzić w trakcie wykonywania przez agenta rzeczywistych zadań. Należy rozpocząć sesję, wymusić odczyt pliku, uruchomienie polecenia lub wystąpienie błędu. Ruch sieciowy generowany tylko podczas startu lub w momencie wystąpienia wyjątku nie pojawi się w przechwycie wykonanym w stanie bezczynności, a analiza stanu bezczynności jest najczęstszą przyczyną błędnych wniosków z audytu.

Krok 4: co znajduje się w żądaniach?

Nazwy hostów określają adresata. Aby sprawdzić zawartość, należy umieścić kontrolowany serwer proxy przed agentem i zaufać jego urzędowi certyfikacji (CA) wyłącznie w tym środowisku uruchomieniowym. Standardowym narzędziem jest mitmproxy. Projekt zaleca użycie samodzielnych plików binarnych z mitmproxy.org oraz dokumentuje uv tool install mitmproxy jako metodę instalacji przez pakiet Python.

mitmdump -w /tmp/agent-flows.mitm

Pierwsze uruchomienie zapisuje CA w ~/.mitmproxy/, gdzie mitmproxy-ca-cert.pem jest samym certyfikatem. W powłoce, z której zostanie uruchomiony agent, należy wskazać klientowi serwer proxy oraz ten certyfikat.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

Wiele interfejsów CLI agentów to programy Node, a Node odczytuje NODE_EXTRA_CA_CERTS w momencie uruchomienia procesu, dlatego zmienną należy wyeksportować przed uruchomieniem agenta, a nie w innym terminalu po fakcie. Klienci w języku Python odczytują REQUESTS_CA_BUNDLE lub SSL_CERT_FILE, a pliki binarne Go korzystające ze standardowej biblioteki odczytują SSL_CERT_FILE w systemie Linux. Przed obwinieniem agenta należy zweryfikować poprawność ścieżki za pomocą curl.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Działający serwer proxy wyświetla 200, a żądanie pojawia się w danych wyjściowych mitmdump. Niezaufany urząd CA powoduje curl: (60) SSL certificate problem: self-signed certificate in certificate chain, a odpowiednikiem tego błędu w agencie Node jest błąd z kodem SELF_SIGNED_CERT_IN_CHAIN. Zapisane przepływy można przejrzeć później za pomocą przeglądarki konsolowej, gdzie można otworzyć pojedyncze żądanie i odczytać jego nagłówki oraz treść.

mitmproxy -r /tmp/agent-flows.mitm

Warto wyróżnić cztery możliwe scenariusze. Widoczne są żądania – w takim przypadku należy je przeanalizować i podjąć decyzję. Agent odmawia uruchomienia z powodu błędu certyfikatu – jest to problem z zaufaniem w danym środowisku uruchomieniowym, a nie ustalenie dotyczące dostawcy. Widoczne jest tylko API modelu – oznacza to, że pozostałe kategorie są wyłączone lub uruchamiają się w odpowiedzi na zdarzenie, które nie zostało wywołane. Brak jakichkolwiek danych przy jednoczesnym poprawnym działaniu agenta – oznacza to, że klient ignoruje zmienne środowiskowe proxy lub przypina certyfikaty (certificate pinning), przez co żadne ustawienie aplikacji nie jest wiarygodne. Ten ostatni scenariusz jest najważniejszy i zmusza do powrotu do kroku 3, ponieważ przechwytywanie pakietów (packet capture) zawsze wykaże istniejące połączenie.

Kontrole, od najsłabszych do najsilniejszych

Ustawienia typu opt-out. Najtańsze i najsłabsze, ponieważ działają tylko wtedy, gdy dostawca je respektuje i obejmują one kategorie, które już istniały. Należy je ustawić tak, aby przetrwały restart i otwarcie nowego terminala, zapisując je w pliku ustawień użytkownika lub w profilu powłoki. Przy okazji warto dodać DO_NOT_TRACK=1: jest to konwencja respektowana przez wiele narzędzi wiersza poleceń, w tym niektóre agenty, a jej wdrożenie nie wiąże się z żadnym kosztem. Po każdej aktualizacji należy ponownie wykonać krok 3, ponieważ to właśnie wtedy zmienia się zakres ochrony.

Ograniczenie ruchu wychodzącego (egress). Na tym etapie kończy się prośba, a zaczyna wymuszanie. Agenta należy uruchamiać jako osobnego użytkownika, a następnie zezwolić temu użytkownikowi wyłącznie na ruch loopback oraz DNS, blokując resztę. Rozwiązanie to dodaje własną tablicę, dzięki czemu nie wpływa na istniejące reguły firewalla.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Regułę należy zastosować za pomocą sudo nft -f /etc/nftables.d/agent.nft, monitorować licznik za pomocą sudo nft list table inet agentegress, a odrzucenia sprawdzać poleceniem sudo journalctl -k -g agent-egress-drop. Rosnący licznik odrzuceń dla nieoczekiwanej nazwy hosta jest istotą tego mechanizmu. Istnieją dwa uczciwe ograniczenia. meta skuid dopasowuje się do użytkownika będącego właścicielem gniazda, więc działa tylko wtedy, gdy konto to nie może stać się innym użytkownikiem: bezhasłowe sudo dla agenta zmienia tę regułę w sugestię. Pozostawienie otwartego portu UDP 53 dla dowolnego serwera tworzy kanał, który może przesyłać dane w nazwach zapytań, więc należy go zamknąć, jeśli model zagrożeń tego wymaga, kierując resolver agenta na hosta zarządzanego przez administratora. Listy dozwolonych nazw hostów powinny znajdować się w proxy, a nie w nftables, ponieważ punkty końcowe API znajdują się za sieciami dostarczania treści (CDN), których adresy IP ulegają ciągłym zmianom. Kosztem tej kontroli jest ryzyko awarii i konieczność utrzymania: instalacje pakietów, git przez SSH oraz sprawdzanie aktualizacji przez samego agenta zakończą się niepowodzeniem, dopóki nie zostaną jawnie dozwolone, a lista ta staje się odpowiedzialnością administratora. W przypadku konfiguracji na serwerze, a nie na laptopie, ten sam układ konta i firewalla stanowi podstawę dla bezpiecznego uruchamiania Claude Code na VPS.

Maszyna jednorazowa. Agentowi należy przydzielić maszynę wirtualną (VM), która nie zawiera żadnych istotnych poświadczeń i jest niszczona po zakończeniu zadania. Nie ogranicza to ilości danych wysyłanych przez agenta, lecz ogranicza to, do czego agent ma dostęp, co zazwyczaj stanowi główne zagrożenie. Należy to łączyć z powyższymi regułami ruchu wychodzącego, ponieważ świeża maszyna wirtualna z nieograniczonym dostępem do Internetu nadal może połączyć się z każdym hostem w sieci. Metoda ta oraz stan, który należy każdorazowo odtwarzać, zostały opisane w uruchamianiu agentów programistycznych w jednorazowej maszynie wirtualnej, a kwestia doboru zasobów w uruchamianiu agenta programistycznego na VPS.

Samodzielne hostowanie modelu. Jedyna kontrola, która eliminuje przepływ danych do wnioskowania, ponieważ prompt nigdy nie opuszcza lokalnego sprzętu. Koszt jest realny: nie można samodzielnie hostować modelu zamkniętego, co oznacza konieczność wyboru modelu z otwartymi wagami i zaakceptowanie różnicy w możliwościach przy trudnych zadaniach, a także zapewnienie sprzętu do ich obsługi. Kompromisy te zostały omówione w możliwości samodzielnego hostowania Claude, a różnice w możliwościach głównych agentów w różnicach między Claude Code, Cursor, Codex i Copilot.

Żadna z tych czterech kontroli nie zmienia tego, co agent może odczytać z dysku, a ruch związany z wnioskowaniem przenosi wszystko, co agent odczyta. Jeśli plik .env znajduje się w katalogu roboczym, trafi on do modelu w momencie, gdy agent użyje polecenia grep w poszukiwaniu nazwy zmiennej. Utrzymanie takich materiałów poza zasięgiem jest osobnym zadaniem, opisanym w chronieniu sekretów przed kontekstem agenta AI.

Co należy sprawdzić po każdej aktualizacji

1. Porównaj strony ustawień producenta oraz wykorzystania danych z poprzednio zapisanymi informacjami, szukając nowych przełączników i nazwanych usług.
2. Odczytaj ponownie środowisko procesu z /proc/<pid>/environ, aby potwierdzić, że wykluczenia nadal są stosowane w uruchomionym procesie.
3. Ponownie wydrukuj pliki ustawień projektu, ponieważ git pull może wprowadzić plik konfiguracyjny zmieniony przez współpracownika.
4. Uruchom przechwytywanie SNI dla jednej pełnej sesji rzeczywistej pracy i porównaj listę nazw hostów z poprzednią.
5. Sprawdź licznik odrzuceń zapory sieciowej, ponieważ nowy cel zazwyczaj pojawia się tam, zanim zostanie zauważony gdziekolwiek indziej.

Zajmuje to około dziesięciu minut i jest jedyną częścią procesu, która nie traci na aktualności. Ustawienie domyślne zweryfikowane w sierpniu 2026 roku jest faktem dotyczącym sierpnia 2026 roku. Przechwycony ruch jest faktem dotyczącym dnia dzisiejszego.

FAQ

Czy mogę powstrzymać agenta programistycznego przed wysyłaniem mojego kodu do modelu?

Nie, a każde ustawienie, które rzekomo to umożliwia, opisuje inną funkcjonalność. Przesyłanie promptu, plików odczytanych przez agenta oraz wyników wykonanych przez niego poleceń do punktu końcowego modelu jest istotą procesu wnioskowania (inference), więc jedyną zmienną pozostaje odbiorca tych danych. Odbiorcę można zmienić, wskazując agentowi konto w chmurze firmy lub model hostowany samodzielnie, a zakres przesyłanych danych można ograniczyć poprzez zawężenie uprawnień do odczytu plików. Wyłączenie analityki i raportowania błędów nie wpływa w żaden sposób na ten przepływ danych.

Jak sprawdzić, z jakimi hostami łączy się mój agent programistyczny?

Uruchom agenta jako osobnego użytkownika w systemie Linux, a następnie przechwyć pakiety TLS ClientHello dla każdego nowego połączenia podczas pracy: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. Dla każdego połączenia pojawi się jedna linia zawierająca adres docelowy oraz żądaną nazwę hosta. Porównaj nazwy z sudo tcpdump -ni any 'udp port 53', przechwytując ruch na any, ponieważ lokalny resolver stub na 127.0.0.53 obsługuje zapytania w pierwszej kolejności. Przechwytywanie wykonaj podczas rzeczywistej pracy agenta, ponieważ pingi startowe i raporty o awariach nie pojawią się w przechwycie wykonanym w stanie bezczynności.

Mój proxy nie wykazuje ruchu, mimo że agent pracuje. Co poszło nie tak?

Klient ignoruje HTTP_PROXY oraz HTTPS_PROXY albo stosuje przypinanie certyfikatów (certificate pinning) i odrzuca Twój urząd certyfikacji (CA). Przetestuj ścieżkę za pomocą curl: jeśli curl łączy się z Internetem przez proxy, a agent nie pojawia się na liście przepływu, oznacza to, że agent nie korzysta ze zmiennych środowiskowych proxy. Niektóre środowiska uruchomieniowe wymagają dostarczenia certyfikatu CA w określony sposób; w szczególności Node odczytuje NODE_EXTRA_CA_CERTS tylko w momencie uruchomienia procesu, więc wyeksportowanie tej zmiennej po uruchomieniu agenta nie przyniesie efektu. Jeśli proxy nie widzi ruchu, należy przejść do przechwytywania pakietów, którego nie jest w stanie ominąć żadne ustawienie aplikacji.

Czy wyłączenie telemetrii powstrzymuje wykorzystanie mojego kodu do trenowania modelu?

Nie. Analityka i raportowanie awarii to przepływ danych odrębny od wnioskowania, więc ich wyłączenie usuwa jedynie liczniki użycia i ślady stosu (stack traces), pozostawiając każdy prompt przesyłany do modelu bez zmian. To, czy prompty są przechowywane i czy służą do trenowania przyszłych modeli, określają warunki Twojego planu subskrypcyjnego; plany konsumenckie i komercyjne zazwyczaj różnią się pod tym względem. Jest to kwestia zapisów umownych, a nie pakietów sieciowych, dlatego należy sprawdzić stronę dotyczącą wykorzystania danych dla danego planu i, jeśli ma to znaczenie, zawrzeć umowę komercyjną lub umowę o braku retencji danych (zero-retention) przed rozpoczęciem pierwszej sesji.