Zum Hauptinhalt springen
SO FUNKTIONIERT ES

So funktioniert Proof of Actor.

Ein evidenzorientierter Weg von der eingehenden Interaktion zur Anwendungsentscheidung.

Für Early Access bewerbenErkennung und Grenzen ansehen
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

Von der Interaktion zur Entscheidung

  1. 01Anwendungsanfrage oder EreignisEin Seitenaufruf, ein API-Aufruf, ein MCP-Tool-Aufruf oder eine Aktion in der App.
  2. 02Signale aus der unterstützten IntegrationNur das, was diese Integration in diesem Kontext beobachten kann.
  3. 03Normalisierung und Klassifizierung von EvidenzSignale werden geprüft, nach Grundlage gekennzeichnet und zusammengeführt.
  4. 04Actor-Ergebnis mit Grundlage und UnsicherheitHuman, Human + AI, Agent oder Unknown, plus worauf es beruht.
  5. 05Dashboard und AnalysenTrends, Routen und Nachweise zur Prüfung durch Ihr Team.
  6. 06Die eigene Entscheidung Ihrer AnwendungNur beobachten oder eine von Ihnen gewählte Richtlinie anwenden.
FÜR ENTWICKLER

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent oder Unknown.
basis
Wie stark die Evidenz ist: verified, declared, inferred oder unknown.
evidence
Die Signale hinter dem Ergebnis, damit Ihr Team den Grund sehen kann.

Starten Sie im Beobachtungsmodus: Erfassen Sie Ergebnisse neben Ihren Logs und ändern Sie nichts, bis Sie eine Richtlinie wählen. Lesen Sie die Node.js-Integrationsanleitung

Beobachtungsmodus ist der Standard

Die Installation von Proof of Actor blockiert oder verändert keine Anfrage. Die Ergebnisse werden aufgezeichnet, damit Ihr Team sie mit den tatsächlichen Ergebnissen der Anwendung vergleichen, False Positives prüfen und entscheiden kann, ob eine Policy angemessen ist.

Arten von Belegen

Die verfügbaren Belege hängen von der Integration und dem Kontext ab. Die Prüfungen für jeden Workflow werden beim Onboarding mit dem Team vereinbart, und die Signal-Interna bleiben privat, damit sie schwerer zu imitieren sind.

  • Anfragesignaturen

    Kryptografische Signaturen von automatisierten Clients, die ihre Schlüssel veröffentlichen.

  • Deklarationen

    Ein Client, der sich selbst als Agent bezeichnet, oder ein Hinweis auf KI-Unterstützung in Ihrer App.

  • Interaktionssignale

    Signale von einem freigegebenen Browser-Collector, auf den Seiten, auf denen er läuft.

  • Anfragekontext

    Header und Protokolldetails, die einer serverseitigen Integration zur Verfügung stehen.

Agentenidentität ist keine Autorisierung

Eine signierte Anfrage von einem automatisierten Client kann zeigen, dass die Anfrage mit einem Schlüssel signiert wurde, der mit einem veröffentlichten Bezeichner verknüpft ist, etwa der Domain eines Betreibers. Das ist ein nützlicher Nachweis dafür, welcher Client sie gesendet hat.

Es zeigt nicht, wer den Agent angewiesen hat, ob eine Person ihm Berechtigung übertragen hat, welche rechtliche Identität dahintersteht oder ob die Aktion sicher ist. Das sind separate Fragen, die Ihre Anwendung mit eigener Authentifizierung, Autorisierung und Richtlinie beantwortet.

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

Wie Routing-Entscheidungen hineinpassen

Ihre Anwendung ruft Proof of Actor auf, erhält ein Ergebnis und wendet ihre eigenen Regeln an. Sie wählen pro Route und pro Risikostufe, ob die Integration fails open (die Anfrage wird so fortgesetzt, als gäbe es Proof of Actor nicht) oder fails closed (Ihre bestehende stärkere Prüfung greift).

  • API-Zeitüberschreitung

    Wenn ein Ergebnis nicht rechtzeitig verfügbar ist, verwendet Ihre Integration den Fallback, den Sie für diese Route gewählt haben. Ein Timeout wird niemals zu einem Human-Ergebnis.

  • Fehlende Telemetrie

    Wenn der Browser-Collector nicht ausgeführt wurde oder ein Signal fehlt, spiegelt das Ergebnis dies wider. Fehlende Nachweise schränken ein, was gesagt werden kann; sie werden nicht als verdächtig behandelt.

  • Unknown-Klassifizierungen

    Unknown ist ein normales Ergebnis. Ihre Richtlinie definiert, was Unknown für jede Route bedeutet, zum Beispiel: öffentliche Seiten erlauben, bestehende Prüfungen bei Kontoänderungen beibehalten.

  • Veraltete Evidenz

    Evidenz hat einen Zeitpunkt und einen Geltungsbereich. Ein Ergebnis aus einem früheren Punkt einer Sitzung sollte nicht ohne eine neue Prüfung für eine spätere, sensiblere Aktion wiederverwendet werden.

Der Beta-Integrations-Workflow

  1. 01BewerbenErzählen Sie uns von der app und der Interaktion, die Sie verstehen möchten.
  2. 02UmfangStimmen Sie die Integration, die Routen, die Nutzungslimits und die Datenverarbeitung ab.
  3. 03Im Beobachtungsmodus integrierenKeine Änderung daran, wie Ihre app reagiert.
  4. 04ValidierenVergleichen Sie Ergebnisse mit Ihnen bekannter Ground Truth: Abdeckung, Unknown-Rate, False Positives, Latenz.
  5. 05EntscheidenAktivieren Sie eine Richtlinie nur dort, wo die Evidenz sie stützt.

Was wir mit Founding Teams messen

Abdeckung, Unknown-Rate, False Positives gegenüber bekannten Ergebnissen und zusätzliche Latenz in jedem unterstützten Kontext.

Im Beobachtungsmodus beginnen.

Bewerben Sie sich für die Teilnahme am Founding-Developer-Programm.

Für Early Access bewerbenErkennung und Grenzen ansehen

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