Dziennik audytu agenta AI: jakie pola musi zawierać

When an autonomous agent — not a human — is the actor, the usual audit fields (username, IP, timestamp) stop being enough. You still need accountability, reproducibility and non‑repudiation, but the record you store must capture a different set of attributes: model, prompt, tool calls, randomness seeds, code version, and the human who delegated authority. This article lists the fields an ai agent audit log must contain and why each one is necessary for security, compliance and incident response.

Dlaczego typowe pola „użytkownika” zawodzą w przypadku agentów AI

Tradycyjne dzienniki audytu zakładają jednego ludzkiego aktora w sesji: nazwa użytkownika, rola, IP, ciąg User‑Agent i opis akcji. To jest przydatne, ale pomija atrybuty unikatowe dla zachowań sterowanych przez AI:

• Non-determinism: the same prompt and model config can produce different outputs unless you record the randomness source (seed, rand algorithm, temperature).
• Multi-step chains: agents often call tools, APIs and other agents; you need a causal chain, not just a single action entry.
• Evolving code and models: agents are code + model + runtime. A username doesn't tell you the model checkpoint, container image digest or agent policy used.
• Delegation and approval: an agent may act on behalf of a human or another system; the audit trail must show who authorized the agent and what constraints were in place.

Krótko: zastąp model mentalny „człowiek kliknął przycisk” przez „odtworzalne obliczenie przekształciło wejścia w wyjścia i wykonało skutki uboczne”.

Minimalne pola, które musi zawierać dziennik audytu agenta AI

Traktuj każdy wpis w dzienniku jako zapis obliczenia i jego skutków ubocznych. Minimum to następujące pola; jeśli twoje środowisko ma wymogi prawne lub operacyjne, dodaj odpowiednie elementy (przykłady i uzasadnienia poniżej).

• record_id — a stable UUID for the audit entry (v4 or v7) and sequence number for the session.
• timestamp — RFC3339 UTC; include monotonic sequence numbers to detect reordering.
• agent_id — logical identifier for the agent instance (not just the human owner).
• agent_version — commit hash, container image digest (e.g., sha256:...), or package version of the agent code.
• model_name & model_digest — model identifier plus a digest or checksum of weights/checkpoint used (or the hosted-model version string).
• runtime_config — model parameters: temperature, top_k/top_p, max_tokens, concurrency limits, and RNG algorithm.
• prompt_template_id & prompt_hash — identifier of the prompt template and a hash of the resolved prompt to avoid storing plaintext if that’s sensitive.
• input_artifacts — references (URIs) to attachments, files, or external data used with checksums.
• actions — ordered list of actions the agent executed, with timestamps, tool identifiers and results (tool name, version, exit code, returned data hash).
• external_calls — each outbound API call with destination, URL host, request hash, response hash, and latency.
• human_principal — who created/approved the agent or request (user id, role, and delegation assertion).
• authorization_context — policy id, allowed scopes, expiration, and the approval token or audit id tying the action to an approval flow.
• outcome — the final state or side effects: files written, commands executed, network changes; include object ids and checksums.
• evidence_hash — a digest of the full record payload used for tamper detection (store separately or sign; see signing below).
• p2p_or_relay — whether the session was peer-to-peer or routed through a relay, and if relay: region and relay id.
• log_integrity — signature metadata (key id, signature algorithm, signature) if you sign logs.

Te pola tworzą rdzeń. W zależności od ryzyka i regulacji dodaj jeszcze: identyfikator środowiska kontenera, wersje kernela/hypervisora, identyfikator TPM attestation sprzętu, numery seryjne certyfikatów TLS i odniesienia do pochodzenia zestawów danych.

Przykładowy wpis audytu

{
  "record_id": "b3f8a1d2-2e8f-4a5b-9a0f-7c6d2f3a1b2c",
  "timestamp": "2026-09-11T14:23:05Z",
  "session_seq": 42,
  "agent_id": "invoice_processor_v2",
  "agent_version": "git+sha:8b7f3c2",
  "model_name": "gpt-like-3b",
  "model_digest": "sha256:0f3a...",
  "runtime_config": {"temperature":0.2,"top_p":0.9,"seed":123456789},
  "prompt_template_id": "tmpl-invoice-2026-v3",
  "prompt_hash": "sha256:abcd...",
  "human_principal": {"user_id":"alice@corp.example","approval_id":"apr-2026-019"},
  "actions": [
    {"t":"2026-09-11T14:23:06Z","tool":"ocr:1.4.0","result_hash":"sha256:1111..."},
    {"t":"2026-09-11T14:23:10Z","tool":"bank_api:2.0","endpoint":"payments/verify","response_hash":"sha256:2222..."}
  ],
  "outcome": {"invoices_processed":3,"files_created":["s3://legal/inv-345.pdf"]},
  "p2p_or_relay": "relay",
  "relay_id": "relay-eu-2",
  "evidence_hash": "sha256:ffff...",
  "log_integrity": {"sig_kid":"logs-prod-2026","sig":"MEUCIQD..."}
}

