JPMorgan Chase i AI: 10-krotny skok podatności kodu

Masowe wdrażanie autonomicznych agentów programistycznych, takich jak Claude Code czy Cursor, drastically przyspiesza tworzenie kodu, ale buduje zarazem krytyczny dług bezpieczeństwa w sektorze regulowanym. Doświadczenia z przeszkolenia ponad 600 inżynierów w JPMorgan Chase oraz badania na próbie 100 modeli LLM pokazują, że aż 45% generowanych próbek wprowadza podatności z listy OWASP Top 10, a przy 3-4-krotnym wzroście liczby commitów liczba luk rośnie aż dziesięciokrotnie. Aby uniknąć paraliżu operacyjnego, zespoły platformowe muszą przejść od bezrefleksyjnego „vibe codingu” do architektury wielopoziomowych reguł i nadzoru dostosowanego do ryzyka.

Pułapka prędkości w JPMorgan Chase: 10-krotny wzrost luk w kodzie

Narzędzia autonomicznego kodowania, takie jak Claude Code, GitHub Copilot czy Cursor, przekształciły proste podpowiadanie wiersza kodu w wielokrokowe wykonywanie zadań programistycznych. Programiści generują kod od 3 do 4 razy szybciej, jednak generatory LLM tworzą zarazem krytyczny dług bezpieczeństwa w bazach produkcyjnych, wzmacniając architektoniczne luki. Liderzy IT w sektorze regulowanym stają przed wyzwaniem opanowania tej skali bez dławienia wydajności.

Według raportu DORA 2025 blisko 90% profesjonalistów IT korzysta z narzędzi AI, lecz 30% z nich wykazuje znikome zaufanie do bezpieczeństwa wygenerowanego kodu. Z kolei badanie Stack Overflow 2025 wskazuje, że choć 84% deweloperów stosuje rozwiązania AI, tylko 14,1% wdrożyło autonomicznych agentów do codziennej pracy. Różnica wynika z faktu, że o ile sugerowany kod w edytorze pozostaje bierny do momentu akceptacji przez człowieka, o tyle autonomiczny agent wywołuje polecenia powłoki, modyfikuje pliki i wchodzi w interakcje z API.

Systematyczne pomiary bezpieczeństwa opublikowane przez Veracode oraz Apiiro ujawniają skrótowy profil ryzyka powiązanego z kodem generowanym przez AI:

• Wskaźnik awaryjności OWASP Top 10: Badanie Veracode na ponad 100 modelach LLM wykazało, że 45% wygenerowanych próbek kodu zawiera bezpośrednie podatności, w tym wstrzykiwanie zapytań SQL (CWE-89), skrypty międzywitrynowe (CWE-80), wstrzykiwanie do logów (CWE-117) czy słabą kryptografię (CWE-327).
• Dziesięciokrotny skok podatności: Pomiary Apiiro w korporacjach Fortune 50 wykazały, że przy 3-4-krotnym wzroście liczby commitów miesięczna liczba wykrywanych luk bezpieczeństwa wzrosła z 1 000 do ponad 10 000.
• Fałszywe poczucie pewności: W wygenerowanym kodzie liczba błędów składniowych spadła o 76%, a błędów logiki o 60%, co buduje u deweloperów mylne przekonanie o wysokiej jakości. Jednocześnie luki umożliwiające eskalację uprawnień wzrosły o 322%, a błędne decyzje architektoniczne o 153%.

Slopsquatting i Friendly Fire: nowe podatności narzędzia Claude Code

Infrastruktura deweloperska wykorzystująca agentów AI staje się dwukierunkowym celem ataków w sektorze finansowym i regulowanym. Autonomiczne agenty nie tylko generują podatny kod, ale również ulegają halucynacjom pakietów programistycznych i manipulacjom w środowiskach uruchomieniowych. Zespoły bezpieczeństwa muszą zidentyfikować nowe wektory zagrożeń w swoim stosie technologicznym.

