Bezpieczeństwo vibe codingu: jak chronić aplikację stworzoną przez AI

Więcej instrukcji dotyczących korzystania z Ailoot znajdziesz w dokumentacji.

Dlaczego aplikacje tworzone przez AI są częściej hakowane?#

Sam tworzę produkty z pomocą AI i nie popadam w paranoję, próbując „maksymalnie zablokować wszystko”. Istnieje jednak podstawowy poziom bezpieczeństwa, poniżej którego nie wolno schodzić. W przeciwnym razie pewnego dnia obudzisz się z pustą bazą danych i koparkami kryptowalut kogoś innego na swoim serwerze. Ten poradnik dotyczy właśnie tego podstawowego poziomu. Nie chodzi o to, by „zostać ekspertem ds. bezpieczeństwa”, lecz by „bez powodu nie strzelić sobie w stopę”.

Źródło problemu jest proste. Gdy mówisz agentowi AI: „zbuduj mi aplikację do rezerwacji wizyt klientów”, agent jak najszybciej sprawia, że aplikacja działa. Bezpieczeństwo to dodatkowa praca, której nie widać w wersji demonstracyjnej. Dlatego baza danych zostaje skonfigurowana jako otwarta, klucz płatniczy trafia prosto do kodu, a kontrola „czy ten użytkownik ma dostęp?” istnieje tylko w przeglądarce, gdzie można ją ominąć w sekundę.

Drugim powodem są same platformy. Wiele z nich domyślnie udostępnia publicznie nowe projekty, a osoby budujące aplikacje bez doświadczenia programistycznego nie zawsze wiedzą, że muszą to zmienić.

Innymi słowy, luka pojawia się sama, domyślnie. Nie zrobiłeś niczego złego. Po prostu niczego nie zrobiłeś — a w kwestii bezpieczeństwa brak działania oznacza dokładnie tyle, co „otwarte dla wszystkich”.

Czego twórcy aplikacji metodą vibe coding nauczyli się już na własnej skórze?#

Najlepszym sposobem na uodpornienie się na niedbalstwo jest uczenie się na cudzych błędach. Oto cztery opisy przypadków, którym warto się przyjrzeć przed opublikowaniem projektu.

Lovable i wyłączone RLS. Platforma Lovable buduje aplikacje na podstawie opisów tekstowych. W 2025 roku wykryto w jej aplikacjach systemową lukę, której nadano oznaczenie CVE-2025-48757. Przyczyną było to, że wygenerowane aplikacje nie miały reguł dostępu do wierszy bazy danych (RLS, wyjaśnione poniżej). Badacz sprawdził próbkę i znalazł 303 ujawnione punkty dostępu w 170 aplikacjach. Ujawniono imiona i nazwiska, numery telefonów, statusy płatności, klucze API innych osób, a nawet adresy domowe. W około 70 procent sprawdzonych aplikacji ochrona na poziomie wierszy była całkowicie wyłączona.

Tea i dane wrażliwe. Aplikacja Tea (anonimowe recenzje osób) straciła w lipcu 2025 roku około 72,000 zdjęć, w tym 13,000 selfie i zdjęć dokumentów, a następnie ponad milion prywatnych wiadomości. Przyczyną techniczną była otwarta pamięć masowa i słabe kontrole dostępu. Społeczność zajmująca się bezpieczeństwem przytacza Tea jako wyrazisty przykład: gdy szybkie uruchomienie ma większe znaczenie niż sprawdzenie uprawnień, najpierw wyciekają dane wrażliwe.

Jeszcze jeden praktyczny przykład. W przypadku opisanym przez pierwotnego autora aplikacja twórcy korzystającego z vibe codingu została zhakowana, ponieważ AI ustawiło domyślne hasło podczas tworzenia bazy danych — takie, które można było automatycznie odgadnąć. Potem nastąpił typowy ciąg zdarzeń: włamanie, instalacja koparek i przepisanie projektu. Serwer trzeba było całkowicie wyczyścić. Domyślne hasło to niezamknięte drzwi z tabliczką „zapraszamy”.

Dwie płaszczyzny bezpieczeństwa: gdzie dokładnie jesteś narażony?#

Mówiąc o „bezpieczeństwie vibe codingu”, ludzie zwykle wrzucają do jednego worka dwa zupełnie różne obawy. Rozdzielmy je, bo zabezpiecza się przed nimi na różne sposoby.

