APIs hatten früher ein einfaches Traffic-Modell. Ein Entwickler registrierte sich, erhielt einen Schlüssel, schrieb eine Integration und diese Integration rief Ihre Endpunkte nach einem Zeitplan oder wenn ein Nutzer etwas anklickte auf. Bot-Management für APIs ist aus diesem Modell entstanden: Schlüssel authentifizieren, Volumen begrenzen, offensichtlich missbräuchlichen Traffic filtern und den Dienst für alle anderen verfügbar halten.
Dieses Modell gilt weiterhin, und die dafür gebauten Werkzeuge sind nach wie vor wichtig. Geändert hat sich, wer hinter den Aufrufen sitzt. Derselbe API-Schlüssel kann heute Anfragen von einer Person tragen, die die App Ihres Kunden nutzt, von einer Person, die einen AI-Assistenten mit der Arbeit beauftragt hat, und von einem autonomen Agenten, der nachts eine mehrstufige Aufgabe ausführt. Ihre bestehenden Kontrollen sehen einen Schlüssel und eine Anfragerate. Ihre Produkt-, Support- und Policy-Entscheidungen brauchen oft mehr.
Proof of Actor schließt diese Lücke. Es sagt Ihrer API, wer oder was bei jeder Anfrage handelt, nennt die Evidenz und überlässt die Entscheidung dann Ihrem Code. Diese Seite vergleicht es mit den wichtigsten Ebenen des API-Bot-Schutzes, damit Sie sehen, wo jede hingehört.
Die Kurzfassung
| API-Bot-Schutz | Proof of Actor | |
|---|---|---|
| Hauptfrage | Ist diese Anfrage erlaubt, authentifiziert und innerhalb der Grenzen? | Wer oder was handelt, und was ist die Evidenz? |
| Typische Ebenen | API-Gateway, WAF-Bot-Regeln, API-Schlüssel, Rate Limits | Actor-Klassifizierung innerhalb Ihrer API oder Ihres MCP server |
| Identifiziert | Das Konto oder die Integration, der der Schlüssel gehört | Den Actor hinter jeder Anfrage: Human, Human + AI, Agent oder Unknown |
| Ausgabe | Allow, reject, throttle; manchmal ein Bot-Score | Eine Klasse plus eine Basis: verified, declared, inferred oder unknown |
| Unklarer Traffic | Meist erlaubt, wenn der Schlüssel gültig ist, oder durch eine Regel abgewiesen | Unknown, mit einem Fallback, den Sie pro Route wählen |
| Wer entscheidet über die Antwort | Gateway- und WAF-Konfiguration | Ihr Anwendungscode |
| Standard bei der Installation | Durchsetzung | Observation; nichts ändert sich, bis Sie eine Policy hinzufügen |
| Am besten für | Verfügbarkeit, Missbrauchsfilterung, Kontingente, Nachvollziehbarkeit | Jeden Actor korrekt bedienen und die API-Nutzung verstehen |
Die Abschnitte unten erklären die einzelnen Teile.
Was API-Bot-Schutz gut macht
Es lohnt sich, die Aufgabe jeder Ebene präzise zu benennen, denn Proof of Actor ist dafür gedacht, neben all diesen Ebenen zu sitzen, nicht eine davon zu ersetzen.
API-Gateways
Ein Gateway ist die Eingangstür für Ihre API. Es terminiert Verbindungen, authentifiziert API-Schlüssel oder Tokens, routet Anfragen an den richtigen Service, setzt Kontingente durch und protokolliert die Nutzung oft für Billing und Analytics. Es beantwortet schnell und konsistent über jeden Endpoint hinweg die Frage: "Ist dieser Aufrufer zugelassen, und durch welche Tür?"
WAF-Bot-Regeln
Eine Web Application Firewall mit Bot-Regeln prüft Traffic auf bekannte Angriffsmuster und missbräuchliche Automatisierung. Sie kann Injection-Versuche filtern, Traffic aus Quellen mit Missbrauchshistorie blockieren und Anfragen challengen oder verwerfen, die wie Scraping- oder Credential-Angriffe aussehen. Sie ist Ihre beste Verteidigung gegen Traffic, der Ihren Code nie erreichen sollte.
API-Schlüssel und Tokens
Schlüssel und Tokens geben Ihnen Nachvollziehbarkeit. Jede Anfrage ist einem Konto zugeordnet, sodass Sie wissen, welche Integration einen Aufruf gemacht hat, Sie Zugriff widerrufen können und Nutzung zuordnen können. Gescopte Tokens gehen noch weiter und begrenzen, was ein Aufrufer tun darf.
Rate Limits
Rate Limits schützen die Verfügbarkeit. Sie verhindern, dass eine Integration Kapazität verbraucht, die für alle gedacht ist, und sie bremsen Brute-Force- und Enumeration-Versuche. Limits pro Schlüssel und pro Route sind eine gängige, wirksame Kontrolle.
Zusammen beantworten diese Ebenen die Fragen nach Schutz und Nachvollziehbarkeit sehr gut. Behalten Sie sie.
Die Frage, für die sie nicht gebaut wurden
Keine dieser Ebenen ist dafür ausgelegt, Ihnen zu sagen, welche Art von Actor hinter einer authentifizierten Anfrage sitzt. Ein gültiger Schlüssel sagt, welchem Konto die Integration gehört. Er sagt nicht:
- ob dieser konkrete Aufruf von einer Person kam, die in der App Ihres Kunden auf einen Button klickt,
- ob eine Person einen AI-Assistenten gebeten hat, die Aktion auszuführen,
- ob ein autonomer Agent den Aufruf als einen Schritt in einer längeren Aufgabe gemacht hat,
- oder ob niemand das sicher sagen kann.
Dieser Unterschied wird von Monat zu Monat wichtiger. Eine API, die eine CRM-Integration, ein Planungstool oder eine Entwicklerplattform bedient, erhält zunehmend Agent-Traffic über dieselben Schlüssel, die auch menschengetriebene Apps bedienen. Wenn Sie Agenten eine strukturierte Antwort geben, für hochwirksame Writes, die von Agenten ausgelöst werden, eine Bestätigung verlangen, AI-unterstützte Einsendungen kennzeichnen oder einfach messen wollen, wie viel Ihrer API-Nutzung agentengesteuert ist, brauchen Sie Actor-Kontext.
Was Proof of Actor einer API hinzufügt
Proof of Actor gibt für jede Interaktion eine von vier Klassen zurück:
- Human: die beobachtbaren Signale deuten auf menschlich gesteuerte Interaktion hin.
- Human + AI: eine Person hat die Interaktion mit AI-Unterstützung gesteuert, die über eine unterstützte Integration deklariert oder beobachtet wurde.
- Agent: automatisierte oder agentenursprüngliche Interaktion.
- Unknown: die Evidenz erlaubt keine verlässliche Bestimmung.
Jedes Ergebnis nennt außerdem seine Evidenzbasis:
- Verified: zum Beispiel eine HTTP Message Signature (RFC 9421), die gegen einen veröffentlichten Schlüssel geprüft wurde.
- Declared: der Client oder Ihre eigene Anwendung hat sie angegeben.
- Inferred: Verhaltens- oder Kontextsignale, klar als Inferenz gekennzeichnet.
- Unknown: keine verlässliche Basis.
Für APIs ist die verifizierte Basis besonders nützlich. Agenten, die ihre Anfragen signieren, können gegen ihre veröffentlichten Schlüssel geprüft werden, was der Ansatz hinter der IETF-Arbeit zu Web Bot Auth ist. Lesen Sie die Erläuterung zu Web Bot Auth für Produktteams für den Hintergrund und den Leitfaden zu signierte Agent-Anfragen verifizieren für die Implementierung.
Eine Einschränkung ist hier wichtig. Eine gültige Signatur beweist, welcher Schlüssel die Anfrage signiert hat. Sie beweist nicht, dass der Agent autorisiert ist, die Aktion auszuführen. Die Autorisierung bleibt dort, wo sie hingehört, in der eigenen Zugriffskontrolle Ihrer API. Der Eintrag zu Agent-Autorisierung erklärt den Unterschied.
Scores und Schlüssel versus Actor-Evidenz
Einige Bot-Schutzprodukte hängen an jede Anfrage einen Score. Ein Score ist effizient für eine Blockierentscheidung. Für Produktentscheidungen bei APIs ist er weniger nützlich, weil er nicht sagt, ob eine legitime Anfrage von einem Menschen oder einem Agenten ausgelöst wurde, und weil er verlässliche Fakten nicht von Inferenz trennt.
API-Schlüssel haben die gegenteilige Einschränkung. Sie sind präzise bei der Zuordnung und schweigen zum Actor. Ein Schlüssel eines Kunden kann innerhalb einer einzigen Stunde alle vier Klassen tragen.
Proof of Actor hält beide Unterscheidungen sichtbar. Ihre API sieht das Konto aus dem Schlüssel, die Actor-Klasse aus Proof of Actor und die Basis, die sie stützt. Jede Ebene beantwortet die Frage, für die sie gut ist.
Wo jede Ebene läuft
Gateways und WAFs laufen am Rand Ihres Netzwerks oder vor Ihren Diensten. Diese Position ist richtig für Schutz und Kontingente.
Proof of Actor läuft dort, wo Ihre API-Logik lebt. Founding-Teams können über Node.js-Middleware, Next.js, eine von Ihnen kontrollierte Edge-Ebene, die generische HTTP API oder eine MCP server-Integration integrieren. Die vollständige Liste finden Sie unter Integrationen. Weil es innerhalb Ihrer Anwendung läuft, kann es verwenden, was Ihre API weiß: die Route, den Workflow, ob ein Client sich deklariert hat und ob eine Signatur verifiziert wurde.
Routing-Entscheidungen bleiben in Ihrem Code
Proof of Actor blockiert standardmäßig nichts. Es startet im Observationsmodus, sodass sich bei der Installation nichts daran ändert, wie Ihre API antwortet. Sie sehen Ihre Actor-Mischung pro Endpunkt, prüfen Evidenz für einzelne Ergebnisse und beobachten Ihre Unknown-Rate.
Wenn Sie bereit sind, schreiben Sie anwendungsdefinierte Policies pro Route, pro Actor-Klasse und pro Basis. Typische Ergebnisse sind:
- Allow: die Anfrage normal bedienen.
- Adapt: für einen verifizierten Agenten eine strukturierte oder reduzierte Antwort zurückgeben.
- Challenge: einen zusätzlichen Bestätigungsschritt verlangen, zum Beispiel eine menschliche Freigabe bei einem hochwirksamen Write.
- Review: die Aktion zur Prüfung durch eine Person in eine Warteschlange stellen.
- Rate-limit: ein strengeres Limit für eine bestimmte Klasse und Basis auf einer bestimmten Route anwenden.
Sie können eine Policy gegen echten Traffic vor dem Enforce-Modus in der Vorschau prüfen und dann Route für Route durchsetzen. Der Leitfaden zu sichere Einführung von Actor-bewussten Policies beschreibt den Ablauf, und sensitive Aktionen schützen, ohne Agenten zu blockieren zeigt gängige Muster.
Unknown API-Aufrufer behandeln
Jede API erhält Traffic, der nicht mit Sicherheit klassifiziert werden kann. Bei traditionellen Kontrollen bedeutet ein gültiger Schlüssel meist, dass die Anfrage durchgeht, und ein ungültiger, dass sie nicht durchgeht. Dazwischen gibt es nichts.
Proof of Actor gibt Ihnen ein explizites Unknown-Ergebnis und lässt Sie den Fallback pro Route wählen. Read-only-Katalogendpunkte können offen bleiben. Kontoänderungen können Ihre bestehenden strengeren Prüfungen behalten. Massenexports können in die Review gehen. Siehe Unknown-Traffic behandeln und unbekannten automatisierten Traffic für die Details.
Wie sie sich ergänzen
Das stärkste API-Setup nutzt jede Ebene für ihre eigene Aufgabe:
- Am Rand filtert die WAF missbräuchlichen und fehlerhaften Traffic.
- Am Gateway werden Schlüssel authentifiziert, Kontingente durchgesetzt und Nutzung protokolliert.
- Innerhalb der API klassifiziert Proof of Actor jede Anfrage, die durchkommt, und nennt ihre Basis.
- In Ihren Handlern nutzen Policies die Klasse und Basis, um die Antwort zu wählen: normale Verarbeitung für einen menschengetriebenen Aufruf, eine strukturierte Antwort für einen verifizierten Agenten, einen Bestätigungsschritt für einen agentengesteuerten hochwirksamen Write, einen Fallback für Unknown.
- In Analytics sieht Ihr Team, welche Endpunkte und Workflows jede Actor-Klasse nutzt, zusammen mit den Kontodaten aus dem Gateway.
Nichts in diesem Stack wird doppelt gemacht. Das Gateway kennt das Konto, die WAF kennt die Angriffsmuster, und Proof of Actor kennt den Actor.
Wann Sie worauf den Fokus legen sollten
Legen Sie den Fokus zuerst auf API-Bot-Schutz, wenn Ihre Hauptprobleme Missbrauch, Verfügbarkeit oder ungemessene Nutzung sind: Credential-Angriffe auf Auth-Endpunkte, aggressives Scraping oder eine Integration, die andere ausbremst.
Legen Sie den Fokus auf Proof of Actor, wenn Ihre Hauptfragen Ihre Aufrufer betreffen: wie viel Ihres API-Traffics agentengesteuert ist, welche Agenten welche Endpunkte aufrufen, wo sich menschlich gesteuerte und agentengesteuerte Nutzung unterscheiden und welche Routen eine actor-bewusste Policy brauchen. Der Anwendungsfall APIs und AI-Agent-Identifikation für APIs gehen tiefer darauf ein.
Die meisten Teams, die eine Produktions-API betreiben, brauchen Antworten auf beides.
Erste Schritte
Proof of Actor befindet sich in der privaten Beta. Ausgewählte Founding-Developer-Teams können innerhalb vereinbarter Nutzungslimits bis zu 12 Monate kostenlosen Zugang erhalten, ohne automatische Abrechnung. Für Early Access bewerben und erzählen Sie uns von der API und den Aufrufern, die Sie verstehen möchten.