Badania zaprezentowane na konferencji USENIX Security 2025 (analiza 576 000 próbek kodu z 16 modeli LLM) potwierdziły, że 20% wygenerowanych odpowiedzi zawiera odwołania do nieistniejących pakietów w rejestrach Python czy JavaScript. Zjawisko to wykorzystuje atak znany jako Slopsquatting (lub HalluSquatting):

1. Odtwarzalność halucynacji: Aż 43% zmyślonych nazw pakietów pojawia się powtarzalnie w odpowiedziach na podobne zapytania.
2. Przejęcie łańcucha dostaw: Przestępcy rejestrują zmyślone nazwy w publicznych rejestrach przed ich instalacją przez nieświadomych deweloperów. Złośliwy pakiet unused-imports po instalacji wykonywał skrypty kradnące poświadczenia API, a pusta biblioteka zarejestrowana jako eksperyment zebrała ponad 30 000 pobrań w 3 miesiące.
3. Friendly Fire: Badacze AI Now Institute wykazali, że agenty Claude Code oraz OpenAI Codex działające w trybie autonomicznym dają się oszukać podczas skanowania nietestowanego kodu pod kątem podatności, wykonując złośliwe polecenia zakodowane przez napastnika w analizowanym repozytorium.
4. Zatrucie środowiska edytorów: Odnotowano krytyczne podatności w edytorze Cursor (CVE-2025-54135 CurXecute i CVE-2025-54136 MCPoison) pozwalające na zdalne wykonanie kodu poprzez modyfikację konfiguracji MCP, a także złośliwe prompts zaktualizowane w wtyczce Amazon Q (CVE-2025-8217).

Projekt Georgia Tech Vibe Security Radar potwierdził w samym marcu 2026 roku 35 opublikowanych podatności CVE wynikających bezpośrednio z użycia agentów AI, z czego 27 dotyczyło kodu stworzonego przez Claude Code.

Ile kosztuje utrata kontroli nad agentami AI w kodzie?

Wdrożenie agentów AI bez przemyślanego nadzoru generuje bezpośrednie koszty operacyjne, opóźnienia w przeglądach kodu oraz ryzyko kar regulacyjnych. Gdy każdy fragment kodu AI wymaga ręcznej weryfikacji na tradycyjnych zasadach, zysk z wydajności zostaje całkowicie skonsumowany przez narzut kontrolny. Z kolei brak nadzoru naraża instytucję na utratę zgodności i incydenty produkcyjne.

Badania empiryczne obalają mit uniwersalnego przyspieszenia pracy. O ile w przypadku prostych zadań typu greenfield programiści uzyskują tempo wyższe o 55,8%, o tyle kontrolowane badanie na dojrzałych repozytoriach wykazuje, że dostęp do AI wydłużył czas wykonania zadań przez doświadczonych inżynierów o 19%, generując przy tym 91% dłuższy czas przeglądu kodu (pull request review).

Porównanie podejść do nadzoru wg ramy GAIE (Governed AI-Assisted Engineering) wskazuje konkretny wpływ na prędkość zespołów i wymogi audytowe:

Instytucje finansowe stosujące automatyzację agentową z progiem pewności osiągają redukcję wskaźnika MTTR o 55–75%, spadek kosztów operacyjnych o 20–40% oraz spadek liczby zgłoszeń L1/L2 o 40–60%.

Czterowarstwowa architektura nadzoru agentów w JPMorgan Chase

Skalowanie agentów AI dla ponad 600 inżynierów w JPMorgan Chase wymagało zastąpienia indywidualnych ustawień edytorów centralną architekturą platformową opartą na czterech warstwach. Większość rozwiązań domyślnych przyznaje agentom nadmierną autonomię (Excessive Agency), co narusza zasady bezpieczeństwa. Sukces wdrożenia zależy od odizolowania uprawnień i zastosowania deterministycznych reguł w kodzie.

Architektura wdrożona przez Lokesha Suri w JPMorgan Chase opiera się na czterech bezwzględnych poziomach kontroli:

