OWASP: stan bezpieczeństwa i governance agentów AI 2026.
Czego uczy się kancelaria, która buduje własnego agenta.

O czym jest ten dokument

OWASP GenAI Security Project działa pod parasolem OWASP Foundation, vendor-neutral, finansowany przez kilkudziesięciu sponsorów (hyperscalerzy, dostawcy cybersec, sektor finansowy). Raport v2.01 jest rozbudowaną drugą edycją: wprowadza analizę zagrożeń opartą na udokumentowanych incydentach, nowy rozdział o relacji AI Safety i AI Security, tracker realnych incydentów spięty z OWASP Top 10 for Agentic Applications, model dojrzałości adopcji i osobne rozdziały o tożsamości agenta oraz o AI SBOM. Ekosystem opisano na podstawie telemetrii z 53 śledzonych projektów agentowych, a krajobraz regulacyjny obejmuje 42 instrumenty w 10 jurysdykcjach.

Dla nas to materiał pierwszej potrzeby, bo pierwszy raz ktoś autorytatywny opisuje nie „AI w ogóle”, lecz agenta: byt, który rozumuje, deleguje zadania innym agentom, odkrywa narzędzia w trakcie działania i wykonuje akcje na produkcyjnych systemach.

Licencja CC BY-SA 4.0 (Attribution-ShareAlike) jest istotna operacyjnie. Wolno cytować, adaptować i używać komercyjnie, ale share-alike znaczy, że dzieło pochodne musi wyjść pod tą samą licencją. Ta recenzja opiera się na prawie cytatu (art. 29 prawa autorskiego), więc interpretacja MateMatic pozostaje nasza; własne tabele i ujęcia poniżej nie są przeróbką tabel OWASP, lecz naszą syntezą pod polską kancelarię. Oryginalny PDF hostujemy lokalnie z atrybucją do OWASP GenAI Security Project (przycisk „Pobierz oryginał” powyżej).

Recenzja właściwa

Trzy ustalenia, które trzeba przyjąć

Pierwsze: zagrożenia są realne teraz. Lista architektonicznych obaw z 2025 roku ma dziś incydenty, advisory i CVE. Druga edycja kuratoruje je w trackerze, więc model zagrożeń przestał być hipotetyczny.

Drugie, najważniejsze koncepcyjnie: safety i security zlewają się na warstwie wdrożenia. Przez większość historii oprogramowania bezpieczeństwo w sensie safety (czy system robi to, co powinien) i security (czy ktoś go nie obróci przeciw nam) były osobnymi dyscyplinami osobnych zespołów. Agent to zaciera. Cytuję tezę raportu: gdy agent działa na produkcyjnych systemach, te same kontrole rządzą oboma rodzajami szkody, a to samo dochodzenie odsłania obie przyczyny. Bezpieczeństwo modelu zostaje u dostawcy, ale warstwa wdrożenia (architektura, uprawnienia, konfiguracja, kontrole operacyjne) jest wspólna. Wniosek autorów jest bezpośredni: AI Safety i AI Security nie mogą dłużej działać jako równoległe funkcje.

Trzecie: governance musi nadążyć za wdrożeniem. Regulatorzy przyjęli założenie, że agent wyrządza szkodę szybciej, niż człowiek zdąży ją przejrzeć. Stąd skompresowane terminy zgłoszeń: DORA 4 godziny, NIS2 24 godziny wczesnego ostrzeżenia, nowojorski RAISE Act 72 godziny, kalifornijski SB 53 15 dni. To zakłada ciągły nadzór nad zachowaniem agenta, nie audyt raz na kwartał.

Prompt injection to wciąż nierozwiązany fundament

Raport stawia prompt injection (LLM01:2025) jako technikę leżącą pod niemal każdą klasą ataku i mapującą się na sześć z dziesięciu kategorii OWASP Top 10 for Agentic. Przyczyna jest architektoniczna i warto ją znać dosłownie: model językowy zlewa warstwę danych i warstwę sterowania w jeden strumień tokenów. System prompt, polecenie użytkownika i treść pobrana z zewnątrz są przetwarzane z tą samą wagą, bez mechanizmu egzekwującego granicę uprawnień między nimi. Kto wstrzyknie instrukcję w dowolne źródło, które agent czyta, nadaje jej wagę legalnego polecenia.

