Prompt injection, indirect prompt injection, data exfiltration, lethal trifecta, MCP security i OWASP LLM Top 10 tworzą nową warstwę ryzyka w projektach AI. Im większy dostęp Agentów AI do danych, narzędzi i systemów, tym większe znaczenie ma kontrola bezpieczeństwa przed uruchomieniem produkcyjnym.
AI Security Review pomaga wykryć scenariusze, w których Agent AI może uzyskać dostęp do danych wrażliwych, ujawnić informacje przez odpowiedź, logi lub narzędzia albo zostać wykorzystany do wyprowadzenia danych. Ryzyka identyfikujemy przed wdrożeniem, gdy można je jeszcze ograniczyć architekturą, uprawnieniami i mechanizmami zabezpieczającymi.
Wdrożenie AI powinno mieć udokumentowaną ocenę ryzyka, kontrolę dostępu, logowanie użycia, zasady nadzoru i ścieżkę audytu. SNOK przygotowuje AI Security Review jako materiał wspierający zgodność, audyt wewnętrzny i decyzję o dopuszczeniu rozwiązania do produkcji.
AI Trust Layer i mechanizmy logowania pozwalają rejestrować zapytania, odpowiedzi, użyte źródła, wywołane narzędzia, eskalacje i decyzje człowieka. Dzięki temu organizacja może prześledzić, co zrobił Agent AI, na jakiej podstawie i w jakim kontekście.
Incydent związany z AI może oznaczać nie tylko problem techniczny, ale także ryzyko reputacyjne, regulacyjne i operacyjne. Lepiej zidentyfikować podatności na etapie projektu niż reagować po wdrożeniu, gdy rozwiązanie ma już dostęp do danych, użytkowników i systemów.
Testujemy rozwiązania pod kątem direct i indirect prompt injection, jailbreakingu, retrieval poisoning, data exfiltration, nieuprawnionego dostępu do źródeł, nadużycia narzędzi oraz błędów w projektowaniu uprawnień. Jako baseline wykorzystujemy OWASP LLM Top 10, NIST AI RMF, MITRE ATLAS oraz dobre praktyki bezpieczeństwa aplikacji opartych na LLM.
Wdrażamy i konfigurujemy mechanizmy governance dla Agentów AI: kontrolę dostępu, logowanie działań, zasady użycia, monitoring, ścieżki eskalacji i audit trail. Celem jest takie wdrożenie AI, które można nadzorować, analizować i rozwijać w kontrolowany sposób.
Projektujemy dostęp do danych tak, aby Agent AI korzystał tylko ze źródeł, do których użytkownik ma uprawnienia. Dotyczy to zarówno odpowiedzi bezpośrednich, jak i odpowiedzi generowanych na podstawie dokumentów, baz wiedzy, systemów enterprise i narzędzi zewnętrznych.
Audytujemy wykorzystanie Model Context Protocol i narzędzi podłączonych do Agentów AI. Sprawdzamy sandboxing tools, walidację inputów, kontrolę side effects, separację danych, ograniczenia uprawnień oraz ryzyko command injection lub niekontrolowanego działania narzędzi.
Prowadzimy symulowane ataki na Agenty AI: prompt injection, indirect prompt injection, data exfiltration, privilege escalation, nadużycie narzędzi, manipulację źródłami i ataki na proces decyzyjny. Dla danych krytycznych rekomendujemy dodatkowe testy red team przed wdrożeniem produkcyjnym.
Wspieramy klasyfikację systemów AI, gap analysis, przygotowanie rejestru rozwiązań AI, dokumentacji, zasad nadzoru, ról właścicielskich, logowania użycia i ścieżki audytu. Jeżeli organizacja potrzebuje szybkiego startu, możemy przygotować podstawowy framework governance dla AI w ciągu 4 tygodni - z dalszym rozszerzeniem pod konkretne systemy, źródła danych i wymagania bezpieczeństwa.
Zaczynamy od threat modelingu. Ustalamy, co Agent AI może zrobić, do jakich danych ma dostęp, z jakich narzędzi korzysta, jakie decyzje wspiera i jakie scenariusze nadużycia są realne w danym środowisku.
Następnie prowadzimy testy techniczne: prompt injection, indirect prompt injection, data exfiltration, jailbreak, retrieval poisoning, MCP security oraz scenariusze zgodne z OWASP LLM Top 10. Sprawdzamy także konfigurację AI Trust Layer, logowanie użycia, uprawnienia i ścieżki eskalacji.
Raport końcowy zawiera opis ryzyk, ich priorytetyzację, rekomendacje remediacji, plan działań naprawczych i zakres retestu. Dla projektów produkcyjnych rekomendujemy, aby pozytywny AI Security Review był jednym z warunków uruchomienia rozwiązania.
Stack technologiczny
Doświadczenie zespołu w obszarze cyberbezpieczeństwa, AI i systemów enterprise potwierdza gotowość SNOK do realizacji projektów bezpieczeństwa AI.
Operator medyczny
AI Security Review dla Agenta HR z dostępem do danych pracowników. Przegląd objął dostęp do danych, scenariusze nadużyć, logowanie działań i remediację ryzyk przed uruchomieniem produkcyjnym.
Bank z sektora finansowego
AI Security Review dla Agenta KYC, obejmujący testy red team, kontrolę dostępu do źródeł, analizę procesu decyzyjnego oraz przygotowanie materiału wspierającego wymagania środowiska regulowanego.
Spółka technologiczna
Audyt MCP tools dla Agenta DevOps, obejmujący ryzyko command injection, niekontrolowane użycie narzędzi, dostęp do pipeline CI/CD i mechanizmy ograniczania skutków błędnego działania Agenta.
Klasyczny pentest koncentruje się na aplikacji, API, frontendzie, infrastrukturze i konfiguracji bezpieczeństwa. AI Security bada dodatkowo warstwę modelu i orkiestracji AI: prompt injection, jailbreaking, retrieval poisoning, dostęp do źródeł, użycie narzędzi, MCP security i ryzyko data exfiltration. To nie zastępuje klasycznego pentestu - to jego uzupełnienie dla systemów opartych na LLM i Agentach AI.
Częściowo. Dostawcy modeli stosują własne zabezpieczenia i guardrails, ale duża część ryzyk powstaje w warstwie aplikacyjnej: w dostępie do danych, retrievalu, narzędziach, integracjach, uprawnieniach i logice procesu. To tę warstwę trzeba zaprojektować, przetestować i monitorować po stronie organizacji.
Lethal trifecta to scenariusz, w którym Agent AI ma jednocześnie dostęp do prywatnych danych, kontakt z niezaufaną treścią zewnętrzną oraz możliwość komunikacji lub działania na zewnątrz. Taka kombinacja zwiększa ryzyko data exfiltration przez prompt injection. W praktyce oznacza to, że Agent może przeczytać wrażliwe dane, zostać zmanipulowany przez zewnętrzną treść i wykorzystać dostępne narzędzie do ujawnienia informacji.
Dla projektów agentycznej automatyzacji i rozwiązań AI z dostępem do danych, narzędzi lub systemów rekomendujemy AI Security Review jako standardowy element wdrożenia. W projektach produkcyjnych traktujemy pozytywny wynik przeglądu jako warunek bezpiecznego uruchomienia rozwiązania lub jako podstawę do decyzji o dodatkowej remediacji.
