Audit trail dla agentów AI: kompletne logowanie odporne na manipulacje

Ścieżka audytu dla agentów AI to kompletny, odporny na manipulacje zapis wszystkich decyzji, wywołań narzędzi, dostępów do danych, operacji zapisu w pamięci i zatwierdzeń dokonanych przez człowieka w pracy agenta. Pozwala odtworzyć autonomiczne zachowanie na potrzeby analizy śledczej, spełnia regulacyjne obowiązki rejestrowania zdarzeń, a w razie szkody dostarcza dowodów na to, kto lub co wywołało daną akcję. W przeciwieństwie do klasycznego logowania aplikacji musi umożliwiać odtworzenie ścieżki decyzyjnej specyficznej dla agenta.

• Co jest logowane: prompt, wersja modelu/hash konfiguracji, sekwencja wywołań narzędzi z argumentami, zapytania wyszukiwawcze i identyfikatory dokumentów, output z uzasadnieniem, interwencje człowieka, zdarzenia pamięci, koszty i latencja.
• Jak chronić: pamięć WORM (Write-Once-Read-Many) i podpis kryptograficzny do wykrywania manipulacji; przeniesienie do SIEM poza zasięg agenta.
• Dlaczego to konieczne: obowiązki rejestrowania zdarzeń z unijnego AI Act, rozliczalność według RODO i analiza śledcza po incydentach, które eskalują szybciej, niż klasyczne reagowanie na incydenty jest w stanie je opanować.

Dlaczego agenci potrzebują własnej ścieżki audytu

Klasyczne aplikacje LLM tylko odpowiadają: prompt na wejściu, completion na wyjściu. Systemy agentowe natomiast planują, wnioskują, wybierają narzędzia, zapisują w pamięci i działają przy minimalnym zatwierdzaniu przez człowieka krok po kroku. Właśnie te cechy (autonomia, korzystanie z narzędzi i trwały stan) tworzą ścieżkę decyzyjną, której tradycyjne logi żądań i odpowiedzi nie odzwierciedlają.

W modelu OWASP dla aplikacji agentowych (ASI01–ASI10, opublikowanym 9 grudnia 2025 r.) identyfikowalność nie jest już osobnym ryzykiem z listy Top 10, lecz została wbudowana w cały model: dawny temat z wersji roboczej „Repudiation & Untraceability” mieści się dziś w ASI03 (Identity & Privilege Abuse) oraz w przekrojowych wymaganiach dotyczących logowania. Ścieżka audytu jest więc kontrolą przekrojową, która dopiero umożliwia wyjaśnienie kilku klas ryzyka.

Trzy przykłady z badań OWASP pokazują tę potrzebę:

• ASI06: Memory & Context Poisoning: jeden udany atak typu injection może na stałe zatruć pamięć trwałą; kluczowym sygnałem wykrywania jest to, że agent „pamięta” instrukcje, dla których nie istnieje żaden zapis pochodzenia. Bez logów opartych na pochodzeniu przeprowadzenie takiego dowodu jest niemożliwe.
• ASI08: Cascading Failures: według badań Galileo AI (grudzień 2025 r.) w symulacjach jeden skompromitowany agent zatruł 87% dalszych decyzji w ciągu 4 godzin, czyli szybciej, niż klasyczne reagowanie na incydenty jest w stanie to powstrzymać. Tylko kompletny log komunikacji między agentami pozwala odtworzyć przebieg rozprzestrzeniania się.
• ASI10: Rogue Agents: w zestawieniu threat-to-control „Audit” jest, obok ciągłych bazowych profili zachowań i kill switcha, jedną z kluczowych kontroli służących wykrywaniu utrzymującej się w czasie rozbieżności z zamierzonymi celami.

Co trzeba rejestrować

Badania OWASP (sekcja 7.6, Audit logging) definiują minimalny zakres śledczy dla każdej akcji agenta, czyli dla każdej pojedynczej akcji, a nie dla sesji:

