Web Bot Auth: az aláírt AI-ügynökök azonosítása a szerveren

Scheo · 2026-10-30 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha megnyitod egy WordPress-oldal hozzáférési naplóját, a sorok nagy részét ma is a user-agent alapján sorolod be. A Googlebot és a GPTBot bemondja a nevét, a böngészők Chrome-nak vagy Safarinak mondják magukat. A Web Bot Auth erre a bizalmi modellre ad kriptográfiai választ. A bot minden kérését digitálisan aláírja, a szerver vagy a CDN pedig ellenőrzi, hogy az aláírás tényleg attól a szereplőtől jön, akinek a nevét a kérés viseli. A cikk végigveszi a működést, a jelenlegi támogatottságot és a naplóbeli nyomokat. Azt is megnézzük, mit érdemes lépni egy olyan KKV-s WordPress-oldalon, amelyik nem Cloudflare mögött fut.

A szövegben háromféle jelölést használunk. A [Hivatalosan igazolt] szabványra, tervezetre vagy szolgáltatói dokumentációra épül. A [Saját tapasztalat] azt jelöli, amit WordPress-oldalak üzemeltetése közben látunk. A [Szakmai feltételezés] olyan következtetés, amelyet még nem mértünk ki, és szabvány sem rögzít.

Mi az a Web Bot Auth, és mit jelent az aláírt ügynök?

A Web Bot Auth olyan eljárás, amelyben egy bot vagy AI-ügynök a HTTP-kéréseit saját privát kulcsával aláírja, és a hozzá tartozó nyilvános kulcsot egy ismert címen közzéteszi, így a fogadó oldal ellenőrizni tudja, ki küldte a kérést. Az „aláírt ügynök” (signed agent) olyan automatizált kliens, amelyik ezt a módszert használja.

[Hivatalosan igazolt] Az alap az IETF RFC 9421 szabványa (HTTP Message Signatures), amely leírja, hogyan lehet egy HTTP-üzenet kiválasztott részeit aláírni és ellenőrizni. A botokra szabott architektúrát IETF-tervezetek (Internet-Draft) írják le, a szabványosításon az IETF webbotauth munkacsoportja dolgozik. A Cloudflare 2025 tavaszán mutatta be nyilvánosan a megközelítést. Nyáron „signed agents” néven külön kategóriát is létrehozott a bot-ellenőrzési programjában azoknak az ügynököknek, amelyek egy felhasználó nevében böngésznek.

A crawler és az ügynök között lényeges a különbség. A crawler (például egy keresőmotor vagy egy tanítóadat-gyűjtő bot) a saját céljára jár végig oldalakat. Az ügynök egy konkrét ember kérésére nyit meg egy oldalt, kitölt egy űrlapot vagy összehasonlít árakat. Az aláírás mindkettőt azonosítja, a hozzáférési döntés viszont gyakran más a kettőnél.

Miben más, mint a user-agent vagy az IP-tartomány alapján történő ellenőrzés?

A user-agent szabadon beírható szöveg, az IP-tartomány hálózati helyet jelöl, az aláírás pedig azt bizonyítja, hogy a küldő birtokolja a kulcsot. A három módszer ezért eltérő erősségű bizonyítékot ad.

• User-agent. Bárki beírhatja, hogy „GPTBot” vagy „Googlebot”. Önmagában semmit nem bizonyít, csak a jóhiszemű botok önbevallása.
• IP-tartomány és fordított DNS. A nagy szolgáltatók (Google, OpenAI, Microsoft) közzéteszik, mely IP-címekről érkeznek a crawlereik. Ez erősebb ellenőrzés, de a listákat karban kell tartani. A felhős infrastruktúrán futó ügynököknél ráadásul az IP-cím gyakran más ügyfelek forgalmával közös.
• Kriptográfiai aláírás. Az ellenőrzés a kérés tartalmához és időpontjához kötött. Lemásolt fejléccel nem lehet érvényes kérést hamisítani, mert az aláírás a kérés adataira és egy lejárati időre vonatkozik. A privát kulcs nélkül új aláírás nem készíthető.

[Szakmai feltételezés] Az IP-alapú ellenőrzés a böngészőt vezérlő ügynököknél gyengül a leginkább. Ezek gyakran felhős böngészőszolgáltatáson vagy változó hálózaton futnak, így az IP-cím keveset mond arról, melyik termék és kinek a megbízásából küldte a kérést.

Hogyan működik egy aláírt kérés lépésről lépésre?

Az ügynök közzéteszi a nyilvános kulcsát, és minden kéréshez aláírást csatol. A fogadó oldal letölti a kulcsot, majd ellenőrzi az aláírást és annak érvényességi idejét. A folyamat négy lépésből áll.

1. Az ügynök üzemeltetője kulcspárt készít (a tervezetek az Ed25519 algoritmust használják), és a nyilvános kulcsot JWKS formában kiteszi a saját domainjén a /.well-known/http-message-signatures-directory útvonalra.
2. Kéréskor az ügynök három fejlécet küld. A Signature-Agent megmondja, hol található a kulcskönyvtár. A Signature-Input felsorolja az aláírt elemeket és a paramétereket (létrehozás ideje, lejárat, kulcsazonosító, tag="web-bot-auth"). A Signature maga az aláírás.
3. A fogadó oldal (CDN, WAF vagy maga a szerver) letölti és gyorsítótárazza a kulcskönyvtárat, majd az RFC 9421 szerint újraépíti az aláírt adatsort.
4. Ha az aláírás érvényes és nem járt le, a kérés azonosítottnak számít. Hogy ezután átengeded, korlátozod vagy tiltod, az már a te szabályodon múlik.

Egy leegyszerűsített fejlécsor így néz ki (a pontos formátum a tervezet verziójától függően változhat).

Signature-Agent: "https://agent.example.com"

Signature-Input: sig1=("@authority" "signature-agent");created=1761810000;expires=1761810060;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";tag="web-bot-auth"

Signature: sig1=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:

[Hivatalosan igazolt] Az aláírás nem jelent engedélyt. Az ellenőrzés csak azt mondja meg, ki küldte a kérést. A robots.txt, a sebességkorlát és a saját üzleti szabályaid továbbra is érvényesek.

Mely szolgáltatók és CDN-ek támogatják jelenleg?

Az ellenőrzésben a Cloudflare a legkiforrottabb, mellette az AWS WAF és az Akamai is nyilvánosan bejelentette a támogatást. A kéréseit aláíró ügynökök között ott van az OpenAI ChatGPT-ügynöke és több böngészőautomatizálási szolgáltatás. A lista gyorsan változik, ezért döntés előtt mindig nézd meg az adott szolgáltató aktuális dokumentációját.

Ellenőrző oldal (CDN, WAF)

• Cloudflare. [Hivatalosan igazolt] A támogatás a Verified Bots és a signed agents program része, az ellenőrzött ügynökök a bot-kezelési szabályokban külön kategóriaként kezelhetők. A Cloudflare a referencia-implementációt nyílt forráskóddal is közzétette.
• AWS WAF (CloudFront előtt). [Hivatalosan igazolt] Az AWS bejelentette, hogy a Bot Control képes a Web Bot Auth szerint aláírt kérések ellenőrzésére. A pontos csomag- és szabálybeállítást az AWS dokumentációjában érdemes ellenőrizni.
• Akamai. [Hivatalosan igazolt] Az Akamai nyilvánosan jelezte, hogy támogatja az aláírt ügynökök azonosítását, többek között a fizetési ügynökprotokollokkal összefüggésben.

Aláíró oldal (ügynökök)

• OpenAI. [Hivatalosan igazolt] Az OpenAI dokumentációja szerint a ChatGPT ügynökmódja aláírja a kéréseit, a Signature-Agent fejléc értéke a https://chatgpt.com címre mutat.
• Fizetési ügynökprotokollok. [Hivatalosan igazolt] A Visa Trusted Agent Protocolja a Web Bot Auth aláírására épül. Ezzel a kereskedő meg tudja különböztetni a vásárlásra jogosított ügynököt az ismeretlen automatától.
• Böngészőautomatizálási platformok. Több felhős böngészőszolgáltatás jelentette be, hogy a rajta futó ügynökök aláírt kéréseket küldhetnek. Hogy egy adott termék ténylegesen aláír-e, azt a saját naplódból tudod a legmegbízhatóbban kideríteni.

[Szakmai feltételezés] A klasszikus keresőcrawlerek (Googlebot, Bingbot) ellenőrzése a közeljövőben jó eséllyel továbbra is IP-listán és fordított DNS-en alapul. Az aláírás elsősorban az ügynököknél és az új AI-szereplőknél terjed.

Hogyan látszik egy aláírt kérés a szervernaplóban?

Az alapértelmezett Apache- és nginx-naplóformátum nem rögzíti a Signature fejléceket, ezért a naplóban egy aláírt ügynök általában ugyanúgy néz ki, mint egy átlagos böngésző. Ha látni akarod, külön naplómezőt kell felvenned.

[Saját tapasztalat] Az általunk kezelt WordPress-oldalakon a bot-szűrést többnyire a tárhely szintjén vagy biztonsági bővítménnyel oldják meg, és ezek alapbeállításban nem írják ki ezeket a fejléceket. Amíg nem bővíted a naplót, nem tudod megmondani, érkezik-e egyáltalán aláírt forgalom.

Nginx alatt egy kiegészített naplóformátum így vehető fel.

log_format botauth '$remote_addr [$time_local] "$request" $status "$http_user_agent" sa="$http_signature_agent" si="$http_signature_input"';

access_log /var/log/nginx/botauth.log botauth;

Apache alatt ugyanezt a LogFormat sorban a %{Signature-Agent}i és a %{Signature-Input}i mezővel éred el. Egy ilyen naplósorban a user-agent lehet egy teljesen hétköznapi Chrome-azonosító, miközben az sa= mezőben ott áll az ügynök kulcskönyvtárának címe. Ezen látszik a legjobban, miért kevés a user-agent alapú besorolás.

Két dologra figyelj. A fejléc jelenléte még nem bizonyíték, mert bárki beküldheti. Ha pedig CDN van előtted, az ellenőrzés eredményét a CDN saját naplója vagy egy általa továbbadott fejléc mutatja meg, a te szervered csak a nyers fejléceket látja.

Mit tehet egy KKV-s WordPress-oldal, amelyik nem Cloudflare mögött fut?

Először naplózással mérd fel, érkezik-e aláírt forgalom. Szabályt csak akkor építs rá, ha valahol ténylegesen ellenőrzik az aláírást, mert a puszta fejléc alapján átengedni kockázatos. A gyakorlati sorrend a következő.

1. Naplózás bekapcsolása. Ha hozzáférsz a webszerver konfigurációjához, használd a fenti naplóformátumot. Osztott tárhelyen egy kis must-use bővítmény is elég a wp-content/mu-plugins/ mappában.
2. Két-négy hét adatgyűjtés. Nézd meg, mely Signature-Agent értékek jönnek, milyen oldalakra, és kaptak-e 403-as vagy 429-es választ.
3. A blokkolás okának megkeresése. Ha a biztonsági bővítmény vagy a tárhely bot-védelme aláírt kéréseket utasít el, ott döntsd el, kell-e változtatni rajta.
4. Ellenőrzési pont választása. Ha kell külön szabály, az a legegyszerűbb, ha az oldal elé olyan CDN vagy WAF kerül, amelyik elvégzi az ellenőrzést. A saját PHP-ellenőrzés technikailag megoldható, mert a PHP libsodium bővítménye ismeri az Ed25519 ellenőrzést. Az RFC 9421 szerinti aláírt adatsor helyes összerakásában, a kulcskönyvtár gyorsítótárazásában és a lejárat kezelésében viszont könnyű hibázni.
5. Szűk szabály. Ha átengedsz, csak a kiválasztott, ellenőrzött ügynököt engedd, csak azokon az útvonalakon, ahol tényleg dolga van, és sebességkorláttal.

Lent látod a naplózó must-use bővítmény minimális változatát. Csak akkor ír a naplóba, ha a kérésben szerepel a fejléc.

<?php add_action( 'init', function () { if ( empty( $_SERVER['HTTP_SIGNATURE_AGENT'] ) ) { return; } error_log( sprintf( '[webbotauth] %s %s sa=%s ua=%s', $_SERVER['REMOTE_ADDR'] ?? '', $_SERVER['REQUEST_URI'] ?? '', substr( $_SERVER['HTTP_SIGNATURE_AGENT'], 0, 200 ), substr( $_SERVER['HTTP_USER_AGENT'] ?? '', 0, 200 ) ) ); } );

[Saját tapasztalat] A teljes oldalas gyorsítótár (például egy cache-bővítmény vagy a tárhely saját gyorsítótára) a kérések egy részét a PHP elindítása nélkül szolgálja ki. Ilyenkor a fenti kód csak a gyorsítótárat megkerülő kéréseket látja, ezért a webszerver szintű naplózás pontosabb képet ad.

[Szakmai feltételezés] Egy tipikus bemutatkozó KKV-oldalon, ahol nincs agresszív bot-védelem, az aláírt ügynökök ma is akadály nélkül olvassák a tartalmat. Itt a naplózás a fő teendő, külön átengedő szabályra jó eséllyel nincs szükség.

Mikor érdemes az aláírt ügynököket külön szabállyal átengedni, és mikor elég a meglévő bot-szűrés?

Külön szabály akkor éri meg, ha a meglévő védelmed az ügynököket tévesen blokkolja, és ez üzleti kárt okoz. Ha az ügynökök ma is gond nélkül elérik az oldalt, a meglévő szűrés elég.

Érdemes külön szabályt felvenni, ha

• webshopot üzemeltetsz, és számítasz arra, hogy vásárlók ügynökön keresztül keresnek, kosaraznak vagy fizetnek;
• JavaScript-kihívást, CAPTCHA-t vagy országszűrést használsz, és a naplóban aláírt kérések kapnak 403-as választ;
• az oldalad már olyan CDN vagy WAF mögött van, amelyik ellenőrzi az aláírást, így a szabály beállítása néhány kattintás;
• foglalási, ajánlatkérő vagy időpontkérő folyamatod van, amelyet ügynök is elindíthat a felhasználó nevében.

Elég a meglévő bot-szűrés, ha

• bemutatkozó oldalad van kihívás vagy CAPTCHA nélkül, és az ügynökök ma is elérik;
• osztott tárhelyen futsz CDN nélkül, és ellenőrző réteget nem tudsz beiktatni;
• a naplóban nincs vagy elhanyagolható az aláírt forgalom;
• a fő kérdésed a tanítóadat-gyűjtő crawlerek kezelése, amire a robots.txt és a user-agent alapú szabály ma is használható.

Aláírás nélküli kérést mindkét esetben tilos csak azért átengedni, mert a user-agentje egy ismert ügynök nevét viseli. Az aláírt ügynök se kapjon korlátlan hozzáférést, a sebességkorlát és az admin-útvonalak tiltása maradjon érvényben.

Miért lesz az azonosítás a hozzáférés-szabályozás alapja?

[Szakmai feltételezés] Az AI-ügynökök valódi böngészőmotort futtatnak, ezért a forgalmuk viselkedésben és fejlécekben egyre kevésbé választható el az emberi látogatókétól. Ahol a megfigyelés elveszíti a megkülönböztető erejét, ott a döntést a kérés azonosítására lehet építeni.

A régi bot-szűrés arra épült, hogy a bot másképp viselkedik. Nem futtat JavaScriptet, nem tölti be a képeket, túl gyorsan kattint. Egy felhőben futó, Chromiumot vezérlő ügynök ezeken a próbákon jó eséllyel átmegy, mert tényleg böngésző. Ilyenkor két rossz lehetőség marad. Vagy szigorítod a kihívásokat, és velük együtt a valódi vásárlókat is zavarod, vagy lemondasz az ellenőrzésről. Az aláírással van egy harmadik út is. A jóhiszemű ügynök bemutatkozik, ezt kriptográfiailag igazolja, te pedig szereplőnként döntesz.

Ebből következik, hogy a hozzáférési szabályok idővel jó eséllyel kétrétegűek lesznek. Az azonosított ügynökök név szerinti szabályt kapnak (olvashat, vásárolhat, csak bizonyos útvonalakat érhet el). Az azonosítatlan automatizált forgalom a szigorúbb, viselkedésalapú szűrésen megy át. Egy KKV-oldalon ehhez most annyi a teendő, hogy lásd a saját forgalmadat, és ne zárd ki vakon azokat az ügynököket, amelyeken keresztül a vásárlóid már keresnek.

A szabvány még tervezet, a fejlécformátum változhat, és nem minden ügynök ír alá. A Web Bot Auth ezért ma kiegészíti a user-agent és IP alapú ellenőrzést, egyik sem váltja ki a másikat. Ha most beállítod a naplózást, a későbbi döntést már adatra alapozhatod.

Források és további olvasnivalók

• IETF RFC 9421, HTTP Message Signatures
• IETF Internet-Draft, Web Bot Auth architektúra és HTTP Message Signatures Directory (webbotauth munkacsoport)
• Cloudflare Developers dokumentáció, Web Bot Auth és Signed Agents
• OpenAI dokumentáció, ChatGPT agent és a kérések aláírása
• AWS WAF dokumentáció, Bot Control
• Visa Developer, Trusted Agent Protocol
• Google Search Central, a Google crawlereinek ellenőrzése