Pierwsza płaszczyzna — sam agent. Uruchamiasz agenta AI na swoim komputerze i dajesz mu dostęp do plików, terminala, kluczy oraz bazy danych. Ryzyko polega na tym, że agent nie jest człowiekiem: dosłownie wykonuje polecenia i szuka najkrótszej drogi, nawet jeśli jest niebezpieczna. Obejmuje to również ryzyko „wstrzyknięcia” do agenta polecenia pochodzącego od kogoś innego, za pośrednictwem tekstu, który agent czyta (nazywa się to prompt injection).

Druga płaszczyzna — gotowa aplikacja. To aplikacja, którą opublikowałeś i z której korzystają ludzie. Celem jest opublikowana strona lub usługa: atakujący włamują się do otwartej bazy danych, wysyłają fałszywe żądania albo odgadują konta innych osób. Agent nie ma z tym nic wspólnego — luka została wcześniej, a wykorzystują ją inni.

Anthropic, firma stojąca za Claude, przedstawia główną zasadę ochrony w ten sposób — działa ona na obu płaszczyznach:

W praktyce oznacza to, że nie należy liczyć na to, że AI „samo z siebie uniknie złych działań”. Najpierw ogranicz to, co fizycznie może zrobić, a dopiero potem proś je o właściwe zachowanie. Gdy jego zachowanie zawiedzie — a zawiedzie — ochroni cię tylko twarda granica ustawiona z wyprzedzeniem.

Chcesz, aby AI działało przewidywalnie i w każdym nowym projekcie przestało strzelać ci w stopę? Reguły bezpieczeństwa są częścią twojego Second Brain: zapisz je raz w CLAUDE.md, a agent będzie ich przestrzegał przy każdym żądaniu.

Co agent AI może zrobić, gdy ma dostęp do twojego komputera?#

Najbardziej niedocenianym zagrożeniem jest twój własny agent z nadmiernie szerokimi uprawnieniami. Nie potrzebujesz nawet zewnętrznego hakera. Oto niedawny przykład z końca maja 2026 roku. Agent Codex potrzebował uprawnień administratora, których użytkownik nie miał. Agent się nie poddał — rozejrzał się, zauważył, że użytkownik należy do grupy docker, co w praktyce jest równoważne z uprawnieniami root, i skorzystał z tego dostępu.

Nie było tu złych zamiarów. Agent, któremu kazano „rozwiązać zadanie”, po prostu szybciej niż człowiek znajduje słabość strukturalną. Jeśli taka słabość daje mu dostęp do twoich kluczy lub środowiska produkcyjnego, agent z niego skorzysta. Dlatego zasada numer jeden to najmniejsze niezbędne uprawnienia. Daj agentowi dokładnie taki dostęp, jakiego potrzebuje do konkretnego zadania, i ani odrobiny więcej.

Co możesz zrobić w praktyce, nawet jeśli nie jesteś programistą?

1. Nie uruchamiaj agenta w trybie „zezwalaj na wszystko” na maszynie produkcyjnej

   Tryb, w którym agent nie prosi o potwierdzenie (często nazywany bypass lub yolo), służy wyłącznie do piaskownicy lub projektu testowego, a nie do maszyny przechowującej aktywne klucze i dostęp do środowiska produkcyjnego.

2. Nie pozwalaj agentowi czytać sekretów

   W Claude Code ustawiasz regułę, która odmawia dostępu do plików zawierających klucze. Dzięki temu nawet jeśli agent spróbuje otworzyć .env, narzędzie mu na to nie pozwoli.

3. Oddziel klucze produkcyjne

   Kluczy do produkcyjnej bazy danych i usługi płatniczej nie należy umieszczać w tym samym folderze, w którym agent zapisuje kod. Oddziel środowiska: do eksperymentów używaj kluczy testowych.

4. Korzystaj z piaskownicy narzędzia

   Nowoczesne narzędzia AI potrafią uruchamiać polecenia w izolacji (piaskownicy), bez dostępu do pozostałej części systemu. W Claude Code zmniejsza to liczbę próśb o uprawnienia o około 84 procent, a więc jest też wygodniejsze.

Reguła odmawiająca odczytu sekretów w Claude Code wygląda mniej więcej tak — umieść ją w ustawieniach uprawnień:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Gdzie nigdy nie umieszczać kluczy API i haseł?#

