Dziesięć sposobów,
żeby agent zrobił coś, czego nie miał robić.

Dokument trafił do mnie w piątek po południu - nie najlepsza pora na osiemdziesięciostronicowe dokumenty ramowe, ale OWASP rzadko publikuje coś, czego nie warto przeczytać w weekend. Druga kawa, czerwony długopis, i następne trzy godziny spędziłem na marginesach PDF-u. W dyskusji o AI w polskich kancelariach od dwóch lat wraca argument, że "agentic AI to dla nas jeszcze za wcześnie". To było prawdziwe w 2024. W 2026 przestaje być prawdziwe, bo agentic AI przestaje być pytaniem technologicznym, a staje się pytaniem decyzji zakupowej - dostawcy coraz częściej nie oferują "klasycznego LLM chatbota", tylko "asystenta prawnego", który ma autonomię i narzędzia. OWASP AIVSS jest pierwszą poważną próbą uporządkowania tego, co dzisiaj może pójść źle.

O czym jest ten materiał

AIVSS (AI Vulnerability Scoring System) jest dzieckiem dwóch rodziców. Z jednej strony OWASP - społeczności odpowiedzialnej za referencyjne dla całej branży bezpieczeństwa dokumenty takie jak OWASP Top 10 dla aplikacji webowych czy OWASP Top 10 dla LLM. Z drugiej CVSS (Common Vulnerability Scoring System), od lat powszechnie używanego narzędzia do oceny pojedynczych podatności. AIVSS nie zastępuje CVSS, tylko go nadbudowuje - argument autorów jest taki, że klasyczny CVSS nie oddaje jednej fundamentalnej cechy agentic AI, którą nazywają zasadą amplifikacji (Amplification Principle): ta sama techniczna luka w systemie, który tylko odpowiada na pytania, znaczy co innego niż ta sama luka w systemie, który autonomicznie wykonuje akcje w imieniu użytkownika.

Dokument dzieli się na dwie części. Część pierwsza to katalog dziesięciu ryzyk rdzeniowych specyficznych dla agentic AI. Część druga to matematyka scoringu - formuła, która przyjmuje wynik CVSS v4.0 dla danej luki, mnoży go przez Threat Multiplier uwzględniający dziesięć amplification factors (od Tool Integration Depth przez Environmental Impact do Autonomy Level), a następnie redukuje Mitigation Factor. Osobno opisane są rubryki scoringowe, pasma severity, integracja z NIST AI RMF (Govern, Map, Measure, Manage) oraz mapping do siedmiowarstwowej architektury referencyjnej CSA MAESTRO. W załącznikach - JSON schema raportu, mapping do OWASP GenAI Top 10 dla 2026 i crosswalk do AIUC-1, wszystko gotowe do spięcia w istniejące workflow compliance.

Dziesięć ryzyk, których autorzy wybrali jako rdzeniowe, to lista krótka, ale nie przypadkowa:

1. Agentic AI Tool Misuse - agent używa narzędzia w sposób, do którego nie miał mieć uprawnień (wysyła maila, zapisuje plik, wywołuje API).
2. Agent Access Control Violation - agent obchodzi mechanizm kontroli dostępu, korzystając z tego, że jest uwierzytelniony w wielu systemach.
3. Agent Cascading Failures - jedna niewielka pomyłka na wczesnym kroku daje lawinę błędów w dalszych.
4. Agent Orchestration and Multi-Agent Exploitation - jeden agent wykorzystuje drugiego agenta, znając jego wzorce działania.
5. Agent Identity Impersonation - podszycie się pod agenta albo pod prawnika, w imieniu którego agent działa.
6. Agent Memory and Context Manipulation - podrzucenie do pamięci agenta danych, które później wpłyną na jego decyzje.
7. Insecure Agent Critical Systems Interaction - agent z dostępem do systemów krytycznych (finanse, kadry, dane klientów) robi coś poza zakresem.
8. Agent Supply Chain and Dependency Risk - skompromitowany model, wtyczka albo biblioteka.
9. Agent Untraceability - brak wiarygodnego audytu tego, co agent zrobił i dlaczego.
10. Agent Goal and Instruction Manipulation - podmiana celu lub instrukcji agenta przez osobę trzecią.

Lista czyta się jak katalog pułapek, które czekają na każdą kancelarię wdrażającą asystenta prawnego z dostępem do DMS, maila i kalendarza. I to nie w 2030. W 2026, z ofert, które już leżą w skrzynkach zarządów.