Dwie potwierdzone podatności pokazują wzorzec. CVE-2026-22708 (Cursor, styczeń 2026): atakujący wpływający na instrukcje agenta zatruwa środowisko tak, że już zatwierdzone przez allowlist komendy wykonują dowolny kod. Raport ujmuje to celnie: allowlista nie zawodzi w blokowaniu ataku, ona go usprawnia, bo automatycznie akceptuje dokładnie te komendy, których potrzebuje napastnik. CVE-2025-59532 (OpenAI Codex CLI): output agenta redefiniował granicę zapisu sandboxa. Do tego incydenty bez adwersarza i z nim na tej samej architekturze uprawnień: agent kasujący produkcyjną bazę wbrew instrukcji zamrożenia kodu (Replit) oraz hackerbot-claw (luty 2026), autonomiczny bot zbudowany jako broń, który po starcie działał bez człowieka.

Tożsamość agenta jako nowa płaszczyzna kontroli

To rozdział, który dla budującego agenta jest najcenniejszy. Raport rozdziela dwa pojęcia, które rynek myli na własną szkodę. NHI (Non-Human Identity) to prymityw uwierzytelnienia: statyczne konta serwisowe, klucze API. Odpowiada na pytanie „czy to poświadczenie może się połączyć”. Agent Identity to ramka governance: odpowiada na pytanie „co posiadacz robi z tym uprawnieniem, w sposób ciągły”. NHI bramkuje tożsamość na początku sesji; Agent Identity musi rządzić zachowaniem w momencie każdej akcji.

Solidna tożsamość agenta wymaga trzech asercji kryptograficznych: provenance (integralność agenta), attestation (potwierdzenie tożsamości) i intent (zamiar). Do tego uprawnienia just-in-time zamiast stałych, łańcuchy delegacji zachowujące kontekst pierwotnego użytkownika i, co dla nas ważne, identity chaining przy wywołaniach przez protokół MCP: token musi kryptograficznie wiązać żądanie z pierwotnym principałem, żeby zapobiec atakom typu confused deputy (token exchange wg RFC 8693). Skala problemu jest już mierzalna: według raportu Entro Security tożsamości nieludzkie przewyższają ludzi w typowej organizacji w stosunku 100 do 1 (miejscami 500 do 1), 97 procent z nich ma nadmiarowe uprawnienia, a 71 procent nie jest rotowanych w zalecanym czasie. Ryzyko, które trafia w sedno wdrożeń: ghost agents, czyli agenty powołane do zadania i nigdy nie wyrejestrowane, które zostają z ważną tożsamością jak uśpione tylne wejście.

Model dojrzałości: dwa wymiary

Raport proponuje siatkę dwuwymiarową, która jest dla zarządu i compliance najbardziej użytecznym narzędziem w całym dokumencie. Pierwszy wymiar to tier adopcji (od AT0 do AT8): co właściwie wdrażamy. AT0 to Shadow AI, czyli nieusankcjonowane użycie, które większość organizacji ma, zanim cokolwiek świadomie wdroży. Skala rośnie przez asystentów wbudowanych u dostawcy (AT1), platformy (AT2), agentów low-code (AT3), agentów wykonujących kod (AT4), aż po trzy tiery, które są naszym terenem: AT5 (agent zbudowany u siebie, własna tożsamość, narzędzia i granice, raport wymienia tu wprost agentów na własnym stosie inferencji, Ollama i vLLM), AT6 (agent rozszerzony o zewnętrzne narzędzia, raport wymienia agentów z serwerami MCP) i wyżej AT7 (orkiestracja wielu agentów) oraz AT8 (federacja przez granice organizacji).

Drugi wymiar to dojrzałość governance (od poziomu 0 do 4): jak dobrze potrafimy tym rządzić. Poziom 2 to polityki mapujące zastosowania na AI Act i RODO, obowiązkowy człowiek w pętli dla decyzji wysokiego wpływu, wyznaczony właściciel (np. CAIO) i AI SBOM. Poziom 3 to monitoring w czasie rzeczywistym, wykrywanie anomalii, kill switche i governance jako kod. Poziom 4 to samoregulujące się polityki. Zasada raportu: dojrzałość governance traktować jako twardą bramkę wdrożenia, a nie ozdobę. Stoi za tym liczba: według badania CSA z 2026 roku tylko 27 procent organizacji planujących wdrożenia agentowe czuje się pewnie co do ich zabezpieczenia.

