Formularze w WordPressie są zaprojektowane z pewnym założeniem. Założenie brzmi tak: po drugiej stronie ekranu siedzi człowiek, który czasem jest niecierpliwy, czasem nieuważny, czasem próbuje wysłać spam. Pod to projektuje się wszystkie mechanizmy obrony — captcha, honeypot, rate limiting po IP, walidacja pól, wymóg zgody RODO, opóźnienia przed pierwszym kliknięciem „wyślij”. To wszystko działa całkiem dobrze, dopóki po drugiej stronie faktycznie jest człowiek.
W 2026 po drugiej stronie coraz częściej nie jest człowiek, tylko agent AI działający w imieniu człowieka. I obrona, która była skuteczna przeciwko spamowi, przeciwko temu agentowi nie zawsze pasuje. Captchę agent omija coraz częściej, bo dostawcy captch nie nadążają za modelami wizyjnymi. Honeypot działa, dopóki agent nie widzi DOM-u — a większość agentów widzi. Rate limiting po IP zawodzi, kiedy agent odpowiada na zapytania tysiąca użytkowników dziennie z jednego centrum danych. Wymóg zgody RODO jest pytaniem, na które agent potrafi kliknąć „tak” szybciej niż człowiek zdąży zrozumieć, co akceptuje.
W poprzednim wpisie koncepcyjnym pokazałem, że agent staje się nowym rodzajem aktora w architekturze strony — ani użytkownikiem, ani botem, ale pośrednikiem działającym z autoryzacji użytkownika. Ten wpis pokazuje, co to znaczy konkretnie dla formularzy w Divi 5, dla koszyka i checkoutu w WooCommerce, i dla systemów rezerwacji. Gdzie są dziury, których wcześniej nie było. Co można załatać teraz, a co wymaga architektonicznych decyzji.
Wpis jest praktyczny, ale pod jedną zasadą — obrona przed spamem i obrona przed niezamierzonymi akcjami agenta to nie jest to samo. Obrona przed spamem zakłada, że ruch jest szkodliwy. Obrona przed niezamierzonymi akcjami agenta zakłada, że ruch jest dobry w intencji, ale może być źle skierowany, źle zinterpretowany albo wykorzystany. To dwie różne rozmowy i trzeba je prowadzić osobno.
Obszar pierwszy — formularze w Divi 5 i ekosystemie WordPressa
Zacznijmy od tego, czym są dziś formularze na stronach Divi 5. Większość właścicieli używa jednego z dwóch podejść. Pierwsze — natywny moduł Contact Form Divi. Drugie — zewnętrzna wtyczka formularzy osadzona w Divi przez moduł Code albo shortcode. W praktyce najczęściej spotyka się miks: prosty formularz kontaktowy w natywnym module Divi, bardziej zaawansowane (zapis na wydarzenie, formularz zgłoszeniowy, quiz) w wtyczce zewnętrznej.
Najpopularniejsze wtyczki formularzy w ekosystemie WordPress:
Moduł Contact Form Divi 5 — natywny, prosty, generuje pola z etykietami. Podstawowy captcha, podstawowy honeypot. Dla prostych formularzy kontaktowych wystarczający.
Contact Form 7 — najpopularniejszy na świecie, darmowy, minimalistyczny. Wymaga ręcznej konfiguracji, ale ma ogromny ekosystem rozszerzeń, w tym do captchy, honeypota, integracji z zewnętrznymi systemami.
Gravity Forms — komercyjny, jeden z najbardziej rozbudowanych. Warunkowa logika pól, zaawansowane integracje, dobra obsługa zgodności RODO. Domyślnie oferuje kilka warstw zabezpieczeń.
Fluent Forms — nowszy, lżejszy, rosnąca popularność. Wizualny kreator, szybkie wdrożenie, wbudowane zabezpieczenia antyspamowe.
WPForms — popularny w USA, obecny też w Polsce. Wizualny kreator, dobre integracje z e-mail marketingiem.
Formidable Forms — mniej popularny w Polsce, ale silny w zastosowaniach typu kalkulatory, rejestratory, quizy.
Każda z tych wtyczek była projektowana pod ochronę przed spamem, nie pod kontrolę nad tym, co zrobi agent. W praktyce oznacza to kilka konkretnych problemów.
Problem pierwszy — captcha jako ostatnia linia obrony. Większość stron polega na captchy (Google reCAPTCHA v2 albo v3, hCaptcha, Cloudflare Turnstile) jako głównym mechanizmie odróżniającym bota od człowieka. Problem: agenci AI w 2025-2026 coraz częściej potrafią rozwiązać captcha wizualną przez własny model wizyjny. Nie każda próba się udaje, ale odsetek skuteczności rośnie szybko. Reklama „niezawodny captcha” coraz bardziej rozchodzi się z rzeczywistością.
Co zamiast? Dwie warstwy. Pierwsza — captcha inwisible (reCAPTCHA v3, Turnstile) jako warstwa informacyjna, nie blokująca. Druga — wymóg potwierdzenia akcji drugim kanałem (email, SMS) dla wszystkich zgłoszeń, które mają konsekwencje. Agent może pokonać captcha. Agent nie pokona tego, że człowiek musi kliknąć link aktywacyjny w swojej skrzynce.
Problem drugi — brak rozpoznania, że żądanie przyszło od agenta. Większość formularzy nie odróżnia wizyty ludzkiej od agentowej. Dostają żądanie HTTP i zakładają, że człowiek. Agent, który wypełnia formularz w ChatGPT Atlas albo Claude in Chrome, wysyła żądanie z normalnymi nagłówkami przeglądarki — dla strony jest nieodróżnialny od człowieka siedzącego przy laptopie.
Co zrobić? Dodać sygnały, które pomagają odróżnić. Analiza czasu wypełniania formularza (człowiek średnio potrzebuje 20-40 sekund na formularz kontaktowy, agent robi to w 2 sekundy). Analiza ścieżki myszy, jeśli strona to zapisuje. Sprawdzenie nagłówka Sec-CH-UA i innych client hints, które w niektórych agentowych przeglądarkach są ustawione inaczej. To nie są silne sygnały — ale razem tworzą profil, który pomaga systemowi oszacować, czy żądanie wymaga dodatkowej weryfikacji.
Problem trzeci — zgody i pola wymagane. Jeśli formularz ma checkbox „zgadzam się na regulamin”, agent zaznaczy go bez zastanowienia, bo reprezentuje użytkownika, który mu zlecił wypełnienie formularza. To z perspektywy prawa zgoda autoryzowana, ale z perspektywy praktycznej — czasem kłopotliwa. W wcześniejszej serii o dostępnościpokazywałem, że dobre formularze mają jasno opisane konsekwencje każdej zgody — to zyskuje nowy wymiar, kiedy odbiorcą tego opisu jest agent, który ma podjąć decyzję w ciągu sekund.
Praktyka dla Divi 5. W natywnym module Contact Form Divi, w ustawieniach pola → Advanced, możesz dodać custom field required_confirmation albo podobny — i użyć go jako flagi w hooku WordPressowym, który wysyła email potwierdzający. W zewnętrznych wtyczkach (Gravity Forms, Fluent Forms) ta logika jest zazwyczaj wbudowana jako „double opt-in” albo „confirmation email”. Włączenie tego to najprostszy krok, który podnosi poziom ochrony przed niezamierzonymi zgłoszeniami agentowymi — niezależnie od tego, czy agent był „zaufany”, czy nie.
Obszar drugi — WooCommerce checkout w świecie, w którym agent kupuje szybciej niż człowiek
WooCommerce jest najpopularniejszą platformą e-commerce na WordPressie. Divi 5 ma natywne integracje z WooCommerce — moduły dla koszyka, checkoutu, archiwów produktów, pojedynczej strony produktu. Wszystko to było projektowane pod człowieka-klienta. W 2026 na scenę wchodzi agent-klient, i okazuje się, że większość domyślnych ustawień WooCommerce nie pasuje.
Po pierwsze — koszyk i guest checkout. WooCommerce domyślnie pozwala na zakup bez konta. To jest świetne dla konwersji ludzkich klientów, ale dla agenta oznacza, że nie ma żadnej warstwy autoryzacji między „wszedł na stronę” a „złożył zamówienie”. Agent może dodać produkt do koszyka, przejść do checkoutu, wprowadzić dane użytkownika i potwierdzić zakup — wszystko w ciągu sekund, bez żadnego śladu w systemie użytkownika, którego reprezentuje. Jeśli coś poszło nie tak, trudno to odtworzyć.
Co zrobić? Dla sklepów, które mają choćby niewielkie ryzyko niezamierzonych zamówień (wysokie wartości pojedynczego produktu, produkty limitowane, dostępność stanowiąca wartość samą w sobie), warto rozważyć: (a) wyłączenie guest checkout dla zamówień powyżej określonej wartości, (b) wymóg potwierdzenia emailem przed finalizacją zamówienia, (c) opóźnienie realizacji zamówienia o X godzin, żeby dać użytkownikowi okno na anulowanie. Wszystkie trzy są dostępne w podstawowym WooCommerce albo przez proste wtyczki.
Po drugie — szybkie checkout z zapisanymi danymi. Jeśli użytkownik jest zalogowany, WooCommerce pokazuje mu checkout wypełniony danymi. Agent, działający w imieniu tego zalogowanego użytkownika, widzi tę samą wypełnioną formę i może ją po prostu potwierdzić. W perspektywie UCP i agentic commerce to jest dokładnie zamierzony scenariusz — agent finalizuje transakcję bez klikania po dwudziestu polach. Ale z perspektywy bezpieczeństwa to oznacza, że pomiędzy „agent otworzył stronę” a „zamówienie potwierdzone” nie ma żadnego aktywnego potwierdzenia ze strony użytkownika.
Granica, którą warto tu wyznaczyć, jest prosta: akcje o wartości poniżej X są OK do zautomatyzowania, akcje powyżej X wymagają potwierdzenia człowieka. Gdzie jest X — to pytanie biznesowe, nie techniczne. Dla sklepu z subskrypcjami cyfrowymi X może być wysokie (miesięczna subskrypcja za 49 zł — spoko, niech agent klika). Dla sklepu z elektroniką X może być 200 zł. Dla sklepu z meblami pod wymiar — każda transakcja powinna być potwierdzona.
Techniczna implementacja — WooCommerce pozwala na to przez filtry woocommerce_checkout_process albo przez wtyczki typu „order approval” (które wstrzymują zamówienie do momentu ręcznej albo emailowej akceptacji). Żadna z wbudowanych opcji WooCommerce nie jest zaprojektowana pod agentów, ale wszystkie te mechanizmy można wykorzystać do oddzielenia „akcje zautomatyzowane” od „akcje wymagające potwierdzenia”.
Po trzecie — stany magazynowe i ataki wyczerpywania zasobów. Agent, który w imieniu wielu użytkowników na raz próbuje kupić ten sam limitowany produkt (np. nowa generacja sprzętu w przedsprzedaży), może wyczerpać twoje stany magazynowe w ciągu sekund. To nie jest atak w klasycznym sensie — każdy użytkownik ma autentyczny zamiar zakupu. Ale efekt jest ten sam co atak: normalni użytkownicy nie zdążą. Coś, co nazywamy denialem-of-service, tylko bez złej intencji.
Mitygacje: rate limiting na poziomie konta (nie IP, bo agent może mieć różne IP), kolejkowanie zamówień dla produktów limitowanych, wymóg potwierdzenia osobistego dla zakupów z produktami o statusie „hot”. WooCommerce nie ma tego wbudowanego, ale są wtyczki (WooCommerce Waitlist, WooCommerce Pre-Orders), które dają narzędzia. Warto je rozważyć, jeśli sprzedajesz cokolwiek, co ma szansę szybko się wyprzedać.
Po czwarte — checkout, który mówi agentowi za dużo. Default WooCommerce checkout zawiera informacje o całym koszyku, dostępnych metodach płatności, kodach rabatowych, możliwościach wysyłki. Dla agenta, który działa w imieniu użytkownika, to jest dobra sprawa — ma pełną informację do decyzji. Ale ta sama informacja dla nieautoryzowanego agenta (który tylko udaje, że reprezentuje użytkownika) jest mapą, po której można nawigować. W szczególności — wszystkie publicznie dostępne kody rabatowe, które są w HTML strony, agent może wyciągnąć i przetestować.
To nie jest dramatyczny problem — ale jest dobrym przykładem tego, że więcej informacji w HTML to nie zawsze lepiej, kiedy po drugiej stronie jest agent, który tę informację skanuje masowo. Przy konfiguracji checkoutu warto zastanowić się, co musi być w DOM, a co można przenieść do sesji serwerowej.
Obszar trzeci — rezerwacje i specyficzne wtyczki
Systemy rezerwacji w Divi 5 (Bookly, Amelia, Simply Schedule Appointments, WooCommerce Bookings) to nisza, ale ważna — bo to są rzeczy, które dla agenta są szczególnie atrakcyjne do automatyzacji. „Zarezerwuj mi wizytę u fryzjera na sobotę” jest dokładnie tym typem zapytania, pod które budowane są agenty konsumenckie. I to jest warstwa, w której domyślne zabezpieczenia wtyczek rezerwacyjnych są najsłabsze.
Trzy najczęstsze dziury:
Brak weryfikacji, że osoba rezerwująca i osoba z danymi kontaktowymi to ta sama osoba. Agent wypełnia formularz rezerwacji w imieniu użytkownika. Wpisuje dane kontaktowe użytkownika. Potwierdza. System wysyła email z potwierdzeniem na adres podany w formularzu. Wszystko się zgadza. Ale gdzieś w tej ścieżce nie było żadnego momentu, w którym właściciel tego emaila aktywnie potwierdził, że chce tej rezerwacji. Mitygacja: zawsze wymóg potwierdzenia emailem (link aktywacyjny), zanim rezerwacja jest traktowana jako finalna. Większość wtyczek rezerwacyjnych ma tę opcję — warto sprawdzić i włączyć.
Brak limitów na liczbę rezerwacji z jednego konta. Jeśli wtyczka nie limituje tego, ile rezerwacji może zrobić jeden użytkownik w danym czasie, agent działający agresywnie może zarezerwować wszystkie wolne terminy na tydzień. Nie dla siebie — dla „swojego użytkownika”, który w rzeczywistości nie zdaje sobie sprawy, co agent właśnie zrobił. Mitygacja: limit liczby aktywnych rezerwacji na użytkownika (w każdej z wymienionych wtyczek da się to ustawić).
Brak dzienników i audytu. Większość wtyczek rezerwacyjnych zapisuje minimum informacji o tym, kto dokonał rezerwacji. Imię, email, telefon. Ale nie — user-agent, IP, ścieżka kliknięć, czas wypełniania. W świecie, w którym 30% rezerwacji może być wykonywanych przez agentów, brak tych danych oznacza, że nie jesteś w stanie nawet wsteczniezrozumieć, co się działo. Warto włączyć pełne logowanie — a jeśli wtyczka go nie oferuje, rozważyć hook do logu zewnętrznego.
Co z tego wynika
W filarze 4 — warstwie działania — Divi 5 jako builder nie jest głównym czynnikiem. Główne są wtyczki, które obsługują formularze, koszyk, rezerwacje. I każda z tych kategorii ma w 2026 ten sam problem: została zaprojektowana pod świat, w którym nie było agentów. Teraz są, a większość mechanizmów obrony, które działały przeciwko spamowi, nie działa przeciwko agentowi, który ma autoryzację użytkownika, cierpliwość zera sekund i skalę tysiąca równoległych sesji.
Trzy rzeczy, które warto zrobić w najbliższym tygodniu, jeśli twoja strona ma formularze albo sklep:
Po pierwsze — włącz podwójne potwierdzenie. Dla każdego formularza o konsekwencjach (kontakt, zapis, rezerwacja, zakup powyżej X zł) wymagaj kliknięcia linku w emailu przed finalizacją. Agent nie ma dostępu do skrzynki pocztowej użytkownika w taki sam sposób, jak sam użytkownik. Bariera niska, skuteczność wysoka.
Po drugie — rozdziel akcje zautomatyzowane od akcji wymagających decyzji człowieka. Zdecyduj, gdzie przebiega twoja granica. Małe kwoty, rutynowe zgłoszenia — OK, niech agent klika. Duże kwoty, nieodwracalne decyzje — zawsze wymagaj aktywnego potwierdzenia od człowieka. Nawet jeśli agent jest „zaufany”.
Po trzecie — zacznij zbierać dane. User-agent, czas wypełniania, ścieżka kliknięć. Za rok, kiedy ruch agentowy wzrośnie, te dane pozwolą ci zrozumieć, co się dzieje na twojej stronie. Bez nich będziesz w ciemności.
To jest ostatnia sekcja tego konkretnego pogłębienia. Kolejny wpis koncepcyjny w serii to filar piąty — tożsamość i zaufanie. Jest to warstwa, która wchodzi głębiej w pytania z tego wpisu: kto to właściwie jest ten agent, który składa zamówienie w twoim sklepie, i czy rzeczywiście reprezentuje tego użytkownika, za którego się podaje. Pytanie fundamentalne, bo bez odpowiedzi na nie, wszystkie mitygacje z filaru 4 są tylko hackami, które działają dopóki atakujący jest leniwy.
