Bądźmy w kontakcie

Plan Szkolenia

Moduł 1 — Jak łamią się aplikacje AI

Laboratorium: brak — przegląd architektury i dyskusja

Model mentalny twórcy dotyczący powierzchni ataku.

Tematy:

  • Architektury LLM, RAG i agentów z perspektywy programisty
  • Cykl żądanie/odpowiedź funkcji AI
  • Przepływ promptów: komunikaty systemowe, programistyczne, użytkownika i narzędzi
  • Miejsca, w których niezaufane dane wchodzą (i ponownie wchodzą) do modelu
  • Granice zaufania, za które odpowiada programista, a które dziedziczy
  • Dlaczego ataki AI są semantyczne, a nie syntaktyczne
  • Mapowanie OWASP LLM Top 10 na kod, który piszesz

Kluczowe spostrzeżenie: Każde miejsce, w którym niezaufany tekst dociera do modelu — lub dane wyjściowe modelu docierają do Twojego kodu — to granica, za którą odpowiadasz.

Moduł 2 — Iniekcja promptów dla twórców

Laboratorium: Lab 01 — 01-Prompt-Injection

„Moment iniekcji SQL” dla AI — ale nie można się całkowicie przed nią uchronić.

Tematy:

  • iniekcja promptów bezpośrednia vs. pośrednia
  • ukryte instrukcje w dokumentach, stronach internetowych, danych wyjściowych narzędzi
  • jailbreaki i zamieszanie ról
  • dlaczego separacja instrukcji/danych ma znaczenie
  • defensywne projektowanie promptów (ograniczniki, struktura, minimalne uprawnienia)
  • dlaczego zapobieganie jest częściowe — projektowanie na wypadek ograniczenia

Praktycznie:

  • zaatakuj własnego chatbota
  • obejdź naiwny filtr
  • przestrukturyzuj prompt, aby zmniejszyć zasięg ataku

Moduł 3 — Traktowanie danych wyjściowych modelu jako niezaufanych

Laboratorium: Lab 02 — 02-Output-Handling

Klasa błędów, którą programiści najczęściej bagatelizują.

Tematy:

  • dane wyjściowe modelu jako niezaufane dane wejściowe dla reszty aplikacji
  • niebezpieczna obsługa danych wyjściowych (LLM02): XSS, SSRF, iniekcja komend/SQL w dalszej części systemu
  • nigdy nie eval/exec/renderuj surowych danych wyjściowych modelu
  • strukturyzowane dane wyjściowe i walidacja schematu
  • kodowanie danych wyjściowych i listy dozwolonych
  • bezpieczne renderowanie w kontekstach web/UI

Praktycznie:

  • znajdź i napraw lukę w niebezpiecznej obsłudze danych wyjściowych
  • wymuś schemat JSON na odpowiedziach modelu

Moduł 4 — Bezpieczeństwo RAG

Laboratorium: Lab 03 — 03-RAG-Security

Jedna z największych nowych powierzchni ataku — i Twoja do zbudowania.

Tematy:

  • zagrożenia związane z bazą danych wektorowych i pobieraniem
  • sanitacja danych na etapie pobierania
  • proweniencja dokumentów i ocena zaufania
  • ograniczenie zakresu pobierania i izolacja metadanych
  • ukryte instrukcje w pobranych treściach (pośrednia iniekcja)
  • eksfiltracja danych poprzez pobieranie

Praktycznie: - zatruj potok RAG złośliwym dokumentem - dodaj sanitację danych i ograniczenie zakresu pobierania, aby go zabezpieczyć

Moduł 5 — Bezpieczeństwo agenta i narzędzi

Laboratorium: Lab 04 — 04-Agent-Safety

Miejsce, w którym błąd staje się działaniem.

Tematy:

  • nadmierna autonomia (LLM06) i nadużycia narzędzi
  • zasada najmniejszych uprawnień dla agentów
  • listy dozwolonych narzędzi i walidacja argumentów
  • bramki zatwierdzania i człowiek w pętli
  • piaskownica dla wykonywania narzędzi
  • kredencje o ograniczonym zakresie i czasie ważności dla agentów
  • ograniczanie autonomicznych pętli i łańcuchów

Praktycznie:

  • zablokuj nadmiernie uprawnionego agenta
  • dodaj listę dozwolonych + bramkę zatwierdzania do niebezpiecznego narzędzia

Moduł 6 — Tajemnice, tożsamość i koszty

Laboratorium: Lab 05 — 05-Secrets-and-Cost

Błędy operacyjne, które najszybciej bolą.

Tematy:

  • zarządzanie kluczami API i tajemnicami (nigdy w promptach, kodzie lub logach)
  • uwierzytelnianie i autoryzacja na użytkownika dla funkcji AI
  • propagowanie tożsamości użytkownika do narzędzi i pobierania
  • odmowa usługi z powodu kosztów: nieograniczone zużycie tokenów / kosztów
  • limity przepustowości, budżety tokenów i limity czasu
  • logowanie bez wycieku tajemnic lub danych osobowych

Praktycznie:

  • usuń tajemnice ze ścieżki promptów/kodu
  • dodaj limity przepustowości na użytkownika i budżet tokenów / kosztów

Moduł 7 — Biblioteki zabezpieczające

Laboratorium: Lab 06 — 06-Guardrails

Kup vs. zbuduj dla bezpieczeństwa wejścia/wyjścia.

Tematy:

  • co robią (a czego nie) frameworki zabezpieczające
  • zabezpieczenia wejścia: klasyfikatory iniekcji/PII/tematów
  • zabezpieczenia wyjścia: walidacja, filtrowanie, sprawdzanie uzasadnienia
  • kiedy zabezpieczenie jest odpowiednie vs. własna deterministyczna kontrola
  • nakładanie zabezpieczeń na kontrole z poprzednich modułów
  • wydajność, fałszywe pozytywy i tryby awarii