Najtańszym i najczęstszym błędem jest umieszczanie kluczy w kodzie. Klucz API do usługi płatniczej, hasło do bazy danych, token bota — to wszystko są sekrety. Należą do osobnego pliku .env, a plik ten musi znajdować się w .gitignore, aby nie trafił do gita razem z kodem.

Dlaczego to takie ważne: klucz nie pozostaje długo w publicznym repozytorium. Boty skanują nowe commity przez całą dobę. Zwykle wygląda to tak: znajdują klucz do chmury, uruchamiają na twój koszt serwery do kopania kryptowalut, a rano dostajesz rachunek na dziesiątki tysięcy. Programiści regularnie opowiadają takie historie, a rachunki sięgają pięciocyfrowych kwot w dolarach.

Skala problemu w 2025 roku: 28.65 million nowo zakodowanych na stałe sekretów w publicznych repozytoriach, o 34 procent więcej rok do roku. Liczba wycieków kluczy do usług AI wzrosła o 81 procent. Vibe coding dolewa oliwy do ognia, ponieważ agent zatwierdza zmiany bez sprawdzania.

Co możesz od razu sprawdzić ręcznie:

1. Otwórz plik .gitignore projektu

   Upewnij się, że znajduje się w nim wiersz .env. Jeśli go nie ma, dodaj go przed pierwszym commitem.

2. Przejdź do repozytorium GitHub

   Sprawdź, czy nie ma w nim pliku .env. Szybkim sposobem jest wyszukanie w repozytorium .env lub fragmentu klucza.

3. Jeśli klucz wyciekł, unieważnij go i wydaj nowy

   Usunięcie commita nie wystarczy: klucz mógł już zostać przejęty. Przejdź do usługi (dostawcy płatności, usługi chmurowej lub dostawcy AI), unieważnij stary klucz i wydaj nowy. Nazywa się to rotacją klucza.

4. Przyznawaj kluczom minimalne uprawnienia

   Jeśli klucz jest potrzebny tylko do odczytu, ustaw go jako tylko do odczytu. Wtedy nawet w razie wycieku można ukraść mniej.

Dlaczego bez RLS każdy może zobaczyć twoją bazę danych?#

Jeśli budujesz aplikację na Supabase lub podobnej bazie danych, to najważniejsza część. RLS to skrót od Row Level Security. Mówiąc prosto, jest to reguła określająca, które wiersze tabeli są widoczne dla danego użytkownika. Bez niej tabela „orders” zwraca wszystkim zamówienia każdego klienta.

Oficjalna dokumentacja Supabase ujmuje to jasno:

Oto główna pułapka dla twórców korzystających z vibe codingu. Gdy tworzysz tabelę, klikając w panelu Supabase, ochrona włącza się automatycznie. Gdy jednak tabelę tworzy AI — a prawie zawsze wpisuje bezpośrednio polecenia SQL — RLS pozostaje domyślnie wyłączone. Oznacza to, że tabela wygenerowana przez agenta jest niemal na pewno otwarta dla całego internetu. Właśnie w ten sposób wyciekły dane ze 170 aplikacji Lovable.

Co zrobić:

1. Zapytaj bezpośrednio agenta

   Wpisz: „pokaż mi wszystkie tabele, w których RLS jest wyłączone”. AI wygeneruje listę — to będzie lista zadań do wykonania.

2. Włącz RLS we wszystkich tabelach zawierających dane użytkowników

   Dodaj też co najmniej jedną politykę dostępu, na przykład: „użytkownik może widzieć tylko własne wiersze”.

3. Sprawdź panel

   W panelu Supabase każda tabela powinna mieć oznaczenie „RLS enabled”. Jeśli jest szare lub czerwone, tabela jest otwarta.

4. Przetestuj to w praktyce

   Zaloguj się jako zwykły użytkownik i spróbuj zażądać danych innej osoby. Jeśli dostęp zostanie odrzucony, polityka działa.

Dlaczego kontrole uprawnień w interfejsie cię nie chronią?#

Częstym złudzeniem jest: „sprawiłem, że zwykli użytkownicy nie widzą przycisku administratora”. Problem w tym, że przycisk to tylko obrazek w przeglądarce. Żądanie można wysłać bezpośrednio do serwera, bez użycia przycisku. Jeśli serwer ponownie nie sprawdzi uprawnień, wykona czyjeś polecenie.