Od statycznej zgodności do governance w czasie rzeczywistym

Najmocniejsza myśl regulacyjna raportu: certyfikacja przedwdrożeniowa traci wartość w chwili, gdy agent zaczyna gromadzić kontekst, ładować narzędzia w trakcie działania albo modyfikować własną konfigurację. Regulatorzy już to dostrzegają. Artykuł 72 AI Act wymaga od dostawcy systemu wysokiego ryzyka aktywnego, systematycznego monitorowania działania przez cały cykl życia, co dla agentów funkcjonalnie znaczy wykrywanie dryfu, choć ustawa nie używa tego słowa. Artykuł 26 nakłada pokrewne obowiązki na podmiot wdrażający (deployera). Raport wskazuje cztery zdolności, których większości organizacji brakuje: monitoring zachowania w czasie rzeczywistym z wykrywaniem rozbieżności między deklarowanym a faktycznym planem działania; autoryzacja świadoma konsekwencji (ocenia, co agent robi, zamiast dziedziczyć uprawnienia operatora); automatyczna klasyfikacja incydentu pod skompresowane terminy zgłoszeń; oraz wyjaśnialność na poziomie całej trajektorii działania.

Praktyczny szczegół, który widać już w narzędziach: główne frameworki orkiestracji (LangGraph, OpenAI Agents SDK, Google ADK, a także Claude Code) zbiegły się na wzorcu deterministycznych punktów przechwytujących akcję agenta w kodzie, przed wywołaniem narzędzia, po wykonaniu i na granicy delegacji. Raport jest uczciwy: te haki działają lepiej jako warstwa wczesnego ostrzegania niż jako twarda granica bezpieczeństwa, a kierowanie decyzji do człowieka rodzi zmęczenie decyzyjne i hurtowe zatwierdzanie.

Co pozostaje nierozwiązane

Raport nie udaje, że ma odpowiedzi. Trzy problemy strukturalne zostają otwarte. Model zapewnienia (assurance) nie pasuje do natury agenta: dokumentacja opisuje system z chwili oceny, a agent komponuje zachowanie w trakcie działania. Nadzór człowieka przy prędkości maszyny jest fizycznie niemożliwy, co raport ilustruje arytmetyką: jeśli agent wykonuje 10 tysięcy akcji na godzinę, a recenzent ocenia 50, nadzór pokrywa pół procenta decyzji. I fragmentacja regulacyjna: w USA ponad 145 stanowych ustaw AI z 2025 roku, a w UE jeden incydent agentowy potrafi naraz odpalić AI Act, NIS2 i DORA z różnymi terminami i adresatami.

Do tego jeden wątek, który dla zarządu jest twardszy niż każdy compliance: zapaść ubezpieczeń. W USA od stycznia 2026 weszły wyłączenia AI w standardowych polisach (m.in. ISO CGL, absolutne wyłączenie AI u WR Berkley w polisach D&O i E&O). W UE wycofanie dyrektywy o odpowiedzialności za AI zostawia jako główny mechanizm znowelizowaną dyrektywę o odpowiedzialności za produkt (od grudnia 2026, odpowiedzialność na zasadzie ryzyka). Powstaje wąski rynek dedykowanych ubezpieczeń AI, ale każdy z tych ubezpieczycieli wymaga wykazanej governance jako warunku objęcia ochroną. Zdanie raportu, które trzeba zapamiętać: postawa bezpieczeństwa zaczyna wprost decydować o ubezpieczalności.

Czego autorzy nie powiedzieli, a co musi powiedzieć polski prawnik

W całym raporcie Polska nie pada ani razu. To nie zarzut, to nasza luka do wypełnienia. Cztery linie.

Pierwsza linia. PATRON i polska kancelaria to wprost tier AT5 i AT6. Raport własnymi słowami wymienia agentów na własnym stosie inferencji (Ollama, vLLM) oraz agentów z serwerami MCP. To dokładnie architektura, którą budujemy i którą rekomendujemy kancelariom związanym tajemnicą zawodową. Wniosek nie jest miły, ale jest uczciwy: model zagrożeń z tego raportu to nasz model zagrożeń, nie cudzy. Lokalne uruchomienie modelu rozwiązuje pytanie o egress danych (i to realnie), ale nie zwalnia z tożsamości agenta, kontroli uprawnień narzędzi MCP ani z runtime governance. Zero-cloud zamyka jedne drzwi, te trzy zostają otwarte i trzeba je domknąć osobno.

