--- title: "Bezpieczeństwo agentów AI & OWASP" description: "Powierzchnie ataku agentów AI i to, jak framework OWASP chroni przed prompt injection, nadużyciem narzędzi i wyciekami danych." locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp" category: "Agenci AI" updated: "2026-10-28T13:32:31.486Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Bezpieczeństwo agentów AI & OWASP Powierzchnie ataku agentów AI i to, jak framework OWASP chroni przed prompt injection, nadużyciem narzędzi i wyciekami danych. ## Czym jest bezpieczeństwo agentów AI według OWASP Bezpieczeństwo agentów AI według OWASP to systematyczne zabezpieczanie autonomicznych agentów AI przed zagrożeniami, które wynikają z ich zdolności do samodzielnego planowania, wywoływania narzędzi, zapisywania danych w pamięci trwałej i działania przy minimalnym zatwierdzaniu kolejnych kroków przez człowieka. Podczas gdy klasyczny [chatbot](https://blckalpaca.at/pl/slownik/chatbot) przede wszystkim **odpowiada** ([prompt](https://blckalpaca.at/pl/slownik/prompt) na wejściu, odpowiedź modelu na wyjściu, ewentualnie ugruntowana przez [RAG](https://blckalpaca.at/pl/slownik/rag)), agenci **planują, wnioskują, wybierają narzędzia, zapisują pamięć i działają**. To przesunięcie poziomu abstrakcji poszerza powierzchnię ataku w trzech wymiarach: autonomii (wieloetapowe plany, samodzielna modyfikacja kontekstu i pamięci), korzystania z narzędzi (system plików, [API](https://blckalpaca.at/pl/slownik/api), konektory baz danych, sandboxy do wykonywania kodu, [serwery MCP](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/model-context-protocol-mcp/mcp-security-prompt-injection-tool-poisoning-i-zarzadzanie-uprawnieniami), węzły protokołu A2A) oraz trwałości (długotrwałe magazyny pamięci, wektorowe bazy danych, łańcuchy zaufania między agentami). OWASP ujmuje to we własnym sformułowaniu GenAI Security Project (Sotiropoulos et al., 9 grudnia 2025 r.) tak: [systemy agentowe](https://blckalpaca.at/pl/slownik/systemy-agentowe) dziedziczą wszystkie ryzyka [LLM](https://blckalpaca.at/pl/slownik/llm) i wprowadzają zupełnie nowe klasy podatności, wynikające z autonomii, integracji narzędzi, koordynacji wielu agentów i trwałego stanu. Dla decydentów w Europie kluczowy wniosek brzmi: kto czyta wyłącznie [LLM Top 10](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/omowienie-owasp-llm-top-10-2025-dziesiec-ryzyk-bezpieczenstwa-aplikacji-llm), **systematycznie nie docenia ryzyka agentowego**. ## Dwie kluczowe listy OWASP OWASP GenAI Security Project (genai.owasp.org) publikuje rodzinę nakładających się na siebie dokumentów dotyczących bezpieczeństwa [AI](https://blckalpaca.at/pl/slownik/ai). Dwa z nich mają kluczowe znaczenie dla agentów: - **OWASP Top 10 dla aplikacji LLM 2025 (LLM01:2025 do LLM10:2025).** Obejmuje ryzyka modelu i aplikacji w każdej aplikacji GenAI/LLM: konwersacyjnej, opartej na RAG, typu copilot lub agentowej. To punkt odniesienia, który większość zespołów bezpieczeństwa już zna. Od 3 sierpnia 2026 r. dostępne jest [wydanie 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/). Excessive Agency zajmuje w nim 3. miejsce (LLM03:2026). Przyporządkowania na tej stronie są zgodne z numeracją z 2025 r. - **OWASP Top 10 for Agentic Applications 2026 (ASI01 do ASI10).** Lista opublikowana 9 grudnia 2025 r. przez tę samą inicjatywę (Agentic Security Initiative) przy udziale ponad 100 współtwórców i Expert Review Board (m.in. NIST, Alan Turing Institute, Microsoft AI Red Team, AWS/CoSAI, Zenity). To fundament modelowania zagrożeń specyficznych dla agentów. **Ważna uwaga dotycząca taksonomii:** kanoniczna lista z grudnia 2025 r. różni się od wcześniejszej wersji roboczej OWASP („[Agentic AI](https://blckalpaca.at/pl/slownik/agentic-ai) Threats and Mitigations v1.0”, luty 2025 r., często cytowanej jako „15 agentic threats”). Wiele artykułów praktyków z początku i połowy 2025 r. nadal stosuje tę roboczą numerację (np. „[Memory Poisoning](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/jak-zapobiegac-memory-poisoning-zabezpieczenie-pamieci-dlugoterminowej-i-wektoro) jako ASI01”). Należy ona do *historycznych* wersji roboczych, a nie do ostatecznej listy Top 10. Dawne kategorie są dziś włączone *do* skonsolidowanej listy. Memory Poisoning mieści się w ASI06, obejście HITL w ASI09. ## ASI01–ASI10 w skrócie Dziesięć kanonicznych zagrożeń agentowych i ich główne kategorie kontroli: | ID | Nazwa OWASP (grudzień 2025) | Główny środek zaradczy | Powiązanie z LLM Top 10 (2025) | | --- | --- | --- | --- | | **ASI01** | [Agent](https://blckalpaca.at/pl/slownik/agent) Goal Hijack | Filtrowanie danych wejściowych + ACL zakresu i pochodzenia | LLM01 Prompt Injection | | **ASI02** | Tool Misuse & Exploitation | RBAC dla narzędzi + walidacja schematów + HITL przy operacjach destrukcyjnych | LLM06 Excessive Agency | | **ASI03** | Identity & Privilege Abuse | Cykl życia NHI + krótkotrwałe poświadczenia + jawna delegacja | (brak bezpośredniego odpowiednika) | | **ASI04** | Agentic Supply Chain Vulnerabilities | Zaufany rejestr + AIBOM + kwarantanna w czasie działania | LLM03 Supply Chain (statyczny) | | **ASI05** | Unexpected Code Execution | Sandboxing + lista dozwolonych poleceń + wyłączenie automatycznego zatwierdzania | LLM05 Improper Output Handling | | **ASI06** | Memory & Context Poisoning | Metadane pochodzenia + izolacja tenantów + audyty pamięci | LLM04 + LLM08 | | **ASI07** | Insecure Inter-Agent Communication | mTLS + podpisane AgentCards + lista dozwolonych połączeń w grafie współpracy | (brak odpowiednika) | | **ASI08** | Cascading Failures | Circuit breakery + bulkheady + symulacja z cyfrowym bliźniakiem | (brak odpowiednika) | | **ASI09** | Human-Agent Trust Exploitation | Interfejs wymuszający zaangażowanie + stopniowane zatwierdzanie + szkolenia z błędu automatyzacji | LLM09 Misinformation (częściowo) | | **ASI10** | Rogue Agents | Bazowe profile zachowań + kill switch + audyt | LLM06 (częściowo) | Kluczowa jest logika wzmocnienia: według mapowania DeepTeam **ASI01 = LLM01 (Prompt Injection) × LLM06 (Excessive Agency)**, tyle że z wieloetapowym wykonaniem, które zwielokrotnia szkody ponad skutki pojedynczej odpowiedzi. ASI03, ASI07 i ASI08 nie mają bezpośredniego odpowiednika w LLM Top 10, a ASI10 jest tylko częściowo powiązane z LLM06:2025. ## Prompt injection i Agent Goal Hijack (ASI01) W przypadku ASI01 atakujący [manipuluje celami](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/agent-goal-hijacking-gdy-cele-autonomicznych-agentow-ai-zostaja-zmanipulowane), wyborem zadań lub ścieżkami decyzyjnymi agenta, bezpośrednio przez prompt injection albo pośrednio przez ukryte instrukcje w dokumentach, korpusie RAG, e-mailach, zaproszeniach z kalendarza, opisach [PR](https://blckalpaca.at/pl/slownik/pr) lub wynikach narzędzi. Sedno problemu: agenci i model, na którym działają, **nie potrafią niezawodnie odróżnić instrukcji od danych**, więc każdy tekst, który agent czyta, staje się częścią powierzchni ataku. Udokumentowanym punktem zwrotnym jest **EchoLeak (CVE-2025-32711, CVSS 9.3)**, ujawniony przez Aim Labs w czerwcu 2025 r. w Microsoft 365 Copilot: **pierwszy realnie udokumentowany przypadek zero-click prompt injection w systemie produkcyjnym**. Jeden spreparowany e-mail ominął klasyfikator XPIA firmy Microsoft i przez dozwolone proxy Teams wyprowadził najbardziej wrażliwe treści z kontekstu Copilota, bez ani jednego kliknięcia użytkownika (Aim Labs ukuło termin „LLM Scope Violation”; szczegóły techniczne: arXiv 2509.10540, Reddy et al., wrzesień 2025 r.). Microsoft załatał lukę po stronie serwera. Inne przypadki: **GitHub Copilot YOLO Mode (CVE-2025-53773)** oraz **CamoLeak w GitHub Copilot Chat (CVSS 9.6)**, który dzięki obejściu CSP przez własne proxy obrazów Camo firmy GitHub wykradał znak po znaku sekrety z prywatnych repozytoriów. Akademickim źródłem tej dyscypliny jest praca Greshake et al. (arXiv 2302.12173, 2023) o [pośrednim prompt injection](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/prompt-injection-bezposredni-vs-posredni-na-czym-polega-roznica-i-dlaczego-przy). **Przykład z regionu DACH (Niemcy, Austria, Szwajcaria):** agent obsługi klienta w banku, który czyta współdzieloną skrzynkę pocztową, może przez e-mail z „podziękowaniem” zawierający ukryte instrukcje zostać nakłoniony do ujawnienia w następnej odpowiedzi fragmentów transakcji innych klientów. ## Nadużycie narzędzi (ASI02) i Excessive Agency ASI02 subtelnie różni się od nadużycia uprawnień: dostęp jest zgodny z uprawnieniami, ale **użycie** już nie. Agent działa w ramach przyznanych mu praw, lecz stosuje dozwolone narzędzie w niebezpieczny sposób: usuwa dane, zbyt często wywołuje kosztowne API, wykonuje destrukcyjne operacje. [Excessive Agency](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/tool-misuse-i-excessive-agency-gdy-agenci-ai-maja-zbyt-wiele-uprawnien) (LLM06:2025), czyli przyznanie niekontrolowanej swobody działania bez wystarczającego ograniczenia zakresu i nadzoru człowieka, stanowi koncepcyjny pomost do ASI02 i częściowo do ASI10. Udokumentowany przypadek: w **Amazon Q Code Assistant (CVE-2025-8217, lipiec 2025 r.)** atakujący przejęli [token](https://blckalpaca.at/pl/slownik/token) GitHub i przemycili destrukcyjne prompty do rozszerzenia VS Code v1.84.0, które z flagami `--trust-all-tools --no-interactive` mogły bez potwierdzenia usunąć systemy plików i zasoby chmurowe; rozszerzenie zainstalowało około 1 miliona programistów. Środki zaradcze: zasada najmniejszych uprawnień dla każdego narzędzia, walidacja schematu każdego argumentu narzędzia, listy dozwolonych i zabronionych działań dla każdej roli agenta, wyłączenie automatycznego zatwierdzania (trybów „YOLO”) dla wszystkiego, co dotyka baz danych, płatności, komunikacji lub wdrożeń, a także limity kosztów z circuit breakerami. ## Memory & Context Poisoning (ASI06) W przeciwieństwie do chatbotów, które między sesjami zapominają, agenci utrzymują pamięć trwałą: historię rozmów, preferencje, wyuczony kontekst, magazyny RAG. To tworzy **trwałe powierzchnie ataku**: jedna udana iniekcja trwale zatruwa pamięć, payload działa bez końca, a każda kolejna sesja dziedziczy kompromitację. Udokumentowane przykłady: **atak na pamięć Google Gemini** (luty 2025 r., Johann Rehberger) zademonstrował „delayed tool invocation”: przesłany dokument polecał Gemini zapisywać fałszywe informacje, gdy w przyszłości pojawią się określone słowa wyzwalające. Badanie [„Invitation Is All You Need!”](https://arxiv.org/abs/2508.12175) (Nassi, Cohen, Yair, sierpień 2025 r.) przedstawiło **14 scenariuszy ataku na asystentów opartych na Gemini**, uruchamianych przez e-maile, zaproszenia z kalendarza i udostępnione dokumenty. Według analizy ryzyka przeprowadzonej przez autorów **73% przeanalizowanych zagrożeń stanowi wysokie lub krytyczne ryzyko** dla użytkowników. Blogi poświęcone bezpieczeństwu, powołując się na Lakerę, opisują zachowanie typu „uśpiony agent”: skompromitowani agenci mają rozwijać trwałe fałszywe przekonania na temat zasad bezpieczeństwa i **bronić ich przed ludźmi**. Środki zaradcze: traktowanie zapisów w pamięci jako operacji wrażliwych z punktu widzenia bezpieczeństwa, metadane pochodzenia (źródło, znacznik czasu, ścieżka pozyskania, poziom pewności) dla każdego wpisu, izolacja per tenant, regularne audyty pamięci oraz procedury usuwania zgodne z [art. 17 RODO](https://dsgvo-gesetz.de/art-17-dsgvo/) (prawo do usunięcia danych). ## Środki zaradcze i human-in-the-loop (ASI09) Agenci generują dopracowane wyniki, które brzmią autorytatywnie. Ludzie mają skłonność im ufać. ASI09 (Human-Agent Trust Exploitation) czyni właśnie tę warstwę zaufania celem ataku: błąd automatyzacji, uleganie autorytetom i „polished hallucination” sprawiają, że osoby zatwierdzające bez namysłu przepuszczają rekomendacje. Warstwa nadzoru, pomyślana jako zabezpieczenie, **staje się słabym punktem**. Dostawcy rozwiązań bezpieczeństwa opisują niepotwierdzony niezależnie przypadek, w którym agenta zakupowego miano przez trzy tygodnie przekonywać, że jego limit autoryzacji wynosi 500 000 USD; następnie atakujący miał złożyć fałszywe zamówienia na 5 mln USD. Skuteczne bramki HITL wymagają **niezależnej weryfikacji dowodów**, a nie tylko rekomendacji agenta: stopniowanych zatwierdzeń (większy wpływ → więcej zatwierdzających lub mocniejsze dowody), wzorców UI, które aktywnie pokazują rozumowanie, pochodzenie źródeł i poziom pewności (a nie samego przycisku „Zatwierdź”), oraz okresowych „test injections”, które sprawdzają, czy HITL naprawdę działa (jak ćwiczenia przeciwpożarowe). Jest to bezpośrednio zbieżne z [art. 14 unijnego AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) (nadzór ze strony człowieka). Ogólna zasada to obrona w głąb: **żaden pojedynczy guardrail nie jest uniwersalnym rozwiązaniem.** EchoLeak ominął klasyfikator XPIA firmy Microsoft; kompetentni badacze w ciągu kilku miesięcy obeszli każdy opublikowany guardrail (Bedrock Guardrails, Google Model Armor, Gemini Safety). Potrzebnych jest kilka uzupełniających się warstw: filtry wejściowe (np. Llama Guard 4, NVIDIA NeMo Guardrails, Microsoft Prompt Shield, Lakera Guard) + egzekwowanie zakresu i pochodzenia + filtry wyjściowe + monitorowanie zachowań. Guardraile zwykle dodają 100–500 ms opóźnienia na każdą warstwę i w wielojęzycznych kontekstach DACH (przełączanie kodów DE/FR/IT/EN) dają więcej fałszywych alarmów. Deklaracje dostawców w rodzaju „blokuje 99,x% ataków prompt injection” należy traktować jako marketing, dopóki nie zweryfikuje ich niezależny red team. ## Zgodność z regulacjami w regionie DACH (informacyjnie, nie stanowi porady prawnej) Listy OWASP **nie są certyfikacją**, a „OWASP-compliant” nie jest wiarygodną deklaracją dostawcy: dostawcy mogą *wdrażać* zalecenia OWASP, ale nie mogą być „compliant”. Listy te dobrze jednak przekładają się na ramy zgodności w regionie DACH: - **Art. 15 unijnego AI Act** (dokładność, solidność i cyberbezpieczeństwo) szeroko obejmuje systemy wysokiego ryzyka, ale jest neutralny technologicznie; pośrednie wstrzykiwanie promptów, specyfika NHI i kaskady wieloagentowe nie zostały jeszcze skodyfikowane w normie i pozostają odpowiedzialnością podmiotu stosującego. - **Art. 32 [RODO](https://blckalpaca.at/pl/slownik/rodo)** (środki techniczne i organizacyjne): większość zagrożeń ASI dotyczy poufności, integralności, dostępności i odporności. ASI06 dotyczy na przykład art. 5 ust. 1 lit. d (prawidłowość) i art. 17 (usunięcie danych). - **ISO/IEC 42001:2023** (załącznik A, 38 zabezpieczeń w ramach 9 celów) dostarcza zabezpieczeń referencyjnych, m.in. A.6.2.4 (V&V), A.6.2.6 (eksploatacja/monitorowanie) i A.6.2.8 (logowanie). - **NIS2 / DORA**: w przypadku podmiotów kluczowych i ważnych NIS2 w art. 21 ust. 2 wymaga m.in. bezpieczeństwa łańcucha dostaw (→ ASI04) i kontroli dostępu (→ ASI03); DORA w art. 28–30 reguluje ryzyko związane z zewnętrznymi dostawcami usług ICT, co ma bezpośrednie znaczenie dla łańcuchów dostaw [MCP](https://blckalpaca.at/pl/slownik/mcp) i agentów w sektorze finansowym. Nadzór w regionie DACH: **wytyczne BaFin** (18 grudnia 2025 r.) i **komunikat nadzorczy FINMA 08/2024** *nie są wiążące*, ale wyraźnie przesuwają ciężar dowodu podczas audytów; oba dokumenty zalecają m.in. adwersarialne testy penetracyjne lub oparte na scenariuszach ćwiczenia z cyberbezpieczeństwa. W Austrii **FMA** poszła w ich ślady, publikując dokument informacyjny [„Nutzung von KI im Finanzsektor”](https://www.fma.gv.at/querschnittsthemen/kuenstliche-intelligenz/) (wersja 1.0, stan na 11 września 2026 r.). Również ten dokument nie jest wiążący. Stwierdza, że aplikacje AI już dziś muszą spełniać neutralne technologicznie wymogi prawa rynku finansowego, w tym DORA, oraz że organ zarządzający ponosi ostateczną odpowiedzialność także za ryzyka ICT związane z AI. **BSI** w [raporcie o stanie bezpieczeństwa 2025](https://medien.bsi.bund.de/lagebericht/de/resiliente-gestaltung-von-llm-systemen/) wskazuje pośredni prompt injection jako obecnie najistotniejszy wektor ataku na systemy LLM i stwierdza, że nie istnieje jeden wysoce skuteczny środek, który by go powstrzymał. ## Perspektywy i wskazówki praktyczne OWASP Agentic Top 10 ma obecnie wersję 1.0 (9 grudnia 2025 r.) i prawdopodobnie będzie aktualizowana co najmniej raz w roku. Warto dodać `genai.owasp.org` do zakładek, zamiast traktować listę jako statyczną. Trzy trzeźwe uwagi praktyczne. Po pierwsze, MITRE ATLAS jako katalog taktyk przeciwników pozostaje 6–12 miesięcy w tyle za agentowym frontem, zwłaszcza w przypadku ASI07, ASI08 i ASI10. Po drugie, wykrywanie w produkcyjnych wdrożeniach agentów jest wciąż słabe: większość [stosów observability](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/monitoring-agentow-ai-z-langsmith-i-langfuse-obserwowalnosc-dla-bezpiecznych-age) zbudowano dla klasycznych aplikacji i nie wychwytują one anomalii w śladach rozumowania, naruszeń pochodzenia przy zapisach do pamięci ani sygnałów dryfu zachowań; wniosek „nie widzimy tego w SIEM, więc to się nie dzieje” jest niebezpiecznie błędny. Po trzecie, „AI red teaming” to nie to samo co klasyczny pentest (inne umiejętności, inne narzędzia, takie jak Garak/PyRIT/DeepTeam, wyniki probabilistyczne zamiast binarnych). Dla podmiotów wdrażających agentów pragmatyczny punkt wyjścia wygląda tak: założyć rejestr ryzyk na podstawie OWASP Agentic Top 10, zmapować go na ISO 42001 i art. 15 unijnego AI Act, traktować każdego agenta jako odrębną Non-Human Identity z krótkotrwałymi poświadczeniami, wdrożyć guardraile w modelu obrony w głąb, zabezpieczyć destrukcyjne operacje prawdziwym HITL i mieć w gotowości kill switch do izolowania zbuntowanych agentów. Więcej o prompt injection, red teamingu, monitorowaniu i ścieżkach audytu znajdziesz w artykułach poniżej. ## Artykuły - [Omówienie OWASP LLM Top 10 (2025): dziesięć ryzyk bezpieczeństwa aplikacji LLM](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/omowienie-owasp-llm-top-10-2025-dziesiec-ryzyk-bezpieczenstwa-aplikacji-llm) — OWASP LLM Top 10 (2025) to opracowana przez OWASP GenAI Security Project lista dziesięciu najpoważniejszych ryzyk bezpieczeństwa aplikacji opartych na dużych… - [Audit trail dla agentów AI: kompletne logowanie odporne na manipulacje](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/audit-trail-dla-agentow-ai-kompletne-logowanie-odporne-na-manipulacje) — Ścieżka audytu dla agentów AI to kompletny i odporny na manipulacje zapis wszystkich decyzji, wywołań narzędzi, dostępów do danych, operacji zapisu w pamięci i… - [OWASP Agentic Security (ASI) Top 10 (2026): ryzyka agentowych systemów AI](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/owasp-agentic-security-asi-top-10-2026-ryzyka-agentowych-systemow-ai) — OWASP Agentic Top 10 (ASI01–ASI10) to lista ryzyk dla autonomicznych agentów AI, opublikowana 9 grudnia 2025 r. przez OWASP GenAI Security Project w ramach… - [Prompt injection bezpośredni vs. pośredni: na czym polega różnica i dlaczego przy agentach AI to sprawa dla zarządu](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/prompt-injection-bezposredni-vs-posredni-na-czym-polega-roznica-i-dlaczego-przy) — Prompt injection (wstrzykiwanie promptów) polega na przemycaniu szkodliwych instrukcji do danych wejściowych systemu AI w celu przejęcia kontroli nad jego… - [Tool Misuse i Excessive Agency: gdy agenci AI mają zbyt wiele uprawnień](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/tool-misuse-i-excessive-agency-gdy-agenci-ai-maja-zbyt-wiele-uprawnien) — Excessive Agency oznacza zbyt szeroko zakrojoną autonomię, uprawnienia lub funkcjonalność agenta AI: może on zrobić więcej, niż wymaga jego zadanie. Tool Misuse… - [Agent Goal Hijacking: gdy cele autonomicznych agentów AI zostają zmanipulowane](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/agent-goal-hijacking-gdy-cele-autonomicznych-agentow-ai-zostaja-zmanipulowane) — Goal Hijacking (OWASP ASI01) to manipulowanie celami, wyborem zadań lub ścieżkami decyzyjnymi autonomicznego agenta AI. Atakujący przekierowują agenta za pomocą… - [Jak zapobiegać Memory Poisoning: zabezpieczenie pamięci długoterminowej i wektorowej agentów AI](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/jak-zapobiegac-memory-poisoning-zabezpieczenie-pamieci-dlugoterminowej-i-wektoro) — Memory Poisoning to celowe wprowadzanie zmanipulowanych treści do pamięci długoterminowej lub wektorowej agenta AI. W odróżnieniu od jednorazowych ataków prompt… - [Jak dobrze zaprojektować Human-in-the-Loop (HITL): wzorce zatwierdzania dla agentów AI](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/jak-dobrze-zaprojektowac-human-in-the-loop-hitl-wzorce-zatwierdzania-dla-agentow) — Human-in-the-Loop (HITL) oznacza celowe wbudowanie zatwierdzeń przez człowieka w łańcuch działań agenta AI. Gdy działanie jest nieodwracalne, kosztowne lub… - [Red teaming agentów AI: jak systematycznie wykrywać podatności](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/red-teaming-agentow-ai-jak-systematycznie-wykrywac-podatnosci) — Red teaming agentów AI to systematyczne, symulowane atakowanie agentów AI w celu wykrycia podatności, takich jak prompt injection, jailbreaki, nadużycie… - [Monitoring agentów AI z LangSmith i Langfuse: obserwowalność dla bezpiecznych agentów AI](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/monitoring-agentow-ai-z-langsmith-i-langfuse-obserwowalnosc-dla-bezpiecznych-age) — Monitoring agentów AI (Agent Observability) to ciągłe rejestrowanie i analizowanie tego, co robi agent AI: śladów (traces), wywołań narzędzi, kosztów tokenów… --- Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp). Systemy AI mogą wykorzystywać te treści z podaniem źródła.