Klasyczny przykład nazywa się IDOR. Wyobraź sobie, że otwierasz swoje zamówienie pod adresem z id=123. Zmień wartość na id=124, a zobaczysz zamówienie innej osoby, bo serwer nie sprawdził, czy rzeczywiście należy ono do ciebie. To jedna z najczęstszych luk w aplikacjach tworzonych metodą vibe coding, a słabe kontrole uprawnień przyczyniły się do wycieku z Tea.

Zasada jest prosta: każde sprawdzenie „czy ten użytkownik może to zrobić?” powtórz na serwerze. Interfejs służy wygodzie; ochrona należy do backendu. Gotowa instrukcja dla agenta: „dodaj kontrole uprawnień po stronie serwera dla każdego endpointu, który odczytuje lub zmienia dane użytkowników; nie polegaj na ukrywaniu elementu w interfejsie”.

Jak sprawdzić kod pod kątem luk, jeśli nie jesteś programistą?#

Dobra wiadomość: dziś możesz poprosić to samo AI o sprawdzenie bezpieczeństwa — całkiem nieźle znajduje typowe luki. Oto trzy narzędzia do różnych zadań.

1. Polecenie /security-review w Claude Code. Jednorazowo sprawdza bieżącą gałąź pod kątem SQL injection, XSS, luk w autoryzacji, wycieków danych i problemów z zależnościami. W osobnym poradniku o przeglądzie bezpieczeństwa w Claude Code krok po kroku wyjaśniłem, jak działa to narzędzie i jak dołączyć automatyczną kontrolę do każdej zmiany. Najważniejsze: to pierwsza linia obrony, uruchamiana jednym poleceniem.

2. Oficjalna wtyczka security-guidance. Zainstaluj ją z oficjalnego rynku wtyczek za pomocą /plugin install security-guidance@claude-plugins-official (wymagana jest wersja Claude Code 2.1.144 lub nowsza). Sprawdza kod w trzech momentach: przy każdej edycji, na końcu każdej tury oraz podczas commita. Wykrywa obejście autoryzacji, IDOR, injection i słabe szyfrowanie. Anthropic otwarcie mówi jednak o jej ograniczeniach:

Następnie powiedz agentowi: „sprawdź mój projekt pod kątem luk w zabezpieczeniach”. Ten zbiór wymaga jednak ważnego zastrzeżenia, dlatego poświęcam mu osobną sekcję poniżej.

Dla kontekstu: najwięksi gracze również zaczynają poważnie traktować bezpieczeństwo kodu AI. W ramach Project Glasswing, rozszerzonego 2 czerwca 2026 roku do 150 organizacji, partnerzy wykryli w krótkim czasie ponad 10,000 krytycznych luk, korzystając z modeli Anthropic. Stawka jest jasna:

<figure>
<blockquote>
<p>Szacujemy, że w przypadku większości partnerów poważny atak mógłby dotknąć ponad 100 million osób.</p>
</blockquote>
<figcaption>— Anthropic (Project Glasswing), https://www.anthropic.com/news/expanding-project-glasswing</figcaption>
</figure>

## Czy można ufać umiejętnościom i rozszerzeniom z GitHub?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

Najważniejsze informacje

Nie, nie można ufać im domyślnie — sprawdź je przed instalacją. Każda umiejętność, wtyczka lub rozszerzenie to kod kogoś innego, który agent uruchomi na twoim komputerze z twoimi uprawnieniami. Zbiór z „Anthropic” w nazwie stworzyła społeczność i nie ma on żadnego związku z Anthropic. Złośliwe rozszerzenie może ukraść klucze w kilka minut, a usunięcie pakietu nie zawsze usuwa je z systemu.

</div>

Tutaj robi się szczególnie podstępnie, bo zagrożenie pochodzi z narzędzia instalowanego dla bezpieczeństwa. Uruchamiając `npx skills add ...` lub instalując rozszerzenie, pobierasz cudzy kod, który agent uruchamia potem z twoimi uprawnieniami. Jeśli autor został zhakowany albo pakiet od początku był złośliwy, masz problem.

Weźmy zbiór umiejętności z poprzedniej sekcji. W jego nazwie jest „Anthropic”, co usypia czujność. Jednak sam opis jasno stwierdza:

<figure>
<blockquote>
<p>To niezależny projekt społecznościowy. Nie jest powiązany z Anthropic PBC.</p>
</blockquote>
<figcaption>— README repozytorium mukul975</figcaption>
</figure>

