Bezpieczeństwo agentów AI

Agenci łamią założenia, na których zbudowano Wasze zabezpieczenia

Bezpieczeństwo aplikacji zakłada, że ścieżki wykonania są znane z góry. Nadzór nad dostępem zakłada, że człowiek wnioskuje, przełożony zatwierdza, a recenzent recertyfikuje. Systemy agentowe łamią oba założenia: łączą rozumowanie, trwałą pamięć, dostęp do narzędzi i wielokrokowe wykonanie, więc sekwencja działań powstaje w czasie wykonania i jest kształtowana przez tekst, który agent akurat przeczytał.

Powstaje z tego osobna klasa awarii. Agenta można odwieść od pierwotnego celu treścią, którą sam pobrał. Można mu dać legalne narzędzie i skłonić do użycia go w nielegalnej kombinacji. Jego pamięć można zatruć tak, że zła instrukcja przetrwa między sesjami. A ponieważ agenci powstają szybko i po cichu, gromadzą uprawnienia szybciej, niż wychwytuje to jakikolwiek cykl przeglądu.

---

Pracujemy według opublikowanego modelu zagrożeń

Nasze oceny są ułożone wokół OWASP Top 10 for Agentic Applications, dzięki czemu ustalenia trafiają do słownika zrozumiałego jednocześnie dla inżynierów, audytorów i dostawców.

Ryzyko	Jak wygląda na produkcji
Przejęcie celu agenta	Pobrana treść odwodzi agenta od zadania, które otrzymał
Nadużycie narzędzi	Legalne narzędzia wywołane z parametrami lub w sekwencjach, których nikt nie przewidział
Nadużycie tożsamości i uprawnień	Współdzielone konta serwisowe, zbyt szerokie zakresy, brak możliwości przypisania działania
Kompromitacja łańcucha dostaw	Narzędzie, wtyczka lub serwer MCP obdarzone zaufaniem z automatu
Nieoczekiwane wykonanie kodu	Wygenerowany kod lub polecenia trafiające do środowiska bez sandboxa
Zatruwanie pamięci i kontekstu	Złośliwa instrukcja utrwalona w pamięci i odtwarzana później
Niezabezpieczona komunikacja między agentami	Agenci ufający swoim wynikom bez uwierzytelnienia i walidacji
Kaskadowe awarie	Jeden zły wynik propagujący się przez łańcuch szybciej, niż ktokolwiek zdąży zareagować
Nadużycie zaufania człowieka	Pewny siebie wynik zatwierdzany przez operatora bez realnej weryfikacji
Agenci poza kontrolą	Agenci działający poza ewidencją, nadzorem i procedurą wyłączenia

---

Co robimy

Modelowanie zagrożeń i przegląd architektury

Mapujemy cel każdego agenta, jego wejścia, pamięć, narzędzia, poziom autonomii i zasięg potencjalnych szkód, a następnie sprawdzamy, gdzie zaufanie jest zakładane zamiast ustanawiane. Wynikiem jest uszeregowany zestaw ustaleń z konkretnymi zmianami projektowymi, a nie lista ogólnych ostrzeżeń o prompt injection.

Tożsamość i uprawnienia agentów

Tutaj nasze doświadczenie w zarządzaniu tożsamością przekłada się wprost na wynik. Agenci powinni mieć własne tożsamości z imiennym właścicielem, wąsko zakresowe i czasowo ograniczone poświadczenia, delegację nieprzekraczającą uprawnień użytkownika, w imieniu którego działają, miejsce w procesie JML oraz obecność w recertyfikacji dostępu. Większość organizacji nie ma jeszcze żadnego z tych elementów.

• Model tożsamości nieludzkich obejmujący agentów, narzędzia i połączenia usługowe
• Minimalne uprawnienia dla każdego narzędzia, z poświadczeniami wygasającymi i rotowanymi
• Własność, cykl życia i wycofanie — w tym to, jak konkretnie agenta się wyłącza
• Przypisywalność: dowód, który agent i w czyim imieniu wykonał daną czynność

Narzędzia i łańcuch dostaw

Każde narzędzie, które agent może wywołać, rozszerza Waszą powierzchnię ataku, a ekosystemy konektorów, takie jak serwery MCP, są przyjmowane szybciej, niż są przeglądane. Oceniamy, do czego narzędzie sięga, jak się uwierzytelnia, czy jego opis sam nie może przenosić wstrzyknięcia i co umożliwiłaby wersja skompromitowana lub podmieniona.

Bariery ochronne, sandboxing i człowiek w pętli

Nie każde działanie zasługuje na ten sam poziom autonomii. Projektujemy stopniowanie — co agent może robić swobodnie, co wymaga drugiego sygnału, a co akceptacji człowieka, która jest realna, a nie odruchowa — a do tego izolację wykonania, limity tempa i kosztów oraz bezpieczniki zatrzymujące kaskadę, zanim się rozpędzi.

Testy ofensywne i ewaluacja

Testy adwersarialne na Waszych rzeczywistych agentach: pośrednie wstrzyknięcia przez dokumenty, strony i zgłoszenia; nadużycia łańcuchów narzędzi; ataki na trwałość pamięci; eskalacja uprawnień przez granice agentów. Ustalenia dostajecie z odtworzeniami i testami regresji, które można wpiąć do CI, żeby poprawka pozostała poprawką.

Nadzór i zgodność regulacyjna

Ewidencja systemów AI, klasyfikacja ryzyka, bramki akceptacyjne i dokumentacja, o którą pytają dziś regulatorzy i klienci korporacyjni — zgodnie z AI Act, ISO/IEC 42001 i NIST AI Risk Management Framework. Warto pamiętać, że obowiązki przejrzystości z art. 50 AI Act stosuje się od 2 sierpnia 2026 r., natomiast harmonogram obowiązków dla systemów wysokiego ryzyka został przesunięty w ramach pakietu Digital Omnibus. Pomożemy ustalić, gdzie mieszczą się Wasze systemy i co to oznacza w praktyce.

---

Co otrzymujesz

• Ewidencję agentów z właścicielami, poziomami autonomii, narzędziami i zasięgiem danych
• Model zagrożeń i uszeregowane ustalenia zmapowane na ryzyka OWASP
• Projekt tożsamości i uprawnień agentów pasujący do istniejącego IAM i IGA
• Architekturę barier ochronnych i akceptacji, ze spisanymi poziomami autonomii
• Wyniki testów ofensywnych z odtworzeniami i testami regresji
• Artefakty nadzoru: politykę, klasyfikację ryzyka i dowody na jej poparcie

Częste pytania

Mamy tylko kilku wewnętrznych agentów. Czy to nie za wcześnie?

To najlepszy możliwy moment. Ustawienie tożsamości agentów i poziomów akceptacji przy pięciu agentach kosztuje ułamek tego, co doposażanie pięćdziesięciu — a wzorzec ustanowiony teraz jest tym, który skopiuje reszta organizacji.

Czy potrzebujecie dostępu do naszych modeli?

Nie. Pracujemy na poziomie architektury, tożsamości, narzędzi, uprawnień i obserwowalności, bo tam koncentruje się ryzyko możliwe do wykorzystania. Dotyczy to zarówno modeli hostowanych, jak i uruchamianych lokalnie.

Czy możecie pracować z naszymi programistami, a nie obok nich?

To zamierzona forma współpracy. Projekty, które przynoszą trwały efekt, to te, w których bariery ochronne powstają razem z zespołem wypuszczającym agentów, a testy regresji trafiają do ich pipeline’u, a nie do naszego raportu.