Gdy incydent AI dotyczy prompt injection, potrzebna jest jedna, powtarzalna struktura zapisu dowodu: co się stało, skąd przyszła instrukcja, jaki model i tool-call zadziałał, co ucierpiało i jak to zamknięto testem regresji. Ta strona opisuje POLA takiego pakietu — wyłącznie defensywnie. Nie publikujemy treści payloadów ataku; opis pól ma pomóc zespołowi blue udokumentować i zamknąć incydent.
Pakiet ma prostą zasadę: każde pole musi dać się zweryfikować (link, hash, wpis w audit-logu) albo być jawnie oznaczone jako niepotwierdzone. To ten sam kontrakt claim ≤ proof co w reszcie ipIII — struktura poniżej jest dziś szablonem (MVP), a nie zautomatyzowanym generatorem; automatyzacja emisji pakietu jest oznaczona jako ROADMAP.
Kolumna Wymóg: MUST pole obowiązkowe, bez niego pakiet niekompletny · SHOULD zalecane, brak trzeba uzasadnić. Data wersji szablonu: 2026-07-05 (F9, MVP).
| # | Pole | Co zapisuje | Jak weryfikowalne | Wymóg |
|---|---|---|---|---|
| 1 | kontekst context |
Gdzie i kiedy: aplikacja/usługa AI, środowisko (stg/prod), okno czasowe, rola użytkownika lub agenta, cel zadania w chwili incydentu. | Wpis w audit-logu z sygnaturą czasu; identyfikator sesji/konwersacji. | MUST |
| 2 | źródło source |
Skąd napłynęła instrukcja, która wywołała niepożądane zachowanie: kanał (prompt użytkownika, treść dokumentu, wynik narzędzia, dane z sieci — indirect injection). Opis kanału, nie treść payloadu. | Referencja do artefaktu (id dokumentu, url, hash treści) — bez cytowania samej instrukcji ataku. | MUST |
| 3 | model model |
Który model/wersja, parametry istotne dla powtarzalności (temperatura, system-prompt id — bez treści), warstwa guardrails aktywna w chwili zdarzenia. | Metadane wywołania z logu inferencji; wersjonowany identyfikator system-promptu. | MUST |
| 4 | tool-call tool_call |
Jakie narzędzie/funkcję model wywołał w efekcie i z jakimi zredagowanymi argumentami (sekrety i dane wrażliwe maskowane). Czy wywołanie było autoryzowane. | Wpis w logu orkiestratora narzędzi; flaga autoryzacji; zamaskowane argumenty (hash + redakcja). | MUST |
| 5 | wynik outcome |
Obserwowalny skutek: jakie działanie zostało wykonane lub jaka odpowiedź wygenerowana odbiegająca od polityki. Opis skutku, nie reprodukcja treści. | Zrzut z logu odpowiedzi (zredagowany), status wykonania akcji, korelacja czasowa z tool-call. | MUST |
| 6 | impacted-asset impacted_asset |
Co ucierpiało lub było zagrożone: system, dane, konto, integracja. Klasyfikacja wrażliwości i zasięg (jeden rekord vs zbiór). | Mapowanie na rejestr aktywów (asset id), poziom klasyfikacji, ocena zasięgu w audit-logu. | MUST |
| 7 | proof proof |
Dowód integralny: sha256 zebranych artefaktów, chain-of-custody (kto/kiedy zebrał), odnośniki do logów. Spina pola 1–6 w niezmienny pakiet. |
package_sha256 + łańcuch dozoru w bazie; weryfikacja przez /verify. |
MUST |
| 8 | remediation remediation |
Co wdrożono, by zamknąć podatność: filtr wejścia/wyjścia, ograniczenie uprawnień narzędzia, izolacja treści niezaufanej, zmiana system-promptu, human-in-the-loop dla wrażliwych akcji. | Odnośnik do zmiany (commit/ticket), data wdrożenia, właściciel. Powiązanie z playbookiem. | SHOULD |
| 9 | regression-test regression_test |
Test, który potwierdza, że po remediacji ten sam wektor już nie prowadzi do niepożądanego zachowania. Uruchamiany na danych syntetycznych, po RoE. | Identyfikator testu + wynik PASS/FAIL z sygnaturą czasu; retest zamyka incydent w orkiestratorze. | SHOULD |
Poniżej struktura pól z placeholderami. Wartości są syntetyczne — służą pokazaniu kształtu zapisu, nie odtworzeniu żadnego ataku. Pola source/tool_call/outcome przechowują opis i referencje, nigdy treść payloadu.
{
"pack": "prompt-injection-evidence",
"template_version": "F9-MVP-2026-07-05",
"incident_id": "AI-INC-<syntetyczny-id>",
"context": { "app": "<usługa-AI>", "env": "staging", "ts": "<ISO-8601>", "actor_role": "<rola>", "task": "<cel-zadania>" },
"source": { "channel": "indirect|direct", "artifact_ref": "<id/url>", "content_sha256": "<hash>", "note": "opis kanału, BEZ treści instrukcji" },
"model": { "name": "<model>", "version": "<wersja>", "system_prompt_id": "<id>", "guardrails": "<stan>" },
"tool_call": { "tool": "<narzędzie>", "args_redacted": "<zamaskowane>", "authorized": false, "log_ref": "<id>" },
"outcome": { "observed": "<opis-skutku>", "policy_deviation": true, "response_ref_redacted": "<id>" },
"impacted_asset": { "asset_id": "<id>", "classification": "<poziom>", "scope": "<zasięg>" },
"proof": { "package_sha256": "<hash>", "chain_of_custody": [ "<kto/kiedy>" ], "log_refs": [ "<id>" ] },
"remediation": { "change_ref": "<commit/ticket>", "type": "<kontrola>", "deployed_at": "<ISO-8601>", "owner": "<osoba>" },
"regression_test":{ "test_id": "<id>", "data": "synthetic", "result": "PASS|FAIL", "ts": "<ISO-8601>" }
}
incident_id i szkielet pakietu z pustymi polami.proof liczy package_sha256 i chain-of-custody; pakiet staje się niezmienny i weryfikowalny przez /verify.sha256 i chain-of-custody, tak samo jak reszta evidence w ipIII.
Powiązane: procedura reakcji krok po kroku → /playbook-prompt-injection · zgłoszenie incydentu AI → /ai-incident · weryfikacja integralności dowodu → /verify.