Jak czytać ślad audytowy

Audyt jest w dwóch miejscach: na stronie Logi audytowe w portalu, która pokazuje każdemu użytkownikowi jego własne wywołania, oraz w liniach JSON, które każdy komponent zapisuje na standardowe wyjście i które przesyłasz do swojego systemu logów.

Logi audytowe w portalu

Strona Logi audytowe wypisuje wywołania narzędzi zalogowanego użytkownika, od najnowszych. Dla administratorów jest taka sama: pokazuje tylko Twoje własne wywołania i żadnych wartości argumentów. Aby zobaczyć, co robili inni użytkownicy albo inni administratorzy, użyj linii logów (następna sekcja).

Filtry: Szukaj w logach, okres (Ostatnie 24 godziny, Ostatnie 7 dni, Ostatnie 30 dni) i grupa wyników (Wszystkie wyniki, Wykonane, Odmowy, Błędy, Potwierdzenia kodem). Kolumny: Czas, Klient, Narzędzie, Zasób, Filtr (filtr adresu /mcp, którego użył klient) i Wynik. Rozwiń wiersz, aby zobaczyć Błędne kody, Ryzyko, Kod błędu i Identyfikator żądania. Użytkownik podaje Ci identyfikator żądania, a Ty śledzisz po nim wywołanie.

Wyniki, które spotkasz:

Wynik	Znaczenie
Wykonano	Wywołanie przeszło
Odmowa (brak uprawnienia)	Użytkownik nie ma grupy do narzędzia
Odmowa (poza filtrem adresu)	Użytkownik ma uprawnienie, ale adres, którego użył klient, wyklucza narzędzie
Odmowa (polityka)	Polityka albo nadpisanie zabrania wywołania
Narzędzie wyłączone	Włączony jest wyłącznik awaryjny albo narzędzie nie jest zatwierdzone
Brak połączenia z systemem	Użytkownik nie połączył konta
Zbyt wiele wywołań	Limit
Wymaga potwierdzenia tożsamości	Wywołanie wymaga świeżego MFA
Czeka na potwierdzenie, Potwierdzone kodem, Wygasło, Błędny kod, Unieważnione, Anulowane, Zablokowane przez oczekującą	Etapy wywołania z ryzykiem Usuwanie, które wymaga kodu z Authenticatora (120 sekund, 3 próby)

Gateway domyślnie przechowuje tę aktywność przez 30 dni. Ustawienie należy do gatewaya.

Linie audytu w logach

Każdy komponent zapisuje jedną linię JSON na zdarzenie na standardowe wyjście. Gateway i broker używają loggera AUDIT. Portal i serwery używają pl.aiwcorpo.mcp.audit. Wszystkie linie jednego wywołania mają wspólny requestId. Platforma tylko zapisuje: retencja i wyszukiwanie należą do Twojego systemu logów.

W paczce Compose weź linie z kontenerów:

docker compose logs gateway mcp-credential-broker portal | grep <id-żądania>

Zwykłe wywołanie zostawia te linie:

Komponent	Zdarzenie	Mówi
gateway	policy_decision	Dozwolone albo odrzucone, z powodem i rewizją polityk
gateway	credential_resolve	Typ poświadczenia uzyskany z brokera i wynik
broker	credential_resolve	To samo wywołanie widziane z brokera (server to system docelowy)
gateway	confirmation	Etapy wywołania z ryzykiem Usuwanie
serwer	policy_decision, tool_call	Decyzja o rozwiązanym zasobie i wynik
gateway	tool_call	Wynik końcowy i opóźnienie

Typy zdarzeń:

Zdarzenie	Zapisuje	Rejestruje
tool_call	gateway, serwery	Wynik jednego wywołania
policy_decision	gateway, serwery	Decyzję autoryzacyjną
credential_resolve	gateway, broker	Uzyskanie poświadczenia
connection_change	broker, portal	Utworzenie, zastąpienie, odświeżenie lub usunięcie połączenia użytkownika, z backendUser, kontem w systemie docelowym
confirmation	gateway	Etapy potwierdzenia kodem
authenticator	broker, portal	Rejestrację, kody, blokady
admin_change	gateway, broker, portal	Zmiany w administracji
authentication	gateway, broker, serwery	Odrzucony token albo odrzucony certyfikat klienta

Każda linia ma ts, requestId, component, componentId, event, outcome (ok, error, denied) i, jeśli dotyczą, sub, username, client, server, tool, risk, resource, decision, reason, policyRevision, credentialType, errorCode i latencyMs.

Co zapisują zmiany w administracji

admin_change niesie sub administratora i reason:

Zmiana	reason
Serwer dodany, zmieniony, usunięty	server_created, server_updated (z changedFields, nigdy wartości), server_deleted
Połączenie zatwierdzone lub zaproponowane	server_connection_approved, server_connection_changed, z tlsMode i fingerprint
Polityki	policies_submitted, policies_approved, policies_changed
Definicja narzędzia	definition_submitted, definition_approved (z definitionHash, a przy klasyfikacji także risk i action), risk_lowered_by_admin
Mapowanie zakresów	scope_mapping_changed, scope_mapping_entry_removed, scope_mapping_entry_ignored
Nadpisanie	override_set, override_removed, override_invalid, override_rejected (z overrideId, overrideTarget i SHA-256 tekstu, nigdy samym tekstem)
Wyłącznik awaryjny	kill_switch_set, kill_switch_cleared
System	system_created, system_updated, system_deleted, connections_invalidated

Czego nigdy nie zapisujemy

Wartości argumentów, wyniki narzędzi, sekrety, tokeny, kody potwierdzeń, ziarna TOTP i tekst powodu wyłącznika nigdy nie trafiają do linii. Linia ma argsLength, długość argumentów, i nic więcej o nich. Znaki sterujące, U+2028 i U+2029 są w każdej wartości zamieniane na sekwencje ucieczki.

Powtarzające się odmowy tego samego rodzaju (nieprawidłowy filtr, wywołanie odrzucone z braku uprawnień) są zapisywane najwyżej raz na użytkownika, powód i cel w ciągu 10 sekund. Potem następuje zdarzenie podsumowujące z suppressedCount. Sama odmowa zawsze działa. Każda instancja ma własne okno, więc dwie instancje zapisują łącznie do dwóch zdarzeń.

Alerty, które warto mieć

Sygnał	Dlaczego
admin_change z kill_switch_set	Ktoś wyłączył serwer albo narzędzie
admin_change z risk_lowered_by_admin	Obniżono ryzyko
admin_change z definition_approved	Sprawdź, kto co zatwierdził, zwłaszcza definicję od działającego serwera
admin_change z server_connection_approved	Zaufano nowemu odciskowi
admin_change z override_set	Dodano regułę zakazu
Seria zdarzeń authentication	Komponent nie może weryfikować tokenów albo klient przedstawia zły certyfikat
tool_call z rate_limited_user dla jednego sub	Agent poza kontrolą albo zgadywanie
authenticator z authenticator_disabled	20 błędnych kodów: zgadujący agent albo roztargniony użytkownik
Miernik mcp_gateway_kill_switches_unreadable równy 1	Gateway nie czyta wyłączników i odrzuca każde wywołanie

Pełna lista pól i powodów jest w schemacie zdarzenia audytu w kontraktach (zobacz Kontrakty).