Zum Hauptinhalt springen
APIS

Verstehen Sie, wer Ihre API aufruft.

Fügen Sie jeder API-Anfrage Actor-Kontext hinzu: welcher Client aufruft, wie stark die Evidenz ist und was Ihre API damit tun soll, Route für Route.

Frühen Zugang erhaltenFunktionsweise erkunden
example-app.test · actor result

POST /api/v1/orders

Agentbasis: inferred

Nachweise

Traffic mit API-Schlüssel ohne Browser-Kontext und mit automatisiertem Request-Muster

Ihre Richtlinie: Vor dem Erstellen der Bestellung nach dem stärkeren Berechtigungsnachweis fragen

Ein API-Schlüssel ist keine Identität, und Identität ist keine Berechtigung.

Der meiste API-Verkehr trifft mit einem Credential ein, das sagt, welches Konto bezahlt, nicht welcher Client aufruft oder wer ihn angewiesen hat. Einige Clients signieren ihre Requests, viele nennen nur einen Namen, und viele sagen gar nichts.

Proof of Actor trennt die drei Fragen, die jede API beantworten muss, damit jede die richtige Evidenz und die richtige Steuerung erhält.

drei separate Fragen
  • Wer ruft an?Actor-Identität: Signatur, Deklaration oder Inferenz
  • Welches Credential?Ihr API-Schlüssel, OAuth-Token oder Ihre Sitzung
  • Was darf es tun?Ihre Autorisierung und Richtlinie

Proof of Actor beantwortet die erste Frage. Ihr Stack behält die anderen beiden.

Was API-Teams mit Actor-Kontext tun

  • Signierte Clients erkennen

    Prüfen Sie die Signaturen von Anfragen gegen veröffentlichte Schlüssel und sehen Sie, welchem Operator eine Anfrage zugeordnet ist.

  • Deklarationen als Deklarationen behandeln

    Erfassen Sie selbst angegebene Client-Namen und halten Sie sie getrennt von verifizierter Identität.

  • Richtlinien pro Route

    Niedrig relevante Lesezugriffe frei zulassen und bei Schreibzugriffen und Endpoints mit hoher Auswirkung mehr verlangen.

  • Jeden Aufrufer sehen

    Verstehen Sie, welche Clients welche Endpoints nutzen, einschließlich der unbekannten.

  • Anmeldedaten getrennt halten

    API-Schlüssel und OAuth entscheiden weiterhin über den Zugriff. Der Akteurkontext ergänzt, wer aufruft.

  • Plan für Unknown

    Definieren Sie pro Route, was geschieht, wenn ein Aufrufer keine verwertbare Evidenz liefert.

01 · Erkennen

Evidenz aus jeder Anfrage.

Server-, Edge- und HTTP API-Integrationen lesen Anfrage-Signaturen, deklarierte Client-Details und den Anfragekontext aus und kennzeichnen jedes mit seiner Grundlage.

  • HTTP-Message-Signatures anhand veröffentlichter Schlüssel verifiziert.
  • Deklarierte Client-Namen, die als Deklarationen erfasst werden.
  • Rufen Sie Anfragekontext von Ihrem Server, Gateway oder Edge ab.
Signale · letzte Anfrage pro Quelle
  • Anfragesignaturvalid · sample-crawler.exampleverified
  • Kundenerklärung"research-assistant/2.1"declared
  • Browser-Interaktionpointer + keyboard eventsinferred
  • Keine unterstützten Signaleroute not instrumentedunknown

02 · Verstehen

Wissen, wer welchen Endpoint verwendet.

Sehen Sie die Actor-Mischung auf jeder Route, welche Operatoren Sie am häufigsten anrufen und wo sich unbekannte Anrufer konzentrieren.

  • Aufrufer nach Route und Operator.
  • Die Evidenz hinter jeder Klassifizierung.
  • Unknown-Rate pro Endpoint.
Traffic nach Route · 7 Tage
  • /dashboardUnbekannt 7%
  • /api/v1/catalogUnbekannt 15%
  • /support/ticketsUnbekannt 8%
  • /signupUnbekannt 21%
MenschMensch + KIAgentUnbekannt

03 · Weiterleiten

Kontrollen, die zur Wirkung passen.

Schreiben Sie Richtlinien auf Routenebene: strukturierte Antworten für verifizierte Agenten, Standardlimits für deklarierte Clients, stärkere Credentials für wirkungsvolle Aktionen.

  • Richtlinien nach Route, Klasse und Grundlage.
  • Bei Bedarf auf stärkere Berechtigungen umsteigen.
  • Beobachten, Vorschau anzeigen, dann durchsetzen.