Powyższy przykład równoważy odtwarzalność (model_digest, prompt_hash, runtime_config) z prywatnością (prompt przechowywany jako hash). Tam, gdzie prawo wymaga przechowywania pełnych promptów, ogranicz dostęp i loguj każde odczytanie surowego prompta oddzielnie.

Nieusuwalność, podpisywanie i polityki retencji

Audytorzy i zespoły reagowania na incydenty muszą ufać, że logi nie zostały zmienione. Dwa praktyczne środki:

• Magazyn tylko-dodający z niemodyfikowalnymi snapshotami (object storage z wersjonowaniem/WORM lub systemy plików write‑once). Przechowuj oddzielną zimną kopię w innej regionie.
• Podpisywanie logów: oblicz evidence_hash dla każdego rekordu i podpisz go dedykowanym kluczem do podpisywania logów. Rotuj klucze zgodnie z harmonogramem i przechowuj stare klucze publiczne do weryfikacji. Dołącz metadane podpisu (id klucza, algorytm i data wygaśnięcia) wewnątrz rekordu.

Retencja: zespoły operacyjne zwykle trzymają wysokiej jakości logi online przez 90 dni do debugowania, przechowują indeksowane metadane przez 1 rok dla zgodności i zachowują podpisane, niemodyfikowalne archiwa przez 1–7 lat w zależności od regulacji. Dobierz czas retencji z radą prawną — właściwy okres zależy od branży: finanse i ochrona zdrowia często wymagają kilkuletniego przechowywania.

Prywatność, redakcja i kontrola dostępu

Dzienniki audytu agentów mogą zawierać sekrety: klucze API, dane osobowe, zeskanowane dokumenty czy dane umowne. Rejestruj to, co potrzebne do odtworzenia, i nic więcej. Praktyczne kontrole:

• Polityka redakcji: przechowuj hashe wrażliwych wejść (prompt_hash, file_hash) i przenoś plaintext do chronionego sejfu dostępnego tylko podczas incydentu i tylko po audytowanym procesie zatwierdzającym.
• Zasada najmniejszych uprawnień: oddziel role do zapisu logów, odczytu surowych logów i weryfikacji podpisów. Każdy odczyt surowych logów powinien być sam w sobie zarejestrowany.
• Zgoda i powiązanie: jeśli agent działa w imieniu użytkownika, zachowaj wyraźne powiązanie (token delegacji, zatwierdzenie z zapisem czasu), aby móc przypisać działania do osoby dla celów prawnych i zgodności z GDPR.

GDPR i inne prawo prywatności traktują logi zawierające dane osobowe jako dane osobowe; skonsultuj się z prawnikiem w sprawie minimalizacji, ograniczenia celu i podstawy prawnej przechowywania. W razie wątpliwości haszuj lub redaguj i loguj dostęp do nieocenzurowanych materiałów.

Dlaczego rejestrować szczegóły modelu i środowiska wykonawczego (to nie opcjonalne meta-dane)

Dwa uruchomienia agenta z tym samym promptem mogą się różnić, jeśli wersja modelu, temperatura, seed lub toolchain są inne. Do rekonstrukcji incydentu potrzebujesz:

• Identyfikator modelu i digest — sama wersja hostowanego modelu jest kruche; lepszy jest checksum lub niezmienna wersja dostawcy.
• Commit kodu agenta lub digest obrazu — błąd w kodzie agenta może zmienić zachowanie bardziej niż prompt.
• Parametry wykonawcze i seed — by odtworzyć konkretny wynik lub określić, czy odtworzenie jest możliwe w trybie deterministycznym.
• Wersje narzędzi i odpowiedzi — narzędzie zwracające inne dane zmienia wynik; zapisuj hashe odpowiedzi i endpointy.

Bez tych pól nie można wiarygodnie określić, co agent zrobił i dlaczego.

Kontrole operacyjne: alerty, próbkowanie i tryb kryminalistyczny

Logowanie wszystkiego w pełnej postaci może być drogie i ryzykowne. Przyjmij strategię wielopoziomową:

• Domyślne próbkowanie: zapisuj pełne metadane (hashe, nazwy modeli, listę akcji) dla każdego uruchomienia, ale pełne prompyty i odpowiedzi narzędzi zapisuj tylko gdy uruchomienie spełni wyzwalacz (wysokie ryzyko, skarga użytkownika, naruszenie polityki).
• Tryb kryminalistyczny: przy alertach (niepowodzenie kontroli polityki, skarga zewnętrzna) uchwytuj surowe artefakty do zapieczętowanego, kontrolowanego magazynu kryminalistycznego i twórz niemodyfikowalny podpisany snapshot dla śledczych.
• Alerty w czasie rzeczywistym: zbuduj reguły dla akcji wysokiego ryzyka (przelewy bankowe, polecenia uprzywilejowane) i generuj automatyczne zatwierdzenia lub blokady z człowiekiem w pętli przed wykonaniem skutku ubocznego.