Kluczowe są metadane pochodzenia: każdy wpis w pamięci powinien zawierać źródło, znacznik czasu, ścieżkę pozyskania danych i poziom pewności. Zapisy w pamięci są w logice OWASP zdarzeniami istotnymi dla bezpieczeństwa. Wpis trafia do pamięci trwałej wyłącznie w drodze jawnej, audytowanej operacji zapisu, nigdy niejawnie.

Odporność na manipulacje: WORM i podpis kryptograficzny

Ścieżka audytu jest tak wiarygodna, jak trwała jest jej niezmienność. Jeśli skompromitowany agent albo atakujący z jego uprawnieniami (ASI03: „atakujący dziedziczy uprawnienia agenta”) może później zmienić logi, ich wartość dowodowa w analizie śledczej przepada. Wzorce wskazane w badaniach:

• Pamięć WORM (Write-Once-Read-Many): niezmienne logi, których po zapisaniu nie można już modyfikować.
• Podpis kryptograficzny: każdy wpis w logu jest podpisywany, dzięki czemu manipulacja staje się wykrywalna (tamper detection).
• Integracja z SIEM: logi są przekazywane centralnie i znajdują się poza zasięgiem agenta oraz jego uprawnień do narzędzi.

W klasycznej logice zagrożeń STRIDE dotyczy to kategorii Repudiation (zaprzeczalność), która zostaje zachowana w adaptacji STRIDE for AI firmy Microsoft. Dodatkowo: jeśli logowane są wykonania kodu, w ścieżce powinny znaleźć się również zapisy do plików konfiguracyjnych poza standardowym zarządzaniem zmianami oraz uruchamianie podprocesów (sygnały wykrywania z ASI05).

Dlaczego to konieczne: obowiązek logowania, rozliczalność, analiza śledcza

Presja regulacyjna ma trzy źródła. Po pierwsze, unijny AI Act wymaga w przypadku systemów AI wysokiego ryzyka automatycznego rejestrowania zdarzeń przez cały cykl życia (rejestrowanie zdarzeń, art. 12), uzupełnionego o art. 14 (nadzór ze strony człowieka) i obowiązek monitorowania po wprowadzeniu do obrotu z art. 72. Zgodnie z pakietem Digital Omnibus (rozporządzenie (UE) 2026/1744) art. 12 i art. 14 mają zastosowanie dopiero od 2 grudnia 2027 r. do systemów z załącznika III i od 2 sierpnia 2028 r. do systemów z załącznika I. Badania OWASP przypisują ponadto ryzyka agentowe do art. 15 (solidność, cyberbezpieczeństwo) i stwierdzają, że podmioty stosujące muszą czytać katalogi zagrożeń w stylu OWASP oprócz art. 15, ponieważ według stanu na maj 2026 r. normy zharmonizowane nie zamykają jeszcze wielu luk.

Po drugie, zasada rozliczalności RODO (art. 5 ust. 2, art. 24) wymaga wykazania odpowiednich środków technicznych i organizacyjnych, w tym bezpieczeństwa przetwarzania zgodnie z art. 32. Badania wiążą kilka ryzyk bezpośrednio z RODO. Przypisują przy tym ASI03 do art. 32 ust. 1 lit. b (poufność i integralność systemów) oraz do zasady działania na polecenie z art. 32 ust. 4. Przepis ten dotyczy osób fizycznych działających z upoważnienia administratora lub podmiotu przetwarzającego. W odniesieniu do agenta oznacza to, że może on działać wyłącznie w granicach poleceń administratora, ale sam nie jest podmiotem przetwarzającym. Z art. 5 ust. 1 lit. d (prawidłowość) i art. 17 (prawo do usunięcia danych) badania wiążą ASI06. Procesy usuwania danych z pamięci muszą więc być zgodne z art. 17, a właśnie to również trzeba udokumentować.

Po trzecie, ścieżka audytu dostarcza materiału do analizy śledczej. W incydencie Manufacturing Procurement Cascade (2025) agent zakupowy był przez trzy tygodnie stopniowo przekonywany, że jego limit autoryzacji wynosi 500 000 USD; następnie atakujący złożył fałszywe zamówienia na 5 milionów USD w 10 transakcjach. Dopiero kompletna ścieżka zapisów w pamięci, wywołań narzędzi i zdarzeń interwencji człowieka pozwala wstecznie odtworzyć taki przebieg w stylu „gotowanej żaby” i sprawdzić łańcuch zatwierdzeń przez ludzi.

W branżach regulowanych w Austrii i Niemczech dochodzą do tego dodatkowe wymogi unijne: NIS2 (kontrola dostępu i zarządzanie aktywami, art. 21 ust. 2 lit. i) oraz DORA z zarządzaniem incydentami ICT i ich zgłaszaniem (art. 17–23) dla podmiotów świadczących usługi finansowe. W ramach ISO/IEC 42001 ścieżka audytu jest zakotwiczona w kontroli A.6.2.8 (logowanie), uzupełnionej o A.6.2.6 (eksploatacja i monitorowanie).

Okres przechowywania według branży

Unijny AI Act wyznacza dolną granicę dla systemów AI wysokiego ryzyka: dostawcy (art. 19 ust. 1) i podmioty stosujące (art. 26 ust. 6) muszą przechowywać automatycznie generowane logi, w zakresie, w jakim znajdują się one pod ich kontrolą, przez co najmniej sześć miesięcy, o ile prawo Unii lub prawo krajowe nie stanowi inaczej. Do tego dochodzą terminy sektorowe:

Ten artykuł nie stanowi porady prawnej. Konkretne terminy, właściwe numery artykułów i obowiązki sektorowe ustalasz indywidualnie ze swoim działem prawnym i compliance.

Przykład z praktyki: rekord audytowy akcji narzędzia

Tak mógłby wyglądać w pseudokodzie pojedynczy wpis, podpisany i zapisany w pamięci WORM. Każde pole odpowiada minimalnemu standardowi OWASP:

```
audit_event {
event_id: "a1f9-…" // unikalny, część podpisu
agent_id: "procurement-agent-07" // ASI03: Non-Human Identity
timestamp: 2026-06-09T08:14:22Z
model: { version, config_hash }
prompt: { user, system, injected_context }
retrieval: [ { query, doc_ids[] } ]
tool_call: { name: "create_purchase_order",
args: { amount: 5_000_000, vendor: "…" } }
rationale: "Order aligns with stored authorization limit"
memory_read: [ { key: "auth_limit", provenance: NULL } ] // <- alarm
human_override: { approver: "none", action: "auto-approved" } // <- alarm
cost: { tokens, usd }
signature: "sig:…" // kryptograficzne wykrywanie manipulacji
}
```

Dwa pola są tu prawdziwymi perełkami dla analizy śledczej: odczyt pamięci z provenance: NULL pokazuje, że wartość autoryzacji nie ma możliwego do wykazania pochodzenia (sygnał ASI06), a brak interwencji człowieka przy transakcji na 5 mln dowodzi obejścia bramki zatwierdzania (ASI09). Bez tych pól incydentu nie dałoby się wyjaśnić.

Dla agencji i decydentów B2B

Kto wprowadza agentów do procesów produkcyjnych, przesuwa ciężar odpowiedzialności i dowodu: w sporze lub podczas kontroli liczy się to, co zostało w sposób możliwy do wykazania zapisane w logach. Agencje marketingowe, które budują dla klientów workflowy oparte na agentach, powinny od początku traktować ścieżki audytu jako wymóg architektoniczny, a nie jako dodane później logowanie. Blck Alpaca z Wiednia pomaga firmom w całej Europie projektować systemy agentowe ze ścieżkami audytu o wysokiej wartości dowodowej, zgodnymi z OWASP i ISO 42001, od metadanych pochodzenia, przez pamięć WORM, po integrację z SIEM. Dzięki temu autonomia pozostaje możliwa do prześledzenia i gotowa na każdy audyt.