policy · example-app.test
  • /api/v1/catalogenforceAgentZulassen · strukturierte API
  • /support/ticketsenforceMensch + KIZulassen · als KI-unterstützt kennzeichnen
  • /account/*previewUnbekanntBestehende Prüfungen beibehalten
  • /api/v1/orderspreviewAgentStärkeres Anmelde- oder Berechtigungsmerkmal verlangen

Beispielentscheidungen

Von der Anfrage zum Ergebnis zu Ihrer Entscheidung.

  • Ein verifizierter Agent liest Ihren Katalog

    Anfrage

    GET /api/v1/catalog

    Ergebnis

    Agentbasis: verified

    Ihre Entscheidung

    Mit dem Agenten-Rate-Limit und der strukturierten Antwort zulassen.

  • Ein automatisierter Client gibt eine Bestellung auf

    Anfrage

    POST /api/v1/orders

    Ergebnis

    Agentbasis: inferred

    Ihre Entscheidung

    Fragen Sie vor dem Erstellen der Bestellung nach dem stärkeren Berechtigungsnachweis der App.

  • Ein Client ohne Nachweise

    Anfrage

    GET /api/v1/catalog

    Ergebnis

    Unbekanntbasis: unknown

    Ihre Entscheidung

    Schreibgeschützte Route: mit dem Standard-Ratenlimit erlauben.

Ohne Risiko einführen

Teams beginnen im Beobachtungsmodus und gehen Route für Route vor.

  1. 01

    Jede Route beobachten

    Fügen Sie die Middleware oder HTTP API vor Ihre API. Signaturen, Deklarationen und Unknown-Aufrufer werden pro Route erfasst.

  2. 02

    Richtlinien pro Route in der Vorschau prüfen

    Prüfen Sie, was Agenten-Rate-Limits oder Step-up-Berechtigungen bei echtem Traffic bewirkt hätten, bevor sie angewendet werden.

  3. 03

    Nach Auswirkung durchsetzen

    Halten Sie Lesezugriffe offen, schränken Sie Schreibzugriffe ein und lassen Sie API-Schlüssel und OAuth den Zugriff steuern.

Funktioniert mit Ihrem Stack

  • Gründerteams

    Webserver-Middleware (Node.js)

    Serverseitig

    Signale auf Anfrageebene für serverseitig gerenderte Apps und APIs.

  • Gründerteams

    Next.js

    Serverseitig und am Edge

    Middleware für Seiten- und API-Routen.

  • Gründerteams

    Browser-Skript

    Nur Browser-Signale

    Interaktionssignale aus Browser-Sitzungen, zusammen mit einer serverseitigen Integration.

  • Gründerteams

    Cloudflare und Edge-Runtimes

    Edge

    Signale am Edge, bevor Anfragen Ihr Origin erreichen.

  • Gründerteams

    Generische HTTP API

    Jeder Stack

    Senden Sie Anfragekontext an eine API und erhalten Sie ein Ergebnis mit seiner Grundlage.

  • Gründerteams

    MCP-Server

    MCP

    Actor-Kontext für MCP-Tool-Aufrufe.

  • Roadmap

    WordPress

    Plugin

    Plugin für WordPress-Websites.

  • Roadmap

    Nativ mobil

    iOS und Android

    Native iOS und Android SDKs.

Integrationen werden während des Onboardings mit jedem Gründungsteam praktisch umgesetzt. Verwenden Sie einen anderen Stack? Teilen Sie es uns bei der Bewerbung mit.

Mehr erfahren

Lesen Sie Detection & Limitations

Häufig gestellte Fragen

Müssen Clients ihre Anfragen signieren?

Nein. Signierte Requests liefern den stärksten Beleg, aber Proof of Actor erfasst auch Deklarationen und Inferenzwerte, jeweils mit ihrer Grundlage gekennzeichnet, und meldet Unknown, wenn es nicht genug gibt.

Bedeutet eine gültige Signatur, dass der Client handeln darf?

Nein. Es zeigt, dass der Request mit einem Schlüssel signiert wurde, der an einen veröffentlichten Identifikator gebunden ist. Was dieser Operator tun darf, entscheidet Ihre Autorisierung und Richtlinie.

Ersetzt es API keys oder OAuth?

Nein. Credentials steuern weiterhin den Zugriff. Proof of Actor ergänzt, wer oder was aufruft, damit Sie darüber bessere Richtlinien anwenden können.

Können wir pro Endpoint unterschiedliche Regeln festlegen?

Ja. Richtlinien werden pro Route geschrieben, sodass schreibgeschützte Endpunkte und besonders wirkungsvolle Schreibvorgänge unterschiedlich behandelt werden können.

Was kostet das?

Ausgewählte Founding-Developer-Teams können innerhalb vereinbarter Nutzungslimits bis zu 12 Monate kostenlos erhalten.

Wissen, wer Ihre API aufruft.

Werden Sie Teil des Founding-Developer-Programms von Proof of Actor.

Frühen Zugang erhaltenEntwickler-Hub

Möchten Sie zuerst sprechen? Mit den Gründern sprechen