Recenzja właściwa

Perspektywa compliance i ochrony danych

AI Act w art. 15 wymaga od systemów wysokiego ryzyka "odpowiedniego poziomu accuracy, robustness i cybersecurity", przy czym nie definiuje, jak ten poziom mierzyć. RODO w art. 32 żąda "środków technicznych i organizacyjnych adekwatnych do ryzyka", również bez standardu miary. W obu przepisach regulator zostawia pole dla stanu techniki. AIVSS wchodzi w to pole jak klucz w zamek. Nie jest wiążący prawnie - ani w USA, ani w UE, ani w Polsce - ale w sądzie administracyjnym, w postępowaniu UODO albo w audycie krajowego organu AI Act, wynik AIVSS jest dokładnie tym, czym powinna być dokumentacja ryzyka: liczbowy, metodologicznie opisany, oparty na powszechnie uznanym frameworku społeczności bezpieczeństwa.

To oznacza praktyczną zmianę języka w rozmowie dostawca-kancelaria. Dotychczas pytanie brzmiało "czy wasz system jest bezpieczny", a odpowiedź "tak, mamy certyfikat ISO 27001 i szyfrowanie AES-256". Po AIVSS pytanie brzmi "jaki jest AIVSS score waszego deploymentu dla trzech naszych głównych use case'ów" - i dostawca, który nie potrafi odpowiedzieć, sam się dyskwalifikuje. W rozmowach z partnerami kancelarii słyszę, że dotychczas brakowało właśnie takiego wspólnego języka. Nie każdy partner zna CVSS v4.0, ale każdy zrozumie pojęcie "wynik ryzyka na skali 0-10, im niżej tym lepiej".

Perspektywa bezpiecznej architektury

Amplification Principle to nie jest akademicki kwiatek. Wziąć dowolne z klasycznych ryzyk OWASP dla aplikacji webowych - powiedzmy Injection (A03) - i zobaczyć, co się z nim stanie, gdy zamiast aplikacji mamy agenta. Klasyczna injection w aplikacji: atakujący wprowadza złośliwe zapytanie, otrzymuje dane. Ta sama injection w agencie z dostępem do maila klienta, kalendarza zarządu i systemu rozliczeń: atakujący wprowadza złośliwe instrukcje w jednym dokumencie, agent je czyta, sam wykonuje akcję w trzech systemach. Force multiplier.

W praktyce polskiej kancelarii wdrażającej agenta do przeglądu umów oznacza to, że Risk 6 (Memory and Context Manipulation) i Risk 10 (Goal and Instruction Manipulation) stają się potencjalnymi wektorami naruszenia tajemnicy zawodowej. Umowa klienta A, którą agent czyta w poniedziałek rano, może zawierać w sobie ukryte instrukcje (atak typu indirect prompt injection), które w piątek po południu spowodują, że agent odpowiadając na pytanie o sprawę klienta B wyciągnie kontekst klienta A. To nie jest scenariusz hipotetyczny. To jest scenariusz udokumentowany w literaturze od 2023 roku, a w dokumentach OWASP - od wersji 1.0 OWASP Top 10 dla LLM.

Drugi techniczny fragment, który warto przeczytać uważnie, to Risk 9 (Untraceability). Agentic AI podejmuje setki mikrodecyzji w ciągu jednego zadania: wybór narzędzia, wybór argumentu, wybór kontekstu, interpretacja wyniku. Jeśli log nie zawiera każdej z tych decyzji wraz z wersją modelu, treścią promptu, zawartością pamięci i zwróconą odpowiedzią narzędzia, to audyt po incydencie będzie niemożliwy. A bez audytu - w postępowaniu dyscyplinarnym czy przed UODO - kancelaria nie ma dowodu, że zachowała należytą staranność. AIVSS stawia Untraceability wysoko na liście celowo.

Czego autorzy nie dostrzegli: tajemnica zawodowa i polska skala

Jak w każdym dokumencie amerykańskiej proweniencji, słowo "tajemnica zawodowa" nie pada ani razu. Attorney-client privilege pojawia się w kontekście discovery, ale polska tajemnica adwokacka z art. 6 prawa o adwokaturze i radcowska z art. 3 ustawy o radcach prawnych - nie. To nie jest wada dokumentu, który nie jest pisany do polskich kancelarii. To jest luka, którą trzeba wypełnić przy interpretacji: każde z dziesięciu ryzyk w kontekście kancelarii trzeba czytać z osobnym pytaniem, co by się stało, gdyby to ryzyko dotknęło dokumentu objętego tajemnicą zawodową. Odpowiedź zwykle jest surowsza niż w amerykańskim modelu privilege, bo polska tajemnica jest konstruktem ustawowym, nie umownym.