1. Zarządzanie (Governance): Centralnie zarządzany plik konfiguracyjny stosuje zasadę „deny-first”. Uniemożliwia odczyt plików poświadczeń (.env, secrets), blokuje nieautoryzowane wywołania HTTP z powłoki (curl) oraz wymaga akceptacji człowieka na polecenie git push. Wyłączenie opcji disableBypassPermissionsMode uniemożliwia inżynierom pomijanie monitów.
2. Deterministyczne barierki (Guardrails): Skrypty hooków (np. PreToolUse) weryfikują polecenia przed ich wykonaniem. Skrypt check-command.sh sprawdza zapytania powłoki i natychmiast blokuje instrukcje SQL typu DROP TABLE lub zapytania skierowane do produkcyjnych baz danych (prod-db), zwracając kod błędu 2.
3. Skompletowana wiedza (Curated Skills): Przepisy wykonawcze (np. add-contract-test) są przechowywane w centralnym repozytorium, wersjonowane i audytowane tak jak kod źródłowy, co eliminuje niezgodne z normami praktyki.
4. Zasięg integracji (Integration Reach): Agenty łączą się z systemami wewnętrznymi poprzez protokół Model Context Protocol (MCP) wyłącznie na podstawie zatwierdzonej białej listy serwerów.

Klasyfikacja zadań odbywa się według modelu trójpoziomowego GAIE (Oversight Classification Model): Tier 1: Human-in-the-Loop (HITL): Stosowany przy funkcjach strategicznych (np. logika zatwierdzania kredytów, reguły AML). Człowiek zatwierdza plan agenta przed wygenerowaniem kodu oraz podpisuje wdrożenie (5–15% zadań). Tier 2: Human-over-the-Loop (HOTL): Stosowany przy interfejsach klienckich i danych PII. Agent generuje i testuje kod autonomicznie, a człowiek zatwierdza bramkę wdrożeniową (15–25% zadań). * Tier 3: Automated with Monitoring (AWM): Stosowany do wewnętrznych narzędzi i środowisk CI/CD. Pełna automatyzacja z ciągłym monitoringiem anomaliom (60–80% zadań).

Wnioski praktyczne i rekomendacje

• Skonfiguruj centralny plik reguł odmowy (deny rules) w środowisku Claude Code lub Cursor, blokując agentom możliwość odczytywania plików środowiskowych (.env, .aws/credentials) oraz wyłączając możliwość pomijania monitów bezpieczeństwa.
• Wdróż deterministyczne skrypty hooków (PreToolUse) w potoku deweloperskim, aby blokować destrukcyjne polecenia powłoki oraz zapytania SQL do baz produkcyjnych przed ich faktycznym wykonaniem.
• Zweryfikuj używane rejestry pakietów oraz wdrożone serwery Model Context Protocol (MCP), wprowadzając prywatne proxy rejestrów oraz narzędzia Software Composition Analysis (SCA) do wyłapywania ataku Slopsquatting.
• Zmierz rzeczywisty wpływ AI na dostarczanie oprogramowania za pomocą wskaźników DORA i SPACE (czas przeglądu pull requestów, wskaźnik awaryjności zmian Change Failure Rate oraz kompletność ścieżki audytowej), zamiast polegać na deklaratywnych ankietach programistów.
• Przeprowadź kategoryzację zadań programistycznych według ramy GAIE, rezerwując ścisły nadzór człowieka przed generowaniem dla funkcji strategicznych, co pozwala zachować 91% prędkości pracy zespołu deweloperskiego przy pełnej zgodności audytowej.

Źródła

• AI Code Generation in Enterprise Pipelines: Governance, Security, and Code Quality
• Enterprise AI Governance Framework
• Enterprise-grade Agentic AI: Secure, Governed, and Sovereign by Design – Atos Group
• Friendly Fire and HalluSquatting: New Attacks Trick AI Coding Agents Into Running Attacker Code and Installing Malware – Threat-Modeling.com
• From pilot to production: The platform team’s playbook for scaling AI coding agents in regulated industries
• Governed AI-Assisted Engineering: Graduated Human Oversight for Agentic Code Generation in Regulated Domains – arXiv
• How to Implement Human-in-the-Loop Controls for AI Agents – DEV Community
• On Automated and Explainable Provenance of AI-Generated Code – arXiv