De user-agent-allowlist is een van de oudste patronen op het web. Je houdt een lijst bij van crawler- en clientnamen die je vertrouwt. Wanneer een request binnenkomt met een overeenkomende User-Agent-header, laat je het door, sla je een challenge over of serveer je een lichtere pagina. Het kost minuten om op te zetten en iedereen in het team begrijpt het.
Dit patroon had meer zin toen de belangrijkste geautomatiseerde bezoekers uit een handvol zoekmachines en een paar monitoringtools bestonden. Tegenwoordig bereiken AI-agents, assistants en geautomatiseerde clients applicaties in toenemende aantallen, en veel daarvan kondigen een naam aan. Sommige van die namen zijn echt. Sommige zijn gekopieerd. De header kan je niet vertellen welke.
Proof of Actor kiest een andere aanpak. Het behandelt een User-Agent-string voor wat het is, een verklaring, en rapporteert die naast sterker bewijs wanneer dat bewijs bestaat. Deze pagina legt de beperkingen uit van allowlisten op naam, waar controles op netwerk niveau helpen, en hoe geverifieerde signatures en een expliciete Unknown-class het beeld veranderen.
De korte versie
| user-agent-allowlist | Proof of Actor | |
|---|---|---|
| Belangrijkste bewijs | Een naam in de User-Agent-header | Signatures, verklaringen en signalen, elk gelabeld met hun basis |
| Kan een client dit faken? | Ja, door dezelfde string te verzenden | Een declared-basis kan worden geclaimd; een verified-basis vereist de signing key |
| Output | Op de lijst of niet | Human, Human + AI, Agent of Unknown, plus een basis |
| Onduidelijk verkeer | Behandeld als niet-allowlisted, of standaard toegestaan | Unknown, met een fallback die je per route kiest |
| Mensen met AI-assistentie | Onzichtbaar; ze gebruiken gewone browsers | Een aparte class, Human + AI, wanneer gedeclareerd of waargenomen |
| Onderhoud | Handmatige lijstupdates als namen veranderen | Keys gepubliceerd door agent-operators; policies in je code |
| Standaard bij installatie | Wat de lijst toestaat | Observatie; niets verandert totdat je een policy toevoegt |
| Het beste voor | Goedkope routering van goedgedragende, bekende clients | Op bewijs gebaseerde actor-context voor product- en beleidsbeslissingen |
De rest van de pagina legt elke rij uit.
Waarom allowlisten op basis van User-Agent te spoofen zijn
De User-Agent-header wordt ingesteld door de client. Een browser stelt hem in, een script stelt hem in, en een agent-framework stelt hem in. Niets in HTTP controleert of de waarde waar is. Als je allowlist een string vertrouwt, krijgt iedereen die die string kopieert dezelfde behandeling.
Dit heet user agent spoofing, en het is om een eenvoudige reden wijdverbreid: het kost niets. Een scraper die een challenge wil vermijden hoeft alleen de naam te lenen van een crawler die jij vertrouwt. Een client die zich misdraagt kan beweren een populaire assistant te zijn. Een legitieme tool kan zelfs een generieke browser-string verzenden omdat een library-default dat deed.
Het resultaat is dat een user-agent-allowlist twee foutmodi heeft:
- Valse zekerheid: een niet-vertrouwde client claimt een vertrouwde naam en komt binnen.
- Valse twijfel: een legitieme client verzendt een onverwachte of generieke string en faalt.
Geen van beide fouten is zichtbaar uit de header alleen. Dat is de kernbeperking, en geen enkele hoeveelheid lijstonderhoud haalt die weg.
Waar de header nog steeds goed voor is
Dit betekent niet dat je User-Agent-strings moet negeren. Goedgedragende crawlers en agents kondigen zich eerlijk aan, en de naam is een nuttige aanwijzing voor routing, analytics en debugging. Het vertelt je wat een client zegt dat hij is.
De juiste plaats voor die informatie is als een verklaring, gewogen naast ander bewijs, niet als een sleutel die op zichzelf toegang vrijgeeft. Proof of Actor legt het precies zo vast.
Reverse DNS en IP-lijsten: gedeeltelijke maatregelen
Veel teams versterken een allowlist met netwerkcontroles. Ze helpen, en het is de moeite waard om ze precies te begrijpen.
Reverse DNS-verificatie
Sommige crawler-operators documenteren een verificatieproces: zoek de hostname op voor het IP-adres van het request, controleer dat die bij het domein van de operator hoort, zoek vervolgens die hostname op en bevestig dat die terugresolvet naar hetzelfde IP. Wanneer deze round trip slaagt, heb je echt bewijs dat het request afkomstig was van de infrastructuur van de operator.
De grenzen zijn praktisch. Het werkt alleen voor operators die het documenteren en ondersteunen. Het voegt DNS-lookups toe die je moet cachen. En het vertelt je iets over het netwerk, niet over welk product of welke agent het request op dat netwerk heeft gedaan.
Gepubliceerde IP-ranges
Andere operators publiceren de IP-ranges die hun geautomatiseerde clients gebruiken. Een request afstemmen op die ranges is snel en levert vergelijkbaar bewijs op als reverse DNS. Er loopt binnen IETF nog discussie over een standaardformaat voor het publiceren van deze ranges, maar per november 2026 is er geen vaststaande standaard, en de dekking hangt af van elke operator die ervoor kiest om te publiceren.
IP-bewijs verzwakt ook naarmate meer agents draaien op gedeelde cloud-infrastructuur, achter proxies of vanaf het eigen apparaat van een gebruiker. Een cloud-adres kan veel niet-verwante clients hosten, en een agent die vanuit iemands browser handelt ziet eruit als het netwerk van die persoon.
Wat netwerkcontroles samen opleveren
Reverse DNS en IP-lijsten maken van sommige verklaringen iets sterkers voor een subset van bekende operators. Ze dekken de lange staart van agents en tools niet af, en helpen helemaal niet bij mensen die samen met AI werken. Het zijn gedeeltelijke maatregelen: nuttig om te gebruiken, maar niet genoeg op zichzelf.
Signatures versus verklaringen
De sterkere vorm van bewijs is een cryptografische signature. Met HTTP Message Signatures, gedefinieerd in RFC 9421, ondertekent een client geselecteerde delen van elk request met een private key. De verifier haalt de gepubliceerde public key van de operator op en controleert de signature. Als die geverifieerd wordt, is het request ondertekend door de houder van die key, en zijn de ondertekende delen onderweg niet gewijzigd.
De IETF Web Bot Auth working group standardiseert hoe geautomatiseerde clients deze signatures gebruiken en hoe zij hun keys publiceren. Onze uitleg over Web Bot Auth voor productteams behandelt de huidige status.
Proof of Actor gebruikt een geldige signature als verified bewijs. Een User-Agent-string, een client hint of een zelfbeschrijving in een request body geldt als declared. Gedrags- en contextsignalen gelden als inferred, en worden zo gelabeld. Elk resultaat vermeldt op welke basis het rust, zodat je team een bewering nooit verwart met een controle. Zie de vermelding evidence basis voor de volledige definities.
Eén beperking geldt zelfs voor verified bewijs. Een geldige signature bewijst welke key het request heeft ondertekend. Het bewijst niet dat de agent mag doen wat hij vraagt te doen. Dat is een agent authorization-vraag, en die blijft in je applicatie.
Unknown afhandelen in plaats van gokken
Een allowlist dwingt elk request in een van twee buckets: op de lijst of niet. In de praktijk betekent dat dat onduidelijk verkeer krijgt wat je default ook maar is, en die default wordt meestal één keer gekozen voor de hele site.
Proof of Actor behandelt Unknown als een eersteklas resultaat. Wanneer het bewijs geen betrouwbare vaststelling ondersteunt, zegt het dat in plaats van te gokken. Je policies bepalen vervolgens wat Unknown betekent op elke route:
- Op publieke documentatie- of marketingpagina's: toestaan.
- Op zoek- of listing-endpoints: toestaan met je normale rate limits.
- Bij accountwijzigingen: je bestaande controles behouden.
- Bij acties met grote impact: doorsturen naar review of om een sterker signaal vragen.
De gids over Unknown-verkeer afhandelen en de vermelding unknown classification lopen door de patronen heen. Je Unknown-rate in de tijd volgen vertelt je ook hoeveel van je verkeer nog steeds op zwak bewijs rust.
En mensen met AI-assistentie dan?
Een user-agent-allowlist zegt niets over een persoon die een AI-assistent gebruikt in een gewone browser. Hun User-Agent is een normale browser-string. Toch willen veel producten die interactie herkennen, bijvoorbeeld om AI-gegenereerde inzendingen te labelen of te begrijpen hoe AI-ondersteunde gebruikers door onboarding bewegen.
Proof of Actor rapporteert deze interacties als Human + AI wanneer de ondersteuning gedeclareerd is of waargenomen wordt via een ondersteunde integratie. Het raadt niet op basis van schrijfstijl alleen. Lees meer in AI-assisted interaction.
Van een allowlist naar op bewijs gebaseerde policies
Je hoeft je allowlist niet op dag één te verwijderen. Een veilige route ziet er als volgt uit:
- Installeer in observatiemodus. Proof of Actor verandert niets. Je allowlist blijft werken.
- Vergelijk. Bekijk per route welke allowlisted requests geverifieerd bewijs dragen, welke alleen een verklaring dragen en welke uiteindelijk Unknown zijn.
- Preview policies. Stel een policy op die verified agents, declared agents en Unknown verschillend behandelt, en bekijk het effect op echt verkeer vooraf.
- Enforce route voor route. Begin met de routes waar een gespoofte naam het meeste uitmaakt.
- Gebruik de allowlist als hint. Namen blijven nuttig voor routing en analytics, nu met hun basis zichtbaar.
De gids over actor-aware policies veilig uitrollen behandelt elke stap, en verified automated requests legt uit hoe ondertekende clients hierin passen.
Wanneer een allowlist voldoende is
Voor routeerbeslissingen met weinig risico, zoals het tonen van een lichtere pagina aan een bekende crawler op publieke content, is een user-agent-allowlist vaak prima. De kosten van een gespoofte naam zijn klein.
Wanneer de beslissing gevolgen heeft, zoals een challenge overslaan, rijkere data tonen of een write toestaan, wil je bewijs dat je kunt controleren. Daar hoort Proof of Actor thuis, naast de netwerkcontroles en edge-controls die je al draait.
Aan de slag
Proof of Actor bevindt zich in private beta. Geselecteerde founding developer-teams kunnen tot 12 maanden gratis toegang krijgen binnen afgesproken gebruikslimieten, zonder automatische facturering. Vraag early access aan en laat ons weten welke clients je vandaag allowlist en welke routes je met beter bewijs wilt beschermen.