Praktycznie:

  • dodaj warstwę zabezpieczeń wejścia/wyjścia do funkcji AI
  • zmierz, co łapie, a co omija

Moduł 8 — Red-Teaming własnej aplikacji

Laboratorium: Lab 07 — 07-Red-Teaming

Wdrażaj, jakby atakujący już ją mieli.

Tematy:

  • budowanie zestawu testów nadużyć dla funkcji AI
  • zautomatyzowane testy iniekcji promptów i jailbreaków
  • testy regresji zabezpieczeń i polityk
  • uruchamianie kontroli bezpieczeństwa AI w CI
  • łańcuch dostaw modeli i zależności (proweniencja, przypinanie)
  • lista kontrolna bezpieczeństwa przed wdrożeniem dla funkcji AI

Praktycznie:

  • napisz zautomatyzowane testy red-team dla funkcji AI
  • podłącz je do kontroli CI

Moduł 9 — Ocena bezpieczeństwa AI: Framework SAIS-100

Laboratorium: brak — ćwiczenie oceny (używa aplikacji Capstone)

Przekształć wszystko, co zbudowałeś, w powtarzalną ocenę.

Tematy:

  • Hexagon Bezpieczeństwa AI: sześć pytań zamiast „czy jest bezpieczne?”
  • sześć ocenianych kategorii (Dane, Prompt, Agent, Łańcuch dostaw, Wykrywanie, Zarządzanie)
  • 100-punktowa rubryka i jej wagi
  • zakresy werdyktów i reguła nadpisania jednej kategorii
  • Elephant Scale Secure AI Score (SAIS-100) jako markowy, powtarzalny framework
  • ocena przed/po wzmocnieniu jako metryka

Praktycznie:

  • oceń aplikację Capstone na 100-punktowej skali
  • wymień jedną zmianę, która najbardziej podnosi ocenę

Kluczowe spostrzeżenie: Trzy najwyżej oceniane kategorie mapują się na granice zaufania, za które odpowiada programista — więc ocena mierzy dokładnie to, czego uczy ten kurs.

Capstone

Uczniowie wzmacniają celowo podatną aplikację AI od początku do końca.

Aplikacja startowa zawiera:

  • podatny na iniekcję prompt
  • niebezpieczną obsługę danych wyjściowych
  • nieograniczony potok RAG
  • nadmiernie uprawnionego agenta
  • tajemnice w ścieżce promptów
  • brak limitów kosztów

Uczniowie stosują kurs:

  • przestrukturyzuj prompty, aby ograniczyć zasięg
  • waliduj i koduj dane wyjściowe modelu
  • sanitizuj i ogranicz zakres pobierania
  • zastosuj zasadę najmniejszych uprawnień i bramki zatwierdzania dla agenta
  • usuń tajemnice i dodaj limity kosztów/przepustowości
  • dodaj zabezpieczenia i zautomatyzowane testy red-team

Rezultat: wzmocniona aplikacja oraz krótka samoocena OWASP LLM Top 10.

Mapa modułów i laboratoriów

Laboratoria są prowadzone w kolejności modułów. Kurs składa się z 9 modułów i 7 laboratoriów: Moduł 1 to przegląd architektury/dyskusja, a Moduł 9 to ćwiczenie oceny, więc nie mają własnych folderów z laboratoriami.

  • Lab 01 - 01-Prompt-Injection: Zaatakuj swojego chatbota i zaprojektuj ograniczenie zasięgu (Moduł 2)
  • Lab 02 - 02-Output-Handling: Napraw błąd niebezpiecznej obsługi danych wyjściowych (Moduł 3)
  • Lab 03 - 03-RAG-Security: Zatruj, a następnie zabezpiecz potok RAG (Moduł 4)
  • Lab 04 - 04-Agent-Safety: Zablokuj nadmiernie uprawnionego agenta (Moduł 5)
  • Lab 05 - 05-Secrets-and-Cost: Zabezpiecz klucze i dodaj limity kosztów (Moduł 6)
  • Lab 06 - 06-Guardrails: Dodaj warstwę zabezpieczeń wejścia/wyjścia (Moduł 7)
  • Lab 07 - 07-Red-Teaming: Zautomatyzowane testy red-team w CI (Moduł 8)

Moduł 1 (Jak łamią się aplikacje AI) nie ma laboratorium — jest to przegląd architektury i dyskusja. Moduł 9 (Ocena bezpieczeństwa AI) nie ma folderu z laboratorium — jest to ćwiczenie oceny na aplikacji Capstone.

Wymagania

  • Poziom umiejętności: Średniozaawansowany.
  • Uczniowie powinni być zaznajomieni z: budowaniem i korzystaniem z REST API, językiem skryptowym (w laboratoriach używany jest Python), podstawowym uwierzytelnianiem aplikacji, git i CLI
  • Nie jest wymagane doświadczenie w uczeniu maszynowym — to kurs z bezpieczeństwa aplikacji dla osób budujących z LLM, a nie trenujących je.

Odbiorcy

  • Inżynierowie oprogramowania / backendu budujący funkcje LLM
  • Programiści full-stack i API
  • Inżynierowie aplikacji AI/ML
  • Inżynierowie platform wdrażający asystentów i agentów
  • Tech leadowie i starsi inżynierowie odpowiedzialni za funkcje AI
 21 godzin

Liczba uczestników


Cena za uczestnika (netto)

Opinie uczestników (2)

Propozycje terminów

Powiązane Kategorie