Nicht jeder automatisierte Traffic ist gleich
Automatisierte Clients erreichen Ihre Anwendung jede Minute: Such-Crawler, Monitoring-Tools, Partnerintegrationen, KI-Assistenten, die für einen Nutzer Seiten abrufen, und autonome Agenten, die Aufgaben erledigen. Jahrelang war der User-Agent-Header für die meisten Anwendungen die einzige Möglichkeit, sie voneinander zu unterscheiden, ein String, den jeder Client auf beliebige Werte setzen kann.
Das bringt Application-Teams in eine Zwickmühle. Behandeln Sie jede Automatisierung mit Misstrauen, verschlechtert sich die Erfahrung legitimer Agenten, auf die Ihre Kunden angewiesen sind. Vertrauen Sie dem Header, dann kann jeder behaupten, ein bekannter Crawler zu sein.
Verifizierte automatisierte Anfragen ändern die Ausgangslage. Wenn ein automatisierter Client seine Anfragen mit einem Schlüssel signiert, den er veröffentlicht hat, kann Ihre Anwendung die Signatur prüfen und kryptografisch feststellen, welcher Client die Anfrage signiert hat. Proof of Actor macht diese Prüfung zu einem Teil eines einheitlichen Actor-Ergebnisses, auf das Ihr Code routen kann. Einen genaueren Blick darauf, was diese Prüfung belegt und was nicht, finden Sie unter was signierte Anfragen von KI-Agenten belegen.
Wie Request Signing funktioniert
Der entstehende Ansatz für automatisierten Traffic nutzt HTTP message signatures, standardisiert in RFC 9421, der festlegt, wie Signaturen über Bestandteile einer HTTP message erstellt, codiert und verifiziert werden. Der Client signiert ausgewählte Teile jeder Anfrage mit einem privaten Schlüssel und fügt Signatur und Parameter in Headern hinzu. Den zugehörigen öffentlichen Schlüssel veröffentlicht er an einer Stelle, die an einen von ihm kontrollierten Identifikator gebunden ist, typischerweise seine Domain.
Wenn die Anfrage eintrifft, ruft der Empfänger den veröffentlichten Schlüssel ab oder sucht ihn nach, rekonstruiert den signierten Inhalt und prüft die Signatur. Ist sie gültig, wurde die Anfrage vom Inhaber dieses Schlüssels signiert. Die Arbeit am Signieren von automatisiertem Traffic geht in der IETF in der Web Bot Auth working group weiter, deren Mandat die kryptografische Authentifizierung automatisierter Clients wie Crawler und KI-Agenten umfasst, die im Auftrag von Endnutzern handeln; der Glossareintrag zu Web Bot Auth fasst dies zusammen. Der Blogbeitrag was signierte Anfragen von KI-Agenten belegen führt eine verifizierte Anfrage end-to-end durch, und der APIs use case zeigt, wo Verifizierung zuerst Nutzen bringt.
Der Leitfaden zum Verifizieren signierter Agent-Anfragen beschreibt die Mechanik im Detail, einschließlich Zeitstempeln, Replay-Fenstern und Key-Caching.
Was eine verifizierte Signatur belegt und was nicht
Diese Unterscheidung ist der wichtigste Teil beim guten Umgang mit verifizierten automatisierten Anfragen.
Eine gültige Signatur belegt, dass die Anfrage mit einem Schlüssel signiert wurde, der dem veröffentlichten Identifikator zugeordnet ist. Wenn der Schlüssel zu einer Domain eines Betreibers gehört, kam die Anfrage von einem Client, der diesen Schlüssel hält.
Eine gültige Signatur belegt nicht:
- wer den Agenten angewiesen hat oder ob eine Person diese Aktion überhaupt angefordert hat;
- dass eine Person dem Agenten Autorität übertragen hat;
- die rechtliche Identität hinter dem Betreiber in der realen Welt;
- dass die angeforderte Aktion in Ihrer Anwendung sicher oder erlaubt ist.
Das sind getrennte Fragen. Ihre Anwendung beantwortet sie mit ihren eigenen Credentials, ihrem Autorisierungsmodell und ihrer Policy. Proof of Actor hält sie bewusst auseinander, und die Seite zu Detection & Limitations erklärt genau, was jede Art von Evidenz belegen kann.
Wie Proof of Actor verifizierte automatisierte Anfragen verarbeitet
Detect
Ihre Integration übergibt den Anfragekontext, einschließlich aller Signatur-Header, an Proof of Actor. Signaturen werden gegen veröffentlichte Schlüssel geprüft. Verifizierte Anfragen werden mit einer verifizierten Grundlage erfasst. Clients, die sich nur selbst benennen, werden als deklariert erfasst. Verhaltensmuster werden als abgeleitet erfasst. Wenn die Grundlage nicht ausreicht, ist das Ergebnis Unknown. Nichts wird zu verifiziert hochgestuft, ohne dass eine kryptografische Prüfung erfolgreich war.
Understand
Sehen Sie, welche verifizierten Betreiber Ihre Anwendung aufrufen, welche Routes sie verwenden, wie oft und wie sich das im Vergleich zu deklarierter und unbekannter Automatisierung verhält. Die Evidenzzusammenfassung bei jedem Ergebnis zeigt, welcher Schlüssel und welcher Identifikator beteiligt waren, damit Ihr Team jede Anfrage schnell untersuchen kann.
Route
Verwenden Sie die Grundlage in Ihren Policies. Typische Muster sind:
- Verifizierten Agents auf schreibgeschützten Routes eine strukturierte Antwort geben, etwa über eine API oder eine Markdown-Version einer Seite.
- Die Rate Limits für verifizierte Betreiber, die Sie kennen, anheben, während Sie für deklarierte Clients die Standardlimits beibehalten.
- Ihre bestehende Autorisierung auf jeder Write Route beibehalten, unabhängig davon, was die Signatur sagt.
- Eine explizite Fallback-Regel für nicht signierte und Unknown-Aufrufer auf jeder Route definieren.
Ihre Policies entscheiden; Proof of Actor liefert die Evidenz.
Warum der User-Agent-Header nicht ausreicht
User-Agent-Strings sind Deklarationen. Jeder Client kann jeden Wert senden, und User-Agent-Spoofing erfordert keine besonderen Fähigkeiten. Deshalb veröffentlichen Crawler-Betreiber ihre eigenen Prüfungen: Google dokumentiert Reverse- und Forward-DNS-Lookups sowie veröffentlichte IP-Bereiche für Verifying Googlebot, Bing dokumentiert eine DNS-Prüfung für Verifying Bingbot, und OpenAI veröffentlicht IP-Range-Dateien für jeden seiner crawlers and user agents. Proof of Actor behandelt eine User-Agent-Angabe als deklarierte Evidenz, niemals als Verifizierung. Das bedeutet, dass ein Client, der sich als bekannter Crawler ausgibt, ohne gültige Signatur mit einer deklarierten oder abgeleiteten Grundlage gemeldet wird, und Ihre Policy kann ihn anders behandeln als einen Client, der seine Identität belegt hat.
Genau das macht verifizierte automatisierte Anfragen wertvoll: Sie geben Ihnen eine verlässliche Möglichkeit, Vertrauen auf die Clients auszuweiten, die es verdienen, ohne es auf alle auszudehnen, die einfach ihren Header kopieren.
Identitätsevidenz, Credentials und Autorisierung
In jeder Anwendung, die automatisierte Clients bedient, arbeiten drei Ebenen zusammen:
- Identitätsevidenz: Welcher Client hat diese Anfrage signiert? Eine verifizierte Signatur beantwortet das.
- Credentials: Welches Konto ist verantwortlich? Ihr API-Schlüssel, Token oder Ihre Session beantwortet das.
- Autorisierung: Darf dieser Aufrufer das? Ihr Berechtigungsmodell beantwortet das.
Proof of Actor stärkt die erste Ebene und macht sie sichtbar. Es stellt keine Identitäts- oder Delegations-Credentials aus und ersetzt Ihre Autorisierung nicht. Die Ebenen getrennt zu halten, ermöglicht es Ihnen, bei verifizierten Agents auf risikoarmen Routes großzügig und bei hochwirksamen Vorgängen vorsichtig zu sein.
Wo es passt
Proof of Actor sitzt neben Ihrem Gateway, Ihrer Authentifizierung und Ihrem Rate Limiting. Integrationen laufen als serverseitige Middleware, am Edge, in Ihrem MCP server oder über eine generische HTTP-Integration, begleitet von direkter Unterstützung für jedes Gründungsteam. Wenn Ihr Traffic hauptsächlich aus APIs und Tools besteht, zeigen die Use Cases APIs und MCP Servers die wichtigsten Muster.
Im Beobachtungsmodus starten
Jede Integration startet im Beobachtungsmodus. Ergebnisse werden erfasst, ohne zu ändern, wie Ihre Anwendung reagiert, damit Sie sehen können, wie viel Ihres automatisierten Traffics verifiziert ist, welche Betreiber signieren und wo die Unknown-Rate am höchsten ist. Policies kommen später, Route für Route, wenn die Evidenz sie trägt. How It Works führt durch den vollständigen Ablauf.
Praktische Details, die Verifizierung zuverlässig machen
Die Prüfung von Signaturen ist nur so gut wie die Details darum herum. Einige Praktiken machen verifizierte automatisierte Anfragen in der Produktion verlässlich.
Aktualität prüfen
RFC 9421 definiert created und expires Signaturparameter, und signierte Anfragen tragen sie in der Regel. Verwerfen Sie Signaturen außerhalb eines kurzen Fensters, damit eine abgefangene Anfrage später nicht erneut abgespielt werden kann.
Schlüssel sinnvoll cachen
Das Abrufen der veröffentlichten Schlüssel eines Betreibers bei jeder Anfrage erhöht die Latenz. Cachen Sie sie für einen angemessenen Zeitraum und aktualisieren Sie sie, wenn eine Signatur mit einer unbekannten Schlüssel-ID fehlschlägt, damit eine Schlüsselrotation nicht zu falschen Fehlern führt.
Die richtigen Teile der Anfrage signieren
Eine Signatur, die nur einen Zeitstempel abdeckt, belegt sehr wenig. Prüfen Sie, dass die signierten Bestandteile die Methode, den Pfad und den Host einschließen, damit die Signatur an die Anfrage gebunden ist, die Ihre Anwendung tatsächlich erhalten hat.
Die Evidenz erfassen
Bewahren Sie bei jeder verifizierten Anfrage die Schlüssel-ID, den veröffentlichten Identifikator und das Ergebnis auf. Wenn etwas Ungewöhnliches passiert, kann Ihr Team genau sehen, welcher Client was und wann signiert hat.
Proof of Actor übernimmt diese Prüfungen im Detect-Schritt und meldet das Ergebnis als Grundlage, die Ihre Policies lesen können, sodass Ihr Anwendungscode einfach bleibt.
Dem Founding Developer Program beitreten
Proof of Actor befindet sich in der Private Beta. Ausgewählte Founding Development Teams können bis zu 12 Monate kostenlosen Zugang erhalten, innerhalb vereinbarter Nutzungslimits und mit direkter Integrationsunterstützung durch unsere Ingenieure.
Wenn automatisierte Clients Ihre Anwendung erreichen und Sie die verifizierten anders behandeln möchten, bewerben Sie sich für Early Access. Erzählen Sie uns von Ihrer Anwendung und den automatisierten Aufrufern, die Sie sehen, und wir zeigen Ihnen, wie Proof of Actor passt.
Quellen
- RFC 9421: HTTP Message Signatures, IETF, Februar 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.
- Overview of OpenAI crawlers, OpenAI.