Druga luka to problem skali. AIVSS jest pisane dla dużych organizacji z dedykowanymi zespołami AI governance. Pełne wdrożenie - ze scoringiem każdego wdrożenia, release gates, lifecycle integration, raportowaniem JSON do centralnego rejestru - wymaga co najmniej dwóch-trzech etatów kogoś z doświadczeniem w bezpieczeństwie aplikacyjnym. Kancelaria piętnastoosobowa takich etatów nie ma i mieć nie będzie. Dla niej AIVSS nie może być pełnym wdrożeniem. Może być dwiema rzeczami naraz: katalogiem ryzyk jako checklist przy wyborze dostawcy (dziesięć pytań, dziesięć odpowiedzi, minuta na każdą) oraz językiem rozmowy o ryzyku w rzeczywistym incydencie, gdyby się wydarzył.

Dziewiąty głos w kompozycji compound regime

Motyw wraca po raz dziewiąty. TOM 001 (Kenney) zbudował cross-walk regulacyjny. TOM 005 (Levy) pokazał lukę Model Rules. TOM 006 (MindForge) dał playbook operacyjny. TOM 007 (CETaS) handbook kryzysowy. TOM 008 (Bird & Bird) polski AI Act. TOM 009 (MIT) meta-taksonomię. TOM 010 (Boise) głos klienta. TOM 011 (NIST AI 800-4) opis ograniczeń monitoringu.

AIVSS wnosi dziewiąty głos - globalnej społeczności bezpieczeństwa aplikacyjnego. To głos, który nie występuje w polu prawniczym zwyczajowo, a który w 2026 staje się niezbędny. OWASP, CSA i NIST razem w jednym dokumencie to bardzo rzadki układ - branża security czasami między sobą konkuruje, a tutaj widzimy konsensus na skali, na jakiej go dotąd nie było. Dla kancelarii oznacza to, że kiedy dostawca mówi "nasz system jest bezpieczny", a nie jest w stanie pokazać, jak to mierzy po AIVSS, rozmowa jest krótka.

Druga warstwa: AIVSS spięty z TOM 011 (NIST AI 800-4) tworzy praktyczną parę. NIST mówi, czego dzisiaj nie umiemy monitorować. AIVSS mówi, jak scorować ryzyka, których nie umiemy monitorować. Razem dają odpowiedź na pytanie, które regulator kiedyś zada: "co zrobiliście, żeby zmierzyć ryzyko, którego w pełni nie da się monitorować". Odpowiedź: AIVSS score, udokumentowany, z jawnie wskazanymi amplification factors, plus decyzja zarządu kancelarii na piśmie.

Co z tego wynika

AIVSS trzeba przeczytać każdemu, kto podejmie w kancelarii decyzję o wdrożeniu agenta. Nie całość - Część 1 (dziesięć ryzyk) obowiązkowo, Część 2 (matematyka scoringu) w tej wersji, w jakiej się da przyswoić w dany weekend, reszta - w miarę potrzeb. Dokument jest po angielsku, napisany językiem security, bez znanych prawnikom punktów odniesienia, ale lista dziesięciu ryzyk sama w sobie jest wystarczająco konkretna, żeby zadziałała jako narzędzie rozmowy bez pełnego zrozumienia matematyki.

Dla kogo ten materiał. Dla compliance officerów kancelarii, partnerów odpowiedzialnych za technologię, IT directors, DPO podpisujących DPIA pod wdrożenia AI. Dla każdego dostawcy narzędzi AI dla prawników, bo klient prędzej czy później o AIVSS zapyta. Dla zarządów kancelarii, które planują pierwsze wdrożenie agenta.

Dla kogo nie. Dla kancelarii, która dzisiaj używa wyłącznie prostego asystenta do zadawania pytań - zastosowania, które nie uruchamiają autonomii agenta, są poza zakresem AIVSS, i zastosowanie tego frameworku do nich byłoby działaniem na wyrost. Ale uwaga: granica między "prostym asystentem" a "agentem" przesuwa się szybciej niż większość zarządów się spodziewa. Dostawca, który dziś oferuje proste wyszukiwanie, za sześć miesięcy zaktualizuje ofertę o function calling, tool use i memory - i od tego dnia jest w scope.