Der Traffic, den niemand benennen kann
Wer genau in die Logs einer Anwendung schaut, findet Requests, die sich einer Erklärung entziehen. Sie kommen von Clients ohne Browser-Kontext. Ihre User-Agent-Strings sind generisch, leer oder von einem verbreiteten Browser kopiert. Sie signieren ihre Requests nicht. Sie sagen nicht, wer sie gesendet hat. Einige sind harmlose Skripte. Einige sind Agenten, die für echte Nutzer arbeiten. Einige sind Tools, die Sie lieber gar nicht bedienen würden.
Das ist unbekannter automatisierter Traffic, und die meisten Teams gehen damit auf eine von zwei Arten um. Entweder wird er stillschweigend als menschlich gezählt, was Analysen verzerrt und riskante Aktivität durchlässt, oder er wird standardmäßig als feindlich behandelt, was legitime Nutzer und Agenten zusammen mit allem anderen blockiert. Beide Ansätze haben denselben Fehler: Sie ersetzen fehlende Evidenz durch eine Annahme.
Proof of Actor nimmt die entgegengesetzte Position ein. Wenn die Evidenz keine belastbare Bestimmung trägt, lautet die richtige Antwort Unknown, und Unknown sollte sichtbar, messbar und bewusst behandelt werden. Der Blogbeitrag warum Unknown ein gültiges Ergebnis für KI-Traffic ist führt die Argumentation vollständig aus.
Warum Unknown ein erstklassiges Ergebnis ist
Proof of Actor klassifiziert jede Interaktion in eine von vier Klassen: Human, Human + AI, Agent oder Unknown. Unknown ist kein Fehlerzustand und keine Lücke im Produkt. Es ist ein bewusstes Ergebnis mit präziser Bedeutung: Die verfügbaren Evidenzen reichen nicht für eine belastbare Bestimmung aus.
Diese Ehrlichkeit hat praktische Vorteile.
- Ihre Analysen bleiben korrekt. Human- und Agent-Zahlen enthalten nur Interaktionen mit unterstützender Evidenz, sodass sie das bedeuten, was sie sagen.
- Ihre Abdeckung ist messbar. Der Anteil von Unknown auf jeder Route zeigt Ihnen genau, wo Sie mehr Evidenz benötigen.
- Ihre Policies sind sicherer. Unsichere Fälle laufen in einen von Ihnen gewählten Fallback, statt stillschweigend als vertrauenswürdig zu gelten oder durch eine Vermutung blockiert zu werden.
Unknown wird niemals zu Human umgedeutet, und es wird standardmäßig nie als bösartig behandelt. Mehr dazu finden Sie im Glossareintrag Unknown-Klassifizierung, auf Detection & Limitations und in warum Unknown ein gültiges Ergebnis für KI-Traffic ist. Die Anwendungsfälle Websites und APIs zeigen, wie Teams Unknown-Fallbacks in der Praxis einsetzen.
Woher unbekannter automatisierter Traffic kommt
Wenn Sie die Quellen verstehen, können Sie besser entscheiden, wie Sie damit umgehen.
Unsignierte automatisierte Clients
Request-Signierung mit HTTP Message Signatures, definiert in RFC 9421, ist optional, und die IETF-Arbeitsgruppe Web Bot Auth standardisiert noch, wie automatisierte Clients sich auf diese Weise authentifizieren sollen. Ohne Signatur beruht die Identität eines Clients auf dem, was er über sich selbst behauptet.
Kopierte oder generische User-Agents
User-Agent-Strings sind trivial zu setzen. Ein Client, der vorgibt, ein bekannter Browser oder Crawler zu sein, kann genau das sein oder ihn lediglich imitieren. Der Eintrag User-Agent-Spoofing erklärt, warum dieses Header-Feld allein keine Klassifizierung tragen kann. Deshalb dokumentieren Suchmaschinen auch getrennte Verifikationsmethoden: Google beschreibt Reverse- und Forward-DNS-Lookups sowie veröffentlichte IP-Bereiche zum Verifizieren von Googlebot, und Bing beschreibt denselben DNS-Check zum Verifizieren von Bingbot.
Routen ohne Integration
Wenn eine Route weder eine Browser-Integration noch serverseitigen Kontext über die Grundlagen hinaus hat, gibt es schlicht weniger zu beobachten. Unknown auf solchen Routen ist ein Zeichen für Abdeckung, nicht für eine Bedrohung.
Fehlende oder verzögerte Evidenz
Ein Timeout, ein blockiertes Skript oder ein unvollständiger Request kann zu einem Ergebnis ohne ausreichende Evidenz führen. Proof of Actor gibt das ehrlich aus, statt die Lücke zu füllen.
Wie Proof of Actor Unknown handhabbar macht
Proof of Actor strukturiert seine Arbeit in drei Fähigkeiten. Jede davon hilft bei unbekanntem automatisiertem Traffic.
Detect: Unknown getrennt halten
Signale werden geprüft und nach Grundlage markiert: verified, declared, inferred oder unknown. Wenn sie keine belastbare Bestimmung tragen, lautet das Ergebnis Unknown mit einer Zusammenfassung dessen, was verfügbar war und was nicht. Nichts wird in eine andere Klasse geraten.
Understand: sehen, wo Unknown vorkommt
Die Ansicht Understand zeigt Unknown in jeder Aufschlüsselung, nach Route und über die Zeit. Sie sehen, welche Routen den meisten unbekannten Traffic haben, wie sich das nach dem Hinzufügen einer Integration verändert und welche Evidenz für einzelne Interaktionen vorhanden war. So wird aus einer vagen Sorge eine konkrete Karte.
Route: den Fallback pro Route wählen
Unterschiedliche Routen verdienen unterschiedliche Fallbacks. Ein sinnvoller Ausgangspunkt für viele Anwendungen:
- Öffentliche Seiten und Dokumentation: Unknown mit Ihren Standard-Rate-Limits zulassen.
- Signup und Onboarding: Ihre vorhandenen Prüfungen beibehalten und Review nur dann hinzufügen, wenn Ihre eigenen Bedingungen es verlangen.
- Kontenänderungen und andere sensible Aktionen: Auf Ihre vorhandene Authentifizierung und Step-up-Steuerungen setzen, niemals auf eine Schätzung des Actors.
- API-Operationen mit hoher Auswirkung: Die stärkeren Anmeldedaten oder Kontrollen verlangen, die Ihre API bereits unterstützt.
Der Leitfaden zu unbekanntem Traffic behandeln zeigt, wie Sie diese Fallbacks entwerfen, einschließlich Fail-open- und Fail-closed-Entscheidungen für jede Risikostufe.
Unknown im Laufe der Zeit verkleinern
Das Ziel ist nicht, Unknown über Nacht zu beseitigen. Es geht darum, es von Monat zu Monat kleiner zu machen, aus den richtigen Gründen.
- Integrationen dort hinzufügen, wo sie wichtig sind. Eine Browser-Integration auf Schlüsselseiten und eine serverseitige Integration auf Schlüsselpunkten erhöhen die verfügbare Evidenz.
- Signierte Requests unterstützen. Wenn Agent-Betreiber HTTP message signatures einführen, wird Traffic, der zuvor Unknown war, zu verifiziertem Agent-Traffic.
- Deklarationen in Ihrer eigenen App erfassen. Wenn Ihre Anwendung weiß, dass KI-Unterstützung beteiligt ist, sagen Sie das auch. Diese Evidenz ist präzise und günstig.
- Agenten einen vorderen Zugang anbieten. Ein strukturierter Pfad für Agenten ermutigt sie, sich zu identifizieren, statt sich unterzumischen.
Weil Proof of Actor Unknown pro Route verfolgt, sehen Sie jede dieser Änderungen in den Zahlen.
Wie es funktioniert
Jede Interaktion folgt demselben evidenzorientierten Ablauf, der auf How It Works vollständig beschrieben ist: Ihre Anwendung empfängt einen Request oder ein Event, die Integration sammelt die in diesem Kontext verfügbaren Signale, Signale werden normalisiert und mit einer expliziten Grundlage klassifiziert, das Ergebnis wird für Analysen gespeichert, und Ihre Anwendung wendet ihre eigene Policy an oder beobachtet einfach.
Timeouts und fehlende Telemetrie werden ausdrücklich behandelt. Ihre Integration verwendet den für diese Route gewählten Fallback, und das Ergebnis wird niemals zu Human hochgestuft, nur weil Evidenz fehlte.
Wie gutes Ergebnis nach einigen Monaten aussieht
Teams, die unbekannten automatisierten Traffic gut handhaben, erreichen meist denselben gesunden Zustand. Unknown ist auf jeder wichtigen Route eine bekannte Größe und wird im selben Dashboard verfolgt wie menschliche und Agent-Aktivität. Für jede Route gibt es einen schriftlichen Fallback, auf den sich Produkt-, Plattform- und Security-Teams gemeinsam geeinigt haben. Verifizierter Agent-Traffic wächst, wenn mehr Betreiber ihre Requests signieren, und diese Agenten werden über einen strukturierten Pfad bedient statt Seiten zu scrapen. Sensible Aktionen werden durch die Authentifizierung und Step-up-Steuerungen geschützt, denen die Anwendung bereits vertraut, wobei der Actor-Kontext nur ein zusätzlicher Input ist und kein Gatekeeper.
Am wichtigsten ist: Niemand rät. Wenn jemand fragt, wie viel des Traffics der letzten Woche automatisiert war, kommt die Antwort mit ihrer Grundlage: so viel verified, so viel declared, so viel inferred und so viel noch Unknown. Das ist eine Zahl, mit der ein Team planen kann. Es verändert auch das Gespräch mit der Führung, weil die Frage aufhört zu sein, ob Bots ein Problem sind, und stattdessen lautet, welche Routen mehr Evidenz verdienen und welche Fallbacks geschärft werden müssen.
Im Beobachtungsmodus starten
Proof of Actor blockiert standardmäßig nichts. Im Beobachtungsmodus werden Ergebnisse gespeichert, während Ihre Anwendung exakt wie bisher antwortet. Ihr Team sieht, wie viel unbekannter automatisierter Traffic jede Route erhält, vergleicht ihn mit bereits bekannten Ergebnissen und entwirft Fallbacks auf Grundlage realer Muster. Policies werden immer nur für eine Route nach der anderen aktiviert, und zwar erst dann, wenn Ihr Team überzeugt ist, dass sie passen.
Dem Founding Developer Program beitreten
Proof of Actor befindet sich in der privaten Beta. Ausgewählte Founding-Developer-Teams können bis zu 12 Monate kostenlosen Zugang innerhalb vereinbarter Nutzungsgrenzen erhalten, im Austausch für praxisnahes Produktfeedback und mit direkter Integrationsunterstützung durch unsere Engineers.
Wenn unbekannter automatisierter Traffic Ihre Analysen oder Ihre Security-Entscheidungen verfälscht, bewerben Sie sich für Early Access. Erzählen Sie uns von Ihrer Anwendung und den Routen, auf denen Unknown am wichtigsten ist.
Entdecken Sie Proof of Actor, lesen Sie how it works oder sehen Sie, was die Evidenz belegen kann.
Quellen
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.
- Verifying Googlebot and other Google crawlers, Google Search Central.
- How to verify that Bingbot is Bingbot, Bing Webmaster Blog.