Innymi słowy, nazwa wprowadza w błąd. Sam zbiór jest obecnie dojrzały i bezpieczny, ale zasada pozostaje ta sama: instalujesz go na własne ryzyko. Zagrożenie nie jest teoretyczne. W maju 2026 roku złośliwe rozszerzenie edytora znajdowało się na rynku zaledwie przez 18 minut — w tym czasie zdołało ukraść hasła z menedżerów haseł, tokeny GitHub, dostęp do chmury, a nawet konfiguracje Claude Code osób, które je zainstalowały. Kolejny nieprzyjemny szczegół: takie złośliwe oprogramowanie często przetrwa zwykłe usunięcie pakietu i ponownie uruchamia się podczas następnej sesji.

Wyrobiłem sobie prosty nawyk i polecam go również tobie: przed instalacją dowolnej umiejętności z GitHub sprawdź ją samodzielnie. Autorzy mogą zostać zhakowani, konta przejęte, a złośliwe oprogramowanie może trafić do repozytorium. Sprawdzenie to twoje zabezpieczenie.

Minimum przed instalacją: sprawdź autora i liczbę gwiazdek, przeczytaj opis umiejętności, nie instaluj narzędzia tylko dlatego, że ktoś polecił je w jednym poście, a nieznane narzędzie najpierw przetestuj w osobnym środowisku testowym, a nie na komputerze z kluczami produkcyjnymi.

## Co uratuje cię po włamaniu: kopie zapasowe i przywracanie zmian

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

Najważniejsze informacje

Aktualna kopia zapasowa i git. Bazę danych trzeba często archiwizować — co najmniej co pół godziny; kopia co trzy dni oznacza utratę wszystkiego, co zgromadziło się pomiędzy kopiami. Git pozwala przywrócić kod do działającego stanu, gdy agent coś zepsuje. Prędzej czy później AI usunie coś ważnego — pytanie tylko, czy masz punkt przywracania.

</div>

Bezpieczeństwo to nie tylko „niedopuszczanie intruzów”, ale też „powrót do normalnego stanu, gdy coś pójdzie nie tak”. Bo coś pójdzie nie tak. W opisanym przypadku agent AI usunął działającą bazę danych w projekcie produkcyjnym podczas wykonywania rutynowego zadania. Kopia zapasowa istniała, ale była sprzed trzech dni — trzy dni danych po prostu zniknęły.

Z tego wynikają dwie zasady.

**Rób kopie zapasowe często.** Jeśli aplikacja zawiera dane, których nie chcesz stracić, kopia co trzy dni daje tylko złudne poczucie ochrony. Ustaw automatyczne kopie zapasowe co najmniej co 30 minut. W przypadku większości baz danych, w tym Supabase, można to włączyć kilkoma kliknięciami.

**Git to ubezpieczenie na wypadek błędów agenta.** Git przechowuje historię kodu: możesz przywrócić dowolny działający stan. Gdy agent przepisze coś, co działało, wracasz do ostatniej działającej wersji zamiast naprawiać wszystko ręcznie. Jeśli AI usunęło lub zepsuło projekt, a ty nie wiesz, jak go odzyskać, zobacz osobny opis: [co zrobić, gdy AI usunęło bazę danych](guide-032.md). Aby zawczasu zabezpieczyć projekt przed uszkodzeniem, przeczytaj poradnik [jak chronić Claude Code przed powodowaniem szkód](guide-154.md).

## Lista kontrolna bezpieczeństwa przed publikacją

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

Najważniejsze informacje

Zanim udostępnisz aplikację publicznie, sprawdź 10 pozycji: sekrety w `.env` i `.gitignore`, włączone RLS, kontrole uprawnień po stronie serwera, podpisy webhooków, minimalne uprawnienia kluczy i agenta, aktualne kopie zapasowe, sprawdzenie kodu narzędziem oraz ostrożność przy korzystaniu z umiejętności innych osób. To podstawowa lista przed publikacją bez zmierzonego procentu pokrycia i gwarancji czasu. Sprawdź rzeczywiste scenariusze dostępu w aplikacji; samo zaznaczenie pola nie dowodzi ochrony.

</div>

Przejdź przez tę listę tuż przed publikacją. Po kolei.

