Fakt: OpenAI wprost deklaruje, że ChatGPT Atlas wykorzystuje ARIA (role, aria-label, landmarki) do zrozumienia struktury i interakcji na stronach. To ma ułatwić agentowi klikanie, wypełnianie formularzy i nawigację — „jak czytnik ekranu, ale sterowany LLM-em”. Świetne dla dostępności. Ryzykowne dla bezpieczeństwa. 

 

Problem w jednym zdaniu

 

Jeśli agent traktuje ARIA jako prawdę objawioną o intencji elementu, to ukryty tekst w ARIA (albo długie „opisy” podpięte przez aria-describedby) może zostać potraktowany jak instrukcja, a nie jak metadane. To textbook indirect prompt injection. OpenAI samo przyznaje: prompt injection to „frontier challenge” — aktywny obszar ryzyka, nie rozwiązany problem. 

 

Jak dokładnie Atlas „widzi” stronę

 

  • Parsuje DOM i accessibility tree; ARIA pomaga mu zrozumieć, co jest przyciskiem, nawigacją, formularzem, jak brzmi „nazwa” akcji. To zwiększa trafność kliknięć i autofill. 

  • Agent Mode potrafi wykonywać czynności „za użytkownika” (kliki, wpisy, wysyłki). Jeśli semantyka była zmanipulowana, agent może podjąć złą decyzję — poprawnie technicznie, błędną intencyjnie. (Analizy i relacje branżowe). 

 

Czy OpenAI to zabezpiecza? „Tak, ale…”

 

  • Oficjalnie: OpenAI edukuje o prompt injection i publikuje ogólne kierunki mitigacji; w materiałach bezpieczeństwa i system cardach przyznaje, że zespół red-teamingowy atakuje też przez prompt injections, a mechanizmy obronne są rozwijane iteracyjnie. To nie jest zamknięty temat. 

  • Nieoficjalnie / branża: Kilka analiz wskazuje, że Atlas pozostaje podatny na pewne warianty iniekcji (np. „udawane URL-e” lub treści ukryte/wysokozaufane), a ryzyko rośnie, gdy agent ma uprawnienia do akcji i danych. To zgodne z obserwacją, że AI-agenci są na dziś trudni do uodpornienia na iniekcje. 

  • Wniosek: OpenAI nie zaprzecza wektorowi; wręcz przeciwnie — klasyfikuje go jako „frontier challenge”. Zabezpieczenia istnieją, ale nie gwarantują odporności, zwłaszcza gdy serwisy „przekarmiają” ARIA treściami quasi-instrukcyjnymi. 

 

ARIA-Injection: model zagrożenia (dla Atlas / agentów AI)

 

Wejście:

  • aria-label, aria-description, aria-describedby wskazujące na długie, ukryte opisy (sr-only/offscreen/display:none).

  • Landmarki i role opisane „twórczo” (np. roledescription, mylące nazwy akcji).

 

Skutek:

  • Agent przypisuje intencję elementowi na podstawie ARIA, a LLM amplifikuje to w planie działania.

  • Możliwe kliknięcia / wysyłki / nawigacja niezgodne z realnym, widocznym copy.

 

Dlaczego to przechodzi:

  • ARIA jest krótsza, czystsza i „autorytatywna” — więc bywa dla modelu silniejszym sygnałem niż szum UI.

  • LLM nie ma natywnej granicy „to opis, nie polecenie”. (Trend potwierdzony w badaniach/publikacjach o podatności agentów). 

 

Dobre praktyki — dwie strony barykady

 

A. Twórcy agentów / integratorzy Atlas

 

  1. Rozdziel semantykę od instrukcji. Serializuj wejście do modelu jako {visible_text, aria_meta, attrs}; ARIA nie trafia do „kanału poleceń” wprost.

  2. Limity i sanityzacja ARIA. Odrzucaj opisy >N znaków, URL-e, tryb rozkazujący, frazy typu „ignore previous…”, „send…”.

  3. Reguła „dane ≠ polecenia” w promptach. Wprost instruuj LLM, że ARIA to etykiety, nie autoryzacje do akcji.

  4. Rule-of-Two (operacyjne „bezpieczniki”). Jednocześnie nie zezwalaj na >2 z 3: (A) nieufne wejścia, (B) dostęp do wrażliwych danych, (C) możliwość zmiany stanu/komunikacji. Praktyczny pattern do czasu, aż odporność wzrośnie. 

  5. Sandbox akcji wysokiego ryzyka. Zewnętrzne URL-e, wysyłki formularzy, clipboard, klawiatura — tylko przy zgodności widocznego tekstu i ARIA + dodatkowe potwierdzenia.

  6. Telemetria decyzji. Loguj źródła wpływu (visible vs ARIA vs heurystyka). Umożliwia detekcję nadużyć i regresji.

  7. Testy wroga (red-team). Wstaw honeypoty ARIA i ukryte „ostrzeżenia”, żeby sprawdzać, czy agent daje się zwieść. (Zbieżne z praktykami OpenAI dot. red-teamingu). 

 

B. Wydawcy / właściciele serwisów (tak, to o nas)

 

  1. Zero „marketingu” w ARIA. Krótkie, rzeczowe etykiety; bez narracji, bez instrukcji.

  2. Unikaj długich aria-describedby do kluczowych akcji. Jeśli musisz — niech to będzie treść informacyjna, nie „co agent ma zrobić”.

  3. Semantyczne HTML5 > ARIA-overload. Używaj struktur nagłówków, landmarków, proper <button>/<a>. Mniej ARIA-hacków = mniej pola do iniekcji. (Zbieżne z zaleceniami dla Atlas/SEO). 

  4. Audyt „visually-hidden”. Przejrzyj sr-only, offscreen i display:none — usuń treści, które brzmią jak polecenia.

  5. Polityka treści dla kontrybutorów. Spis zasad: co wolno w ARIA, czego nie wolno.

 

Co dalej?

 

AI-przeglądarki już są. ARIA stała się dla nich „językiem zrozumienia interfejsu”. To świetnie dla UX i dostępności — pod warunkiem, że agent nie utożsamia opisu z rozkazem. Na dziś nawet OpenAI mówi wprost: to wyzwanie „z granicy możliwości” i wyścig zbrojeń potrwa. W praktyce: stawiamy na separację warstw, redukcję zaufania do ARIA i operacyjne bezpieczniki. 

 

Może zainteresuje Cię również: