Für den größten Teil der Webgeschichte hatte automatisierter Traffic einen Job im Security-Stack: identifiziert werden und gestoppt werden. Bot Management ist aus genau dieser Aufgabe entstanden. Es sitzt am Rand Ihrer Infrastruktur, bewertet Requests und blockiert oder challengt diejenigen, die missbräuchlich wirken. Dafür ist es sehr gut, und Sie sollten es behalten.
KI-Agenten haben verändert, was Anwendungen wissen müssen. Ein wachsender Anteil automatisierter Requests stammt heute von Agenten, die für echte Kunden handeln: ein Assistent, der Pläne vergleicht, ein Agent, der ein Support-Ticket erstellt, ein Client, der Ihren MCP server aufruft, um eine Aufgabe abzuschließen. Gleichzeitig nutzen viele Menschen Ihr Produkt mit einem KI-Assistenten an ihrer Seite. Das sind keine Angriffe. Das sind Nutzer, und sie verdienen die richtige Experience statt einer Sperrseite.
Genau diese Lücke füllt Proof of Actor. Diese Seite vergleicht die beiden Kategorien nüchtern, damit Sie sehen, wo jede hingehört.
Die Kurzfassung
| Bot Management | Proof of Actor | |
|---|---|---|
| Zentrale Frage | Soll diese Anfrage gestoppt werden? | Wer oder was handelt, und was ist die Evidenz? |
| Wo es läuft | Am Rand, vor Ihrer Anwendung | In Ihrer Anwendung, API oder MCP server |
| Typische Ausgabe | Allow, block oder challenge; oft ein Score | Human, Human + AI, Agent oder Unknown, plus eine Grundlage |
| Behandelt KI-gestützte Menschen als | Meist nicht von anderen Menschen unterscheidbar | Eine eigene Klasse, Human + AI |
| Behandelt unklare Traffic als | Oft challenged oder blockiert | Unknown, mit einem Fallback, den Sie pro Route wählen |
| Wer die Antwort bestimmt | Das Edge-Regelwerk | Ihr Anwendungscode |
| Standardverhalten nach der Installation | Enforcement | Observation; nichts ändert sich, bis Sie eine Policy hinzufügen |
| Am besten geeignet für | Das Stoppen von Credential Stuffing, Scraping-Missbrauch und volumetrischen Angriffen | Produkt-, Analyse- und Policy-Entscheidungen für jeden Actor |
Der Rest dieser Seite erklärt jede Zeile.
Zwei unterschiedliche Fragen
Bot Management beantwortet eine Frage der Protection. Ziel ist es, missbräuchliche Automatisierung von Ihrer Infrastruktur, Ihren Accounts und Ihrem Bestand fernzuhalten. Jedes Signal, das es sammelt, dient diesem Ziel, und seine Ausgabe ist eine Entscheidung: die Anfrage durchlassen, blockieren oder ein Challenge davor schalten.
Proof of Actor beantwortet eine Frage des Verstehens. Ziel ist es, Ihrer Anwendung zu sagen, wer oder was jede Interaktion antreibt, damit Sie entscheiden können, wie Sie sie bedienen. Die Ausgabe ist kein Urteil über die Anfrage. Es ist eine Klassifizierung mit ihrer Evidenz:
- Human: die beobachtbaren Signale deuten auf eine von Menschen gesteuerte Interaktion hin.
- Human + AI: eine Person hat die Interaktion mit deklarierter oder beobachteter KI-Unterstützung gesteuert.
- Agent: automatisierte oder agentenbasierte Interaktion, gestützt durch verifizierbare Identität oder eine qualifizierte Inferenz.
- Unknown: die Evidenz reicht nicht für eine verlässliche Bestimmung aus.
Jedes Ergebnis nennt außerdem seine Evidenzgrundlage: Verified, Declared, Inferred oder Unknown. Das sind die Informationen, die eine Produktentscheidung braucht, und genau diese Informationen ist ein Protection-Score nicht dafür gedacht zu tragen.
Wo jedes der beiden läuft
Bot Management läuft normalerweise am Netzwerk-Edge oder in einem Reverse Proxy vor allem anderen. Diese Position ist für Protection genau richtig. Sie sieht Traffic früh, fängt Angriffe ab, bevor sie Sie etwas kosten, und hält Ihre Origin-Server sauber.
Proof of Actor läuft dort, wo Ihre Anwendungslogik lebt: Server-Middleware, Next.js, die von Ihnen kontrollierte Edge-Schicht, eine freigegebene Browser-Integration, eine generische HTTP API oder Ihr MCP server. Diese Position gibt ihm Zugriff auf das, was Ihre Anwendung weiß: welche Route aufgerufen wird, zu welchem Workflow sie gehört, ob Ihr eigener Assistent eine Aktion ausgeführt hat und ob sich ein Client selbst deklariert hat. Die Integrationspfade zeigen die vollständige Liste.
Weil beide an unterschiedlichen Stellen laufen, konkurrieren sie nicht um dieselbe Aufgabe. Eine Anfrage kann Ihr Bot Management passieren, Ihre Anwendung erreichen und dann Actor-Kontext erhalten, der die Antwort prägt.
Scores versus Evidenz
Viele Schutzprodukte drücken ihr Urteil als Score aus. Ein Score ist effizient für eine Blockierungsentscheidung: Schwellenwert wählen, oberhalb davon handeln. Er ist deutlich weniger nützlich, wenn die Frage lautet: "Welches Erlebnis sollte dieser Actor bekommen?"
Ein Score sagt Ihnen nicht, ob eine risikoarme Anfrage von einer Person, einer Person mit einem Assistenten oder einem gutartigen Agenten kam. Er sagt Ihnen nicht, welche Teile der Schlussfolgerung verifiziert und welche inferiert wurden. Und er kann "wir wissen es nicht" nicht ausdrücken, ohne es in eine Zahl zu pressen.
Proof of Actor erhält diese Unterscheidungen. Ein Verified-Agentenresultat bedeutet, dass eine Request-Signatur gegen einen veröffentlichten Key geprüft wurde, zum Beispiel über HTTP Message Signatures. Ein Declared-Resultat bedeutet, dass ein Client oder Ihre eigene Anwendung es angegeben hat. Ein Inferred-Resultat ist als Inferenz gekennzeichnet. Und Unknown ist eine eigenständige Antwort statt eines versteckten Defaults. Ihr Team kann jedes Ergebnis lesen und genau sehen, worauf es beruht.
KI-gestützte Menschen sind keine Bots
Die am schnellsten wachsende Gruppe in den meisten Anwendungen sind Menschen, die mit KI arbeiten. Sie verfassen Nachrichten mit einem Assistenten, füllen Formulare mit Hilfe aus und bewegen sich mit einem KI-Tool an ihrer Seite durch Ihr Produkt. Protection-Tools wurden nicht dafür gebaut, sie von anderen Menschen zu trennen, und sie müssen es auch nicht.
Ihr Produkt braucht das oft schon. Vielleicht möchten Sie KI-Entwürfe für Support-Tickets kennzeichnen, damit das richtige Team sie bearbeitet, messen, wie sich KI-gestützte Nutzer durch das Onboarding bewegen, oder ihnen einen reibungsloseren Weg anbieten. Proof of Actor gibt dieser Gruppe eine eigene Klasse, Human + AI, und meldet sie nur, wenn die Unterstützung deklariert oder über eine unterstützte Integration beobachtbar ist. Mehr dazu im Glossareintrag AI-assisted interaction.
Unknown ist eine Antwort, keine Bedrohung
Jeder Klassifikator stößt auf Traffic, den er nicht erklären kann. Schutzsysteme sind darauf ausgelegt, vorsichtig zu sein, deshalb wird unklarer Traffic oft mit einem Challenge beantwortet. Am Edge ist das eine vernünftige Wahl.
Innerhalb Ihrer Anwendung ist ein einzelner vorsichtiger Default oft die falsche Entscheidung. Eine unbekannte Anfrage an eine öffentliche Dokumentationsseite und eine unbekannte Anfrage zum Ändern eines Account-Passworts verdienen sehr unterschiedliche Behandlungen. Proof of Actor gibt Unknown als eigenes Ergebnis zurück und lässt Sie den Fallback pro Route festlegen: auf öffentlichen Seiten zulassen, Ihre bestehenden Prüfungen bei Account-Änderungen beibehalten, bei besonders wichtigen Aktionen zur Prüfung weiterleiten. Der Leitfaden zu handling Unknown traffic zeigt die Muster.
Wer die Antwort entscheidet
Bei Bot Management entscheidet das Regelwerk am Edge. Das ist effizient und hält Entscheidungen über Ihre Properties hinweg konsistent.
Bei Proof of Actor entscheidet Ihre Anwendung. Das Produkt liefert den Actor-Kontext, Ihr Code wendet die Policy an. Sie können verifizierten Agenten eine strukturierte API statt Seiten für Menschen ausliefern, das Standarderlebnis für menschliche Sessions beibehalten, KI-gestützte Einreichungen kennzeichnen und bei sensiblen Aktionen stärkere Credentials verlangen, wenn Ihre eigenen Bedingungen das nahelegen. Policies werden pro Route, pro Actor-Klasse und pro Grundlage geschrieben und leben neben dem restlichen Geschäftscode.
Erst beobachten
Bot Management wird normalerweise mit dem Ziel installiert, Enforcement durchzusetzen, weil sein gesamter Wert darin liegt, Missbrauch zu stoppen.
Proof of Actor startet im Observation-Modus. Die Installation ändert nichts daran, wie sich Ihre Anwendung verhält. Sie sehen Ihren echten Actor-Mix pro Route, prüfen die Evidenz, sehen sich die Wirkung einer Policy auf echten Traffic vorab an und setzen Enforcement erst dann durch, wenn Sie bereit sind, Route für Route. Der Leitfaden zu rolling out actor-aware policies safely beschreibt den Ablauf.
Wie beide zusammenarbeiten
Die stärkste Konfiguration nutzt beide, jeweils auf ihrer eigenen Ebene:
- Am Edge stoppt Bot Management Credential Stuffing, Scraping-Missbrauch und volumetrische Angriffe.
- In Ihrer Anwendung klassifiziert Proof of Actor den Traffic, der durchkommt, als Human, Human + AI, Agent oder Unknown, mit seiner Grundlage.
- In Ihrem Code nutzen Policies diesen Kontext, um das Erlebnis zu wählen: die strukturierte API für einen verifizierten Agenten, der normale Ablauf für eine Person, ein Label für eine KI-gestützte Einreichung, ein expliziter Fallback für Unknown.
- In Ihrer Analyse sieht Ihr Team, welche Routen und Workflows jede Actor-Klasse nutzt, sodass Produkt und Security mit demselben Bild arbeiten.
Wenn Sie die Edge-Entscheidung neben dem Actor-Ergebnis speichern, wird das Bild vollständig: was der Schutz getan hat und wer tatsächlich gehandelt hat.
Wann Sie welches wählen sollten
Wählen Sie Bot Management, wenn Ihr Hauptproblem Missbrauch ist: Versuche zur Account-Übernahme, Horten von Inventar, aggressives Scraping oder Traffic-Fluten.
Wählen Sie Proof of Actor, wenn Ihre Hauptfrage Ihre Nutzer betrifft: wie stark Agenten bereits Ihr Produkt nutzen, welche Agenten Ihre API oder Ihren MCP server aufrufen, wo KI-gestützte Menschen auf Schwierigkeiten stoßen und welche Routen eine Actor-aware Policy brauchen.
Die meisten Teams, die eine Produktionsanwendung, eine API oder einen MCP server betreiben, brauchen Antworten auf beides. Deshalb gehören die beiden in denselben Stack.
Loslegen
Proof of Actor befindet sich in privater Beta. Ausgewählte Founding Developer Teams können innerhalb vereinbarter Nutzungslimits bis zu 12 Monate kostenlosen Zugang erhalten, mit direkter Unterstützung durch das Team, das es entwickelt. Bewerben Sie sich für Early Access und erzählen Sie uns von der Anwendung und der Interaktion, die Sie verstehen möchten.