Druga linia. Artykuł 72 i artykuł 12 AI Act spotykają się z tajemnicą zawodową. Runtime monitoring z artykułu 72 i rejestrowanie zdarzeń z artykułu 12 to dla agenta prawniczego nie biurokracja, lecz warunek wykazania należytej staranności. Agent, który czyta akta, musi zostawiać odtwarzalny ślad: na jakiej podstawie podjął krok, jakie narzędzie wywołał, jaki dokument pobrał. Bez tego nie ma jak udowodnić, że nie doszło do naruszenia tajemnicy (art. 6 prawa o adwokaturze, art. 3 ustawy o radcach prawnych), a samo „działa lokalnie” tego nie dowodzi. To ten sam wektor, który opisujemy jako wykazanie zgodności przy polskiej ustawie o systemach AI uchwalonej w tym samym tygodniu.

Trzecia linia. DORA i NIS2 dotykają polskiego sektora regulowanego i kancelarii, które go obsługują. Skompresowane terminy zgłoszeń (DORA 4 godziny, NIS2 24 godziny) zakładają, że organizacja potrafi automatycznie sklasyfikować incydent agentowy w sekundach. Kancelaria doradzająca bankowi albo podmiotowi infrastruktury krytycznej musi rozumieć, że wdrożenie agenta po stronie klienta uruchamia te zegary, a manualna triaga ich nie dotrzyma.

Czwarta linia. Ubezpieczalność jako argument dla zarządu. „Postawa bezpieczeństwa decyduje o ubezpieczalności” to zdanie, które trafia do partnera zarządzającego mocniej niż każdy artykuł rozporządzenia. Governance agenta przestaje być kosztem zgodności, a staje się warunkiem zachowania ochrony ubezpieczeniowej. To język, którym warto rozmawiać z zarządem o tym, dlaczego nie wdraża się agenta bez nadzoru.

Słabsze strony dokumentu

Trzy zarzuty uczciwie. Pierwszy, raport jest mocno amerykański w warstwie regulacyjnej. Operuje na NY RAISE Act, CA SB 53, Colorado SB 24-205 i 145 stanowych ustawach; AI Act, DORA i NIS2 są obecne, ale europejski enforcement potraktowano cieniej niż amerykański krajobraz. Polski i unijny czytelnik musi sam zejść w konkrety obowiązków deployera i providera.

Drugi, to mega-dokument. Treść sięga 139 stron z sześcioma załącznikami (taksonomia, krajobraz regulacyjny, klasy ryzyka, projekty, CTF szkoleniowy, top 10 dla agentów osobistych). Dla praktyka to znaczy, że trzeba czytać selektywnie, bo lektura całości jest zadaniem na dni, nie godziny.

Trzeci, brak scenariuszy z domeny prawniczej. Przykłady są inżynierskie i korporacyjne (coding agents, copiloty enterprise, OT/ICS). Analogię do kancelarii (agent w obiegu akt, RAG na orzecznictwie, agent klasyfikujący pisma) trzeba zbudować samodzielnie, co poniżej robimy w tabeli.

Co z tego wynika

Najcenniejsze w tym raporcie nie są pojedyncze zagrożenia, lecz siatka, która pozwala uczciwie powiedzieć, gdzie się jest. Poniżej nasze ujęcie tej siatki przełożone na polską kancelarię (synteza MateMatic, nie kopia tabeli OWASP).

Reguła jest prosta: im wyżej w kolumnie pierwszej, tym wyższa wymagana dojrzałość w kolumnie trzeciej, a wdrożenie bez tej dojrzałości to nie odwaga, tylko niezabezpieczone ryzyko. Raport OWASP daje na to autorytatywny język i twarde dowody. Polski kontekst, tajemnicę zawodową i mapę na AI Act trzeba dołożyć samemu, i właśnie po to jest ta recenzja.

Materiał jest do przeczytania przez osobę odpowiedzialną za wdrożenie AI w kancelarii i przez szefa LegalTech, nie przez zarząd w całości. Zarząd dostaje siatkę dojrzałości, zdanie o ubezpieczalności i decyzję: na którym tierze jesteśmy i czy nasza governance go udźwignie.