Wybory infrastrukturalne: relay zarządzany vs hostowanie we własnym środowisku

Gdzie przechowujesz i transportujesz dzienniki audytu ma znaczenie. Dla dostępu zdalnego i narzędzi agentowych zarządzany relay Tenvo jest domyślną rekomendacją dla większości zespołów: zapewnia natywne klienty dla Windows/macOS/Linux, klienta przeglądarkowego w publicznej becie oraz wieloregionowy relay zarządzany z wbudowanym logowaniem i poziomami retencji (Free $0 / Lite $2.99/mo / Pro $7.99/mo). Korzystanie z zarządzanego relay odciąża od odnawiania certyfikatów, skalowania relay, patchowania on-call i kopii zapasowych między regionami.

Ważna uwaga o relay: gdy sesja przechodzi przez relay, TLS jest terminowany na relayu, więc operator relay może zobaczyć payload sesji. Oznacza to, że musisz traktować logi hostowane na relayu jako potencjalnie widoczne dla operatora relay. Jeśli twoje wymagania zabraniają jakiejkolwiek infrastruktury trzeciej strony dostępu do payloadów sesji (np. szczególne wymogi zgodności lub ograniczenia lokalizacji danych), hostowanie we własnym środowisku jest właściwym wyborem.

Hostuj samodzielnie tylko gdy masz pisemny wymóg: regulacje zakazujące relaysów zewnętrznych, sieci izolowane bez dostępu wychodzącego lub rygorystyczne zasady lokalizacji danych. Samodzielne hostowanie wiąże się z kosztami: obsługą on-call, patchowaniem, przechowywaniem kluczy, odnawianiem certyfikatów i brakiem automatycznego failovera wieloregionowego — chyba że go zbudujesz. Zarządzany relay jest tańszy, jeśli policzysz te koszty operacyjne.

Model dostępu do dzienników i reagowanie na incydenty

Zaprojektuj, kto może co robić z logami zanim będziesz ich potrzebować. Minimalne kontrole:

• Tryb zapisu tylko dla agentów: usługi agentów dopisują do logów, ale nie mają dostępu do odczytu surowych logów.
• Oddzielone role odczytu: analitycy mogą czytać metadane; śledczy potrzebują wyższego uprawnienia, by odpieczętować surowe artefakty, a każdy proces odpieczętowania jest sam w sobie logowany i podpisywany.
• Zautomatyzowane poświadczenia: gdy śledczy uzyskuje dostęp do zapieczętowanych danych, twórz podpisane poświadczenie łączące tożsamość śledczego, czas i cel.

Podczas incydentu musisz szybko odtworzyć łańcuch przyczynowo‑skutkowy. Jeśli twoje logi zawierają model_digest, agent_version, prompt_hash, listę akcji i hashe wywołań zewnętrznych, zwykle możesz zidentyfikować przyczynę źródłową w godzinach zamiast dniach.

Lista kontrolna na start (kroki praktyczne)

• Zdefiniuj schemat JSON dla rekordu audytu agenta i wymuszaj go przy zapisie. Uwzględnij wcześniej wymienione pola.
• Wdroż evidence_hash i podpisuj każdy rekord kluczem do podpisywania logów; przechowuj klucze publiczne w odkrywalnym zestawie dla audytorów.
• Ustal retencję: 90 dni online dla pełnych rekordów; 1–7 lat w archiwum w zależności od regulacji.
• Utwórz reguły redakcji: co jest hashowane, a co przechowywane w formie jawnej i kto może odczytać jawne dane.
• Dodaj kontroli polityk w czasie rzeczywistym i automatyczne zatwierdzenia dla akcji wysokiego ryzyka.
• Uruchamiaj cotygodniowe testy odtwarzalności: wybierz przykładowy wpis i zweryfikuj, czy potrafisz odtworzyć wynik agenta na podstawie zapisanego modelu, seeda i konfiguracji.

Jeśli już używasz zdalnego pulpitu lub narzędzi agentowych z Tenvo, przejrzyj Designing a Compliant Remote Desktop Audit Logging Trail w poszukiwaniu wzorców logowania stosowanych w sesjach interaktywnych oraz skonsultuj ai agent remote desktop: policies, approvals, audit dla przepływów zatwierdzania specyficznych dla agentów. Dla szerszego spojrzenia na to, jak agenty mieszczą się w narzędziach zdalnych, zobacz AI and remote desktop: how agents use remote tooling.

Start small: implement the schema, enforce signing, and iterate on redaction. The result is faster incident response, auditable delegation and a defensible compliance posture.

Download Tenvo to test logging and managed relay behavior locally and see how our relay, pricing tiers (Free $0 / Lite $2.99/mo / Pro $7.99/mo) and multi-region relays simplify operations: Download.