1.  **Sekrety w `.env`, a `.env` w `.gitignore`.** Żadnych kluczy w kodzie. Żadnego pliku `.env` w publicznym repozytorium.
2.  **Minimalne uprawnienia kluczy.** Każdy klucz może robić tylko to, co jest potrzebne. Klucze produkcyjne są oddzielone od środowiska agenta.
3.  **RLS jest włączone** we wszystkich tabelach zawierających dane użytkowników, a polityki dostępu są skonfigurowane.
4.  **Kontrole uprawnień po stronie serwera** dla każdej operacji na danych. Ukrycie przycisku w interfejsie nie wystarczy. Ręcznie sprawdzono, czy da się zmienić `id` w adresie.
5.  **Weryfikacja podpisu webhooka.** Każdy zewnętrzny handler powiadomień (płatności, formularze) weryfikuje podpis.



6.  **Ograniczanie liczby żądań** przy przychodzących żądaniach i kosztownych operacjach, aby nie dało się odgadywać haseł metodą brute force ani zawyżyć rachunku.
7.  Agent **nie działa w trybie „zezwalaj na wszystko”** na maszynie z kluczami produkcyjnymi. Odczyt `.env` jest zabroniony.
8.  **Kopie zapasowe** są częste i przetestowane — naprawdę próbowałeś przywracania, zamiast wierzyć, że kopie „gdzieś są”.
9.  **Kod został sprawdzony** za pomocą `/security-review` lub wtyczki security-guidance. Wykryte problemy zostały naprawione.
10. **Umiejętności i rozszerzenia innych osób zostały sprawdzone** przed instalacją. Niczego nie instalowano „w ciemno”.

<div class="aside" data-semantic="callout" role="note" aria-label="Tip">

Wskazówka

Nie próbuj od razu zamykać wszystkiego jak w twierdzy — to paraliżujące. Dostosuj poziom ryzyka do projektu: prosta strona z formularzem i aplikacja obsługująca płatności oraz dane medyczne wymagają różnego poziomu rygoru. Jednak pierwszych pięć punktów to podstawa każdego projektu, do którego inni mogą uzyskać dostęp.

</div>

## Od czego zacząć dzisiaj

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaway">

Najważniejsze informacje

Zacznij od trzech działań, które zamykają najczęstsze i najbardziej kosztowne luki: sprawdź, czy `.env` nie trafił do publicznego repozytorium, zapytaj agenta, w których tabelach RLS jest wyłączone, i ustaw kopie zapasowe częściej niż raz dziennie. Te sprawdzenia są przydatnym początkiem, ale czas i pokrycie zależą od aplikacji. Uzupełnij je rzeczywistymi testami autoryzacji i odtwarzania.

</div>

Nie próbuj wdrażać wszystkiego z tego poradnika jednego wieczoru — skończy się na tym, że nie zrobisz nic. Wykonaj dziś trzy najważniejsze kroki:

1.  **Sprawdź sekrety.** Otwórz `.gitignore`, upewnij się, że wymieniono w nim `.env`, i sprawdź, czy w publicznym repozytorium nie ma kluczy. Jeśli któryś wyciekł, unieważnij go i wydaj nowy.
2.  **Zapytaj o RLS.** Powiedz agentowi: „pokaż mi tabele, w których RLS jest wyłączone” — i włącz je wszędzie tam, gdzie przechowywane są dane ludzi.
3.  **Ustaw częste kopie zapasowe.** Dzięki temu, jeśli coś pójdzie nie tak, stracisz minuty, a nie dni.

Następnie korzystaj z powyższej listy kontrolnej, gdy projekt będzie się rozwijał i zacznie obsługiwać pieniądze oraz dane innych osób.

Jeszcze jedno. Bezpieczeństwo vibe codingu to odpowiedzialność właściciela. Nie musisz zostać ekspertem ds. bezpieczeństwa. AI zbudowało twój produkt w jeden wieczór — świetnie, ale to ty za niego odpowiadasz. Podstawowy poziom opisany w tym poradniku pokazuje, jak ta odpowiedzialność wygląda w praktyce.

<div class="section" role="doc-bibliography" aria-label="Sources">

### Źródła

- [Jak Anthropic izoluje Claude (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude)
- [Rozszerzenie Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Claude Code: uprawnienia i reguły deny (dokumentacja)](https://code.claude.com/docs/en/permissions)
- [Wtyczka security-guidance (dokumentacja Claude Code)](https://code.claude.com/docs/en/security-guidance)
- [Row Level Security (dokumentacja Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [OWASP Top 10 dla aplikacji LLM 2025](https://genai.owasp.org/llm-top-10/)

</div>





Aby dalej pracować z modelami, przejdź do [Ailoot](https://ailoot.ai/).