Ścieżka audytu agenta powinna odpowiedzieć na praktyczne pytanie: dlaczego dokładnie to działanie miało miejsce w tym konkretnym środowisku klienta? Zapisanie tylko transkrypcji czatu pozostawia luki. Zwięzły, ustrukturyzowany zapis może łączyć dowody wykorzystane przez agenta, propozycję, którą zobaczył recenzent, organ zatwierdzający i rzeczywisty wynik wdrożenia.
Zapisuj decyzje jako osobne zdarzenia
Przypisz stabilny identyfikator zmiany. Rejestruj czas pobierania danych wejściowych, dzierżawcę, identyfikatory źródła i odpowiednie skróty dowodów. Zapisz zalecenie i związaną z nim niepewność oddzielnie od proponowanej różnicy do odczytu maszynowego. Jeśli jest to konieczne, dołącz wersję modelu lub przepływu pracy do odtworzenia środowiska rozumowania, nie twierdząc, że ponowne uruchomienie modelu da identyczną prozę.
Zapisz tożsamość zatwierdzenia, zakres, wygaśnięcie i dokładny skrót propozycji. Następnie rejestruj próby wykonania, odpowiedzi backendu, obserwacje przed i po, wyniki weryfikacji i wszelkie decyzje o wycofaniu. Odmowa działań ma znaczenie: próba wykonania operacji przez niewłaściwego dzierżawcę może ujawnić defekt, nawet jeśli nie nastąpił żaden zapis.
Powiąż łańcuch bez zawyżania skrótów
Proponowany rekord zatwierdzenia może powiązać podsumowanie propozycji zawierające najemcę, strefę, nazwę rekordu, typ rekordu, operację, wartość przed, wartość po i wersję. Zaufana służba zatwierdzająca musi ustalić, kto ją zatwierdził; sam skrót nie może uwierzytelnić osoby zatwierdzającej. Nie pozwól, aby tekst raportu lub własne dane wyjściowe modelu utworzyły zdarzenie zatwierdzenia.
OWASP zaleca ograniczenie uprawnień agenta i niezależne kontrolowanie operacji o dużym wpływie. Przedstawiony tutaj projekt audytu jest oryginalnym operacyjnym zastosowaniem tej zasady, a nie zalecanym schematem zdarzeń OWASP. OWASP LLM06.
Zrekonstruuj hipotetyczny, nieudany wynik
Przypuszczać rekord zawiera pięć zdarzeń: pobranie danych wejściowych, propozycja, zatwierdzenie, próba zapisu i weryfikacja. Zdarzenie końcowe zgłasza, że autoryzowana obserwacja DNS odpowiada zamierzonej wartości, ale reprezentatywny komunikat nie spełnia wymagań wyrównanie sprawdzać. Zapisz osobno obserwację konfiguracji i warunek końcowy komunikatu o niepowodzeniu. Ani zatwierdzenie, ani pomyślna odpowiedź na zapis nie zamykają nieudanego wyniku. Są to zakładane zdarzenia, a nie wygenerowane logi lub rzeczywiste testy.
Projekt zdarzenia połączony z hashem przechowuje podsumowanie poprzedniego zdarzenia w każdym następnym zdarzeniu. Zmiana jednego zdarzenia i pozostawienie późniejszych linków bez zmian może ujawnić niespójność podczas weryfikacji. Aktor, który jest w stanie przepisać cały łańcuch, może ponownie obliczyć te połączenia, więc sam projekt nie jest niezmiennym dowodem. Chroń niezależny punkt kontrolny lub równoważną kontrolę integralności, oddziel dostęp i zachowaj pochodzenie. Nie przeprowadza się tutaj żadnego testu łańcucha mieszającego ani testu odporności na manipulacje.
Zachowaj przydatne dowody bez zbierania wszystkiego
Przechowuj minimalną ilość surowców potrzebnych do wyjaśnienia decyzji. Raporty uwierzytelniające i próbki wiadomości e-mail mogą zawierać informacje osobiste lub wrażliwe klienta. Trzymaj klucze prywatne, tokeny i dane uwierzytelniające poza dziennikami. Używaj odniesień do dowodów, zamiast powielać pełne komunikaty w każdym wydarzeniu, oraz stosuj kontrolę dostępu i przechowywania zarówno do oryginalnych, jak i pochodnych podsumowań.
Recenzent powinien być w stanie stwierdzić, czy obserwacja pochodzi z autorytatywnego zapytania DNS , rekurencyjnej pamięci podręcznej, odpowiedzi API dostawcy czy testu syntetycznego. Oznacz środowisko i typ dowodu. Brakujące dane wyjściowe to nieznany wynik, a nie pomyślna weryfikacja.
Zapewnij możliwość przeglądu i odzyskania danych
Dołącz identyfikator korelacji dla ponownych prób, aby przekroczenie limitu czasu nie wyglądało na drugą niezależną zmianę. Przed ponowną próbą niepewnego zapisu odczytaj bieżący stan i ustal, czy pierwsza próba została wykonana. Zapisz decyzję o pojednaniu. Chroń ścieżkę audytu przed tym samym agentem, który może zaproponować zmiany, i przetestuj, co się stanie, jeśli logowanie będzie niedostępne. W przypadku wrażliwych zmian zatrzymanie przed wykonaniem może być bezpieczniejsze niż utworzenie wyniku, którego nie można sprawdzić.