Die User-Agent-Allowlist ist eines der ältesten Muster im Web. Sie führen eine Liste von Crawler- und Client-Namen, denen Sie vertrauen. Wenn ein Request mit einem passenden User-Agent-Header ankommt, lassen Sie ihn durch, überspringen eine Challenge oder liefern eine leichtere Seite aus. Die Einrichtung dauert Minuten und jeder im Team versteht das Muster.
Das Muster war sinnvoller, als die wichtigsten automatisierten Besucher nur aus einigen Suchcrawlern und wenigen Monitoring-Tools bestanden. Heute erreichen AI-Agenten, Assistenten und automatisierte Clients Anwendungen in wachsender Zahl, und viele von ihnen kündigen sich mit einem Namen an. Einige dieser Namen sind echt. Einige sind kopiert. Der Header kann Ihnen nicht sagen, welche.
Proof of Actor geht anders vor. Es behandelt eine User-Agent-Zeichenfolge als das, was sie ist, eine Erklärung, und stellt sie zusammen mit stärkerer Evidenz dar, wenn diese Evidenz vorhanden ist. Auf dieser Seite werden die Grenzen des Allowlistings nach Namen erklärt, wo Prüfungen auf Netzwerkebene helfen und wie verifizierte Signaturen und eine explizite Unknown-Klasse das Bild verändern.
Die Kurzfassung
| User-Agent-Allowlist | Proof of Actor | |
|---|---|---|
| Hauptevidenz | Ein Name im User-Agent-Header | Signaturen, Erklärungen und Signale, jeweils mit ihrer Basis gekennzeichnet |
| Kann ein Client das fälschen? | Ja, durch Senden derselben Zeichenfolge | Eine declared-Basis kann behauptet werden; eine verified-Basis erfordert den Signaturschlüssel |
| Ausgabe | Auf der Liste oder nicht | Human, Human + AI, Agent oder Unknown, plus eine Basis |
| Unklare Traffic | Als nicht allowlisted behandelt oder standardmäßig erlaubt | Unknown, mit einem Fallback, den Sie pro Route festlegen |
| Menschen mit AI-Unterstützung | Unsichtbar; sie nutzen normale Browser | Eine eigene Klasse, Human + AI, wenn erklärt oder beobachtet |
| Wartung | Manuelle Listenpflege, wenn sich Namen ändern | Von Agentenbetreibern veröffentlichte Schlüssel; Policies in Ihrem Code |
| Standard bei der Installation | Was auch immer die Liste erlaubt | Beobachtung; nichts ändert sich, bis Sie eine Policy hinzufügen |
| Am besten geeignet für | Kostengünstiges Routing von gutartigen, bekannten Clients | Evidenzbasierter Actor-Kontext für Produkt- und Policy-Entscheidungen |
Der Rest der Seite erklärt jede Zeile.
Warum Allowlisting über User-Agent fälschbar ist
Der User-Agent-Header wird vom Client gesetzt. Ein Browser setzt ihn, ein Skript setzt ihn, und ein Agent-Framework setzt ihn. Nichts in HTTP prüft, ob der Wert wahr ist. Wenn Ihre Allowlist einer Zeichenfolge vertraut, bekommt jeder, der diese Zeichenfolge kopiert, die gleiche Behandlung.
Das nennt man user agent spoofing, und es ist aus einem einfachen Grund weit verbreitet: Es kostet nichts. Ein Scraper, der eine Challenge vermeiden will, muss nur den Namen eines Crawler ausleihen, dem Sie vertrauen. Ein fehlerhaft arbeitender Client kann behaupten, ein beliebter Assistent zu sein. Ein legitimes Tool kann sogar eine generische Browser-Zeichenfolge senden, weil es der Standard der Bibliothek war.
Das Ergebnis ist, dass eine User-Agent-Allowlist zwei Fehlermodi hat:
- Falsches Vertrauen: Ein nicht vertrauenswürdiger Client behauptet einen vertrauenswürdigen Namen und wird durchgelassen.
- Falscher Zweifel: Ein legitimer Client sendet eine unerwartete oder generische Zeichenfolge und scheitert.
Keiner dieser Fehler ist allein aus dem Header sichtbar. Das ist die zentrale Grenze, und keine noch so sorgfältige Listenpflege beseitigt sie.
Wofür der Header trotzdem gut ist
Das bedeutet nicht, dass Sie User-Agent-Zeichenfolgen ignorieren sollten. Gutartige Crawler und Agenten kündigen sich ehrlich an, und der Name ist ein nützlicher Hinweis für Routing, Analytics und Debugging. Er sagt Ihnen, was ein Client über sich selbst behauptet.
Der richtige Ort für diese Information ist als Erklärung, gewichtet neben anderer Evidenz, nicht als Schlüssel, der allein Zugang freischaltet. Proof of Actor erfasst sie genau so.
Reverse DNS und IP-Listen: Teilmaßnahmen
Viele Teams verstärken eine Allowlist mit Netzwerkprüfungen. Sie helfen, und es lohnt sich, sie genau zu verstehen.
Reverse-DNS-Prüfung
Manche Crawler-Betreiber dokumentieren einen Verifizierungsprozess: den Hostnamen zur IP-Adresse des Requests nachschlagen, prüfen, ob er zur Domain des Betreibers gehört, dann diesen Hostnamen erneut nachschlagen und bestätigen, dass er auf dieselbe IP auflöst. Wenn dieser Rundlauf erfolgreich ist, haben Sie echte Evidenz dafür, dass der Request aus der Infrastruktur des Betreibers kam.
Die Grenzen sind praktischer Natur. Das funktioniert nur für Betreiber, die es dokumentieren und unterstützen. Es fügt DNS-Lookups hinzu, die Sie cachen müssen. Und es sagt Ihnen etwas über das Netzwerk, nicht darüber, welches Produkt oder welcher Agent den Request in diesem Netzwerk ausgelöst hat.
Veröffentlichte IP-Bereiche
Andere Betreiber veröffentlichen die IP-Bereiche, die ihre automatisierten Clients verwenden. Ein Abgleich eines Requests mit diesen Bereichen ist schnell und liefert eine ähnliche Evidenz wie Reverse DNS. Es gibt laufende IETF-Diskussionen über ein Standardformat für die Veröffentlichung dieser Bereiche, aber Stand November 2026 gibt es keinen festgelegten Standard, und die Abdeckung hängt davon ab, dass jeder Betreiber veröffentlicht.
IP-Evidenz wird auch schwächer, wenn mehr Agenten auf gemeinsamer Cloud-Infrastruktur, hinter Proxies oder vom eigenen Gerät eines Benutzers aus laufen. Eine Cloud-Adresse kann viele nicht zusammenhängende Clients hosten, und ein Agent, der im Browser einer Person agiert, sieht aus wie das Netzwerk dieser Person.
Was Netzwerkprüfungen zusammen leisten
Reverse DNS und IP-Listen machen aus einigen Erklärungen für eine Teilmenge bekannter Betreiber etwas Stärkeres. Sie decken nicht den langen Tail von Agenten und Tools ab, und sie helfen überhaupt nicht bei Menschen, die gemeinsam mit AI arbeiten. Es sind Teilmaßnahmen: nützlich, aber allein nicht ausreichend.
Signaturen versus Erklärungen
Die stärkere Form von Evidenz ist eine kryptografische Signatur. Mit HTTP Message Signatures, definiert in RFC 9421, signiert ein Client ausgewählte Teile jedes Requests mit einem privaten Schlüssel. Der Verifizierer ruft den veröffentlichten öffentlichen Schlüssel des Betreibers ab und prüft die Signatur. Wenn sie verifiziert, wurde der Request vom Inhaber dieses Schlüssels signiert, und die signierten Teile wurden unterwegs nicht verändert.
Die IETF Web Bot Auth-Arbeitsgruppe standardisiert, wie automatisierte Clients diese Signaturen verwenden und wie sie ihre Schlüssel veröffentlichen. Unsere Erläuterung zu Web Bot Auth für Produktteams beschreibt den aktuellen Stand.
Proof of Actor verwendet eine gültige Signatur als verified-Evidenz. Eine User-Agent-Zeichenfolge, ein Client-Hint oder eine Selbstdarstellung im Request-Body zählt als declared. Verhaltens- und Kontextsignale zählen als inferred und werden auch so gekennzeichnet. Jedes Ergebnis gibt an, worauf es beruht, damit Ihr Team niemals eine Behauptung mit einer Prüfung verwechselt. Siehe den Eintrag zur evidence basis für die vollständigen Definitionen.
Eine Grenze gilt selbst für verifizierte Evidenz. Eine gültige Signatur beweist, welcher Schlüssel den Request signiert hat. Sie beweist nicht, dass der Agent das tun darf, was er zu tun anfragt. Das ist eine Frage der agent authorization, und sie bleibt in Ihrer Anwendung.
Unknown behandeln statt zu raten
Eine Allowlist zwingt jeden Request in einen von zwei Behältern: auf der Liste oder nicht. Praktisch bedeutet das, dass unklare Traffic den Standardwert bekommt, und dieser Standard wird meist einmal für die gesamte Website festgelegt.
Proof of Actor behandelt Unknown als erstklassiges Ergebnis. Wenn die Evidenz keine verlässliche Bestimmung trägt, sagt es das, statt zu raten. Ihre Policies entscheiden dann, was Unknown auf jeder Route bedeutet:
- Auf öffentlichen Dokumentations- oder Marketingseiten erlauben.
- Bei Such- oder Listing-Endpunkten mit Ihren normalen Rate Limits erlauben.
- Bei Kontenänderungen die bestehenden Prüfungen beibehalten.
- Bei Aktionen mit hoher Auswirkung zur Review schicken oder ein stärkeres Signal anfordern.
Der Leitfaden zum handling Unknown traffic und der Eintrag zur unknown classification gehen die Muster durch. Wenn Sie Ihre Unknown-Rate im Zeitverlauf verfolgen, sehen Sie außerdem, wie viel Ihres Traffics noch auf schwacher Evidenz beruht.
Und was ist mit Menschen mit AI-Unterstützung?
Eine User-Agent-Allowlist sagt nichts über eine Person aus, die in einem normalen Browser einen AI-Assistenten nutzt. Ihr User-Agent ist eine normale Browser-Zeichenfolge. Dennoch möchten viele Produkte diese Interaktion erkennen, etwa um AI-entworfene Einsendungen zu kennzeichnen oder zu verstehen, wie sich AI-unterstützte Nutzer durch das Onboarding bewegen.
Proof of Actor stuft diese Interaktionen als Human + AI ein, wenn die Unterstützung über eine unterstützte Integration erklärt oder beobachtet wird. Es rät nicht allein aus dem Schreibstil. Mehr dazu in AI-assisted interaction.
Vom Allowlist zur evidenzbasierten Policy
Sie müssen Ihre Allowlist nicht am ersten Tag entfernen. Ein sicherer Weg sieht so aus:
- Im Beobachtungsmodus installieren. Proof of Actor ändert nichts. Ihre Allowlist funktioniert weiter.
- Vergleichen. Sehen Sie für jede Route, welche allowlisted Requests verifizierte Evidenz tragen, welche nur eine Erklärung tragen und welche als Unknown enden.
- Policies in der Vorschau prüfen. Entwerfen Sie eine Policy, die verifizierte Agenten, deklarierte Agenten und Unknown unterschiedlich behandelt, und sehen Sie sich ihre Wirkung auf realem Traffic an.
- Route für Route durchsetzen. Beginnen Sie mit den Routen, bei denen ein gefälschter Name am meisten ausmachen würde.
- Die Allowlist als Hinweis behalten. Namen bleiben für Routing und Analytics nützlich, jetzt mit sichtbarer Basis.
Der Leitfaden zu rolling out actor-aware policies safely beschreibt jeden Schritt, und verified automated requests erklärt, wie signierte Clients einbezogen werden.
Wann eine Allowlist ausreicht
Für Routing mit geringem Risiko, etwa eine leichtere Seite für einen bekannten Crawler auf öffentlichen Inhalten auszuliefern, ist eine User-Agent-Allowlist oft ausreichend. Die Kosten eines gefälschten Namens sind gering.
Wenn die Entscheidung Konsequenzen hat, etwa eine Challenge zu überspringen, reichere Daten offenzulegen oder einen Write zuzulassen, wollen Sie Evidenz, die Sie prüfen können. Dort gehört Proof of Actor hin, zusammen mit den Netzwerkprüfungen und Edge-Kontrollen, die Sie bereits betreiben.
Jetzt loslegen
Proof of Actor befindet sich in der Private Beta. Ausgewählte Founding-Developer-Teams können innerhalb der vereinbarten Nutzungsgrenzen bis zu 12 Monate lang kostenlosen Zugang erhalten, ohne automatische Abrechnung. Bewerben Sie sich für Early Access und teilen Sie uns mit, welche Clients Sie heute allowlisten und welche Routen Sie mit besserer Evidenz schützen möchten.