Bortom headers och handskak: Web Bot Auth revolutionerar bot-verifiering

Vi har länge lutat oss mot skakiga metoder för att känna igen bots: User-Agent-strängar, IP-adresser och reverse DNS. Det har funkat hyfsat, men det är lätt för en smart angripare att fejka det hela. Med AI-agenter som svämmar över webben känns det som att kolla ID med ficklampa istället för fingeravtryck.

Nu kommer Web Bot Auth, ett experimentellt IETF-protokoll som Google testar för fullt. Det förändrar helt hur vi hanterar bot-autentisering.

Problemen med gamla metoder

Låt oss vara ärliga med läget idag. Traditionell verifiering bygger på:

• User-Agent headers – enkla att ändra eller kopiera
• IP-reputation – bra men opålitlig beroende på plats
• Reverse DNS – hänger på andras infrastruktur
• Begäran-mönster – gissningsbaserat med massa falsklarm

Det stoppar slarviga bots, men inte de seriösa. Och när riktiga AI-agenter blockeras av misstag? Då ringer supporttelefonen non-stop.

Hur Web Bot Auth fungerar

Protokollet ger kryptografisk säkerhet. Istället för att gissa "kommer det här från Google?" verifierar du "är förfrågan kryptografiskt signerad av Google?".

Agenter signerar sina requests med privata nycklar. Servrar validerar med publika nycklar – helt oberoende av IP. Därför blir det så kraftfullt:

• Moln-agenter byter IP hela tiden. Slut på lista-problem.
• Fejk blir omöjligt. Signaturer går inte att lura.
• Full insyn. Du ser exakt vilka agenter som knackar på dörren.

Tänk signerat kontrakt istället för muntlig överenskommelse.

Experimentfasen – var realistisk

Web Bot Auth är inte klart än. Google signerar inte all trafik. IETF-specen uppdateras fortfarande. Det är ingen quick fix – mer en heads-up för framtiden.

Vad betyder det i praktiken?

• Bara delar av Googles bots signeras nu
• Inte alla agenter är med
• Ändringar kan komma när feedback rullar in

Dina gamla metoder behövs kvar. IP, DNS och User-Agent är basen. Web Bot Auth läggs ovanpå.

Så implementerar du det idag

Stora plattformar som Cloudflare, AWS WAF eller Akamai hanterar det ofta automatiskt. Kolla din dashboard – det finns troligen en switch.

För egenhantering, följ de här stegen:

1. Hämta publika nycklar

Ladda Googles nyckelset från https://agent.bot.goog/.well-known/http-message-signatures-directory. Cache:a enligt Cache-Control.

2. Kolla Signature-Agent

Signade requests har Signature-Agent med g="https://agent.bot.goog". Det signalerar signatur.

3. Validera med RFC 9421

Kolla Signature-headern mot Signature-Input. Kryptografin gör jobbet.

4. Hantera utgångstider

Signaturer och nycklar har egna tidsfönster. Validera separat.

5. Ha fallback

Inte alla requests är signerade. Fortsätt med IP, DNS och User-Agent.

Tips för snabbhet: Svara direkt och validera asynkront. Undvik prestandafall.

Varför det påverkar din setup

För API:er, SaaS eller sajter löser det riktiga problem:

• Exakt bot-sortering – skillnad på snälla och onda
• Ren data – analytics utan fejk
• Mindre falsklarm – färre arga kunder
• Framtidssäkert – AI-agenter blir normen

Webben går mot verifierade maskiner som förstklassiga gäster. Web Bot Auth är grunden.

Vad du ska göra nu

1. Kolla din leverantör – Cloudflare eller AWS? Fråga om Web Bot Auth i WAF-inställningarna.

2. Granska din verifiering – Lista hur du jagar bots idag. Var är svagheterna?

3. Håll koll på IETF – Följ working group för updates.

4. Testa med Google – Kontakta deras team för early access.

5. Planera uppgradering – Rita roadmap för verktyg eller custom-lösning.

Den stora bilden

Web Bot Auth visar att bot-trafik är här för att stanna. Att se det som fiende är gammalt. Bättre med kryptografiska ID:n som ger sajter kontroll.

Det är experiment nu. Men experiment blir standarder. Och standarder blir basen.

Handskakstiden är över. Krypto-verifiering tar över